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
parent
e4e5d18622
commit
997155882a
|
|
@ -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
|
||||
|
||||
Loading…
Reference in New Issue