Define Flock services directory layout for MultiOS

This specification will extend the current Flock services directory structure
to support more operating systems apart from the current CentOS OS supported.

Change-Id: Ib518d6814b06929ee6a44ffc71043c9c43e189f3
Signed-off-by: Victor Rodriguez <victor.rodriguez.bahena@intel.com>
Suggested-by: Saul Wold <saul.wold@intel.com>
This commit is contained in:
VictorRodriguez 2019-03-21 12:59:50 -06:00
parent e4e5d18622
commit 997155882a

View File

@ -0,0 +1,209 @@
.. This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==============================================
StarlingX: Define directory layout for MultiOS
==============================================
Storyboard: https://storyboard.openstack.org/#!/story/2004891
This specification will extend the current Flock services directory structure
to support more operating systems apart from the current CentOS OS supported.
Problem description
===================
The current directory structure is based around the build working with CentOS
OS and the current build tooling. The flock services git repositories provide a
directory call centos with the spec files to build RPMs distribution packages.
In order to support building the flock services packages for new, different
OSes is necessary to provide additional directories where the community can
have a place to contribute with build scripts such as control and rules files
(for Debian based operating systems) or spec files based on another RPM base OS
like openSUSE
Use Cases
=========
a) Users that want to build the flock services on other OSes beyond the
current CentOS fully supported by Starling X community
Proposed change
===============
Define an extended directory layout that will support other Operating Systems
beyond the existing CentOS layout. The existing layout will remain in place and
will not disrupt the current workflow in the CentOS build system.
The following is the proposed layout, where <package-name> could be any one of
packages that build flock services.
https://opendev.org/starlingx/fault/src/branch/master/fm-common
<package-name>
├── <existing source>
│ ├── source code of the project
├── centos //This is the current centOS directory, it will not be modified.
└── debian
│ ├── fm-common-dev.install
│ ├── fm-common-doc.install
│ ├── fm-common-wheels.install
│ ├── fm-common.install
│ ├── rules
│ ├── control
└── opensuse
│ ├──fm-common.spec
The Debian directory will contain the following files:
* Debian/control:
The Debian/control file contains the most vital (and version-independent)
information about the source package and about the binary packages it creates.
* Debian/rules:
The Debian/rules script is the executable script to build the Debian package.
The openSuSE directory will contain the spec file for open SuSE distribution.
The build dependencies required are not the same that the spec file from centOS
The proposed change is only to provide a place where the StarlingX community
could leave the build recipes for other distributions. The only distribution
fully supported will be CentOS.
Alternatives
============
Create a new set of directories to represent each new operating system.
Data model impact
=================
None
REST API impact
===============
None
Security impact
===============
None
Other end user impact
=====================
None
Performance Impact
==================
None
Other Deployer impact
=====================
None
Developer impact
=================
The community might send patches to
https://opendev.org/starlingx/config
https://opendev.org/starlingx/distcloud
https://opendev.org/starlingx/distcloud-client
https://opendev.org/starlingx/fault
https://opendev.org/starlingx/gui
https://opendev.org/starlingx/ha
https://opendev.org/starlingx/integ
https://opendev.org/starlingx/nfv
https://opendev.org/starlingx/update
https://opendev.org/starlingx/metal
Upgrade impact
===============
None
Implementation
==============
If a community member wants to provide the build recipes to build a flock the
component in other OS it will be necessary to send the git-review of the patch
adding these files into the proper directory with the name of the os.
These files will be created following upstream distro packaging guidelines
(for example the openSUSE spec file should follow the openSUSE Guideline and
validate with spec-cleaner tools[1])
Assignee(s)
===========
Primary assignee:
- Victor Rodriguez
Other contributors:
- Marcela Rosales
- Erich Cordoba Malibran
Repos Impacted
==============
Work Items
===========
Create directory tree and files as new Operating Systems are added by
community.
Dependencies
============
Testing
=======
Ensure that the current build continues to work as the directory layout is
extended.
For each type of packaging meta-data (specfile, rules, control, ...) for a
specific distribution, there should be a minimum set of gating jobs to validate
that meta-data. This may vary from simple linter type of job (spec-cleaner
tools[1] for OpenSUSE), to full blown build of the package and validate the
built package somehow (rpmlint). This does not necessarily mean validating the
actual packaged binaries, just the packaging itself.
Documentation Impact
====================
New documentation will be generated to define the contents of the extended
directory layout.
Every time a new OS build recipe is provided by the community, the proper
documentation of how to build the package for specific distro should be
provided.
References
==========
[1]https://github.com/openSUSE/spec-cleaner
History
=======
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - STX-2.0
- Introduced