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>

specs/2019.03/approved/multi-os-2004891-directory-layout.rst

@@ -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
+