[Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application
Greetings to the community đ I would like to bring to this mailing list a discussion we are having about splitting the stx-openstack application repositories from the main starlingx manifest into a new one. In order to decouple the OpenStack Clients currently shared between platform and application we are suggesting to decouple the platform and application builds in separate manifests (e.g. starlingx/manifest/default.xml and starlingx/manifest/stx-openstack.xml). I understand that the new manifest needs to be created and build jobs configured properly and tested, I can also create the Stories for mapping this work later. BENEFITS: we achieve the freedom of building different versions of the same packages (i.e. openstack clients) that are shared between the platform and the application. The end goal would be something like: Remain as is (default manifest aligns to upstream Debian version => Victoria) ============ stx/upstream openstack/barbican stx/upstream openstack/keystone stx/upstream openstack/python-barbicanclient stx/upstream openstack/python-keystoneclient stx/upstream openstack/python-horizon stx/upstream openstack/python-openstackclient Only keep the services needed by the platform. Some existing patches might have been brought forward to support stx-openstack, so we should re-evaluate as part of this. Those would still be built as part of STX Platform builds, i.e. starlingx/manifest/default.xml Manifest should not include stx/openstack-armada-app repo anymore. Relocate (stx-openstack app independently aligns to version of choice: Victoria [current] => Antelope [future]) ==================== stx/upstream openstack/barbican copy-to stx/openstack-armada-app/upstream/openstack/barbican stx/upstream openstack/keystone copy-to stx/openstack-armada-app/upstream/openstack/keystone stx/upstream openstack/python-barbicanclient copy-to stx/openstack-armada-app/upstream/openstack/python-barbicanclient stx/upstream openstack/python-keystoneclient copy-to stx/openstack-armada-app/upstream/openstack/python-keystoneclient stx/upstream openstack/python-horizon copy-to stx/openstack-armada-app/upstream/openstack/python-horizon stx/upstream openstack/python-openstackclient copy-to stx/openstack-armada-app/upstream/openstack/python-openstackclient stx/upstream openstack/openstack-pkg-tools move-to stx/openstack-armada-app/upstream/openstack/openstack-pkg-tools stx/upstream openstack/openstack-ras move-to stx/openstack-armada-app/upstream/openstack/openstack-ras stx/upstream openstack/python-aodhclient move-to stx/openstack-armada-app/upstream/openstack/python-aodhclient stx/upstream openstack/python-cinderclient move-to stx/openstack-armada-app/upstream/openstack/python-cinderclient stx/upstream openstack/python-glanceclient move-to stx/openstack-armada-app/upstream/openstack/python-glanceclient stx/upstream openstack/python-gnocchiclient move-to stx/openstack-armada-app/upstream/openstack/python-gnocchiclient stx/upstream openstack/python-heatclient move-to stx/openstack-armada-app/upstream/openstack/python-heatclient stx/upstream openstack/python-ironicclient move-to stx/openstack-armada-app/upstream/openstack/python-ironicclient stx/upstream openstack/python-keystoneclient move-to stx/openstack-armada-app/upstream/openstack/python-keystoneclient stx/upstream openstack/python-neutronclient move-to stx/openstack-armada-app/upstream/openstack/python-neutronclient stx/upstream openstack/python-novaclient move-to stx/openstack-armada-app/upstream/openstack/python-novaclient stx/upstream openstack/python-openstacksdk move-to stx/openstack-armada-app/upstream/openstack/python-openstacksdk stx/upstream openstack/python-osc-lib move-to stx/openstack-armada-app/upstream/openstack/python-osc-lib stx/upstream openstack/python-oslo-messaging move-to stx/openstack-armada-app/upstream/openstack/python-oslo-messaging stx/upstream openstack/python-pankoclient move-to stx/openstack-armada-app/upstream/openstack/python-pankoclient stx/upstream openstack/python-wsme move-to stx/openstack-armada-app/upstream/openstack/python-wsme stx/upstream openstack/rabbitmq-server move-to stx/openstack-armada-app/upstream/openstack/rabbitmq-server The OpenStack Distro Team will create a new directory under stx/openstack-armada-app to store all application needed packages. This will include clients and the stx-openstack Docker images we build only for the application. This way, on stx-openstack build we can build the same packages (name) but using different versions/source code. Manifest does not include upstream repo. ------------------------ We have discussed it between a small group of people so I would like to bring it to the attention of everyone and let the community speak in case there are any concerns against it and/or to support this change proposal. This work will be done in a couple of phases, progressively moving towards achieving the end goal explained here. Looking forward for hearing back from you đ
+1 From: Cervi, Thales Elero <ThalesElero.Cervi@windriver.com> Sent: Thursday, June 15, 2023 1:54 PM To: StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application Greetings to the community đ I would like to bring to this mailing list a discussion we are having about splitting the stx-openstack application repositories from the main starlingx manifest into a new one. In order to decouple the OpenStack Clients currently shared between platform and application we are suggesting to decouple the platform and application builds in separate manifests (e.g. starlingx/manifest/default.xml and starlingx/manifest/stx-openstack.xml). I understand that the new manifest needs to be created and build jobs configured properly and tested, I can also create the Stories for mapping this work later. BENEFITS: we achieve the freedom of building different versions of the same packages (i.e. openstack clients) that are shared between the platform and the application. The end goal would be something like: Remain as is (default manifest aligns to upstream Debian version => Victoria) ============ stx/upstream openstack/barbican stx/upstream openstack/keystone stx/upstream openstack/python-barbicanclient stx/upstream openstack/python-keystoneclient stx/upstream openstack/python-horizon stx/upstream openstack/python-openstackclient Only keep the services needed by the platform. Some existing patches might have been brought forward to support stx-openstack, so we should re-evaluate as part of this. Those would still be built as part of STX Platform builds, i.e. starlingx/manifest/default.xml Manifest should not include stx/openstack-armada-app repo anymore. Relocate (stx-openstack app independently aligns to version of choice: Victoria [current] => Antelope [future]) ==================== stx/upstream openstack/barbican copy-to stx/openstack-armada-app/upstream/openstack/barbican stx/upstream openstack/keystone copy-to stx/openstack-armada-app/upstream/openstack/keystone stx/upstream openstack/python-barbicanclient copy-to stx/openstack-armada-app/upstream/openstack/python-barbicanclient stx/upstream openstack/python-keystoneclient copy-to stx/openstack-armada-app/upstream/openstack/python-keystoneclient stx/upstream openstack/python-horizon copy-to stx/openstack-armada-app/upstream/openstack/python-horizon stx/upstream openstack/python-openstackclient copy-to stx/openstack-armada-app/upstream/openstack/python-openstackclient stx/upstream openstack/openstack-pkg-tools move-to stx/openstack-armada-app/upstream/openstack/openstack-pkg-tools stx/upstream openstack/openstack-ras move-to stx/openstack-armada-app/upstream/openstack/openstack-ras stx/upstream openstack/python-aodhclient move-to stx/openstack-armada-app/upstream/openstack/python-aodhclient stx/upstream openstack/python-cinderclient move-to stx/openstack-armada-app/upstream/openstack/python-cinderclient stx/upstream openstack/python-glanceclient move-to stx/openstack-armada-app/upstream/openstack/python-glanceclient stx/upstream openstack/python-gnocchiclient move-to stx/openstack-armada-app/upstream/openstack/python-gnocchiclient stx/upstream openstack/python-heatclient move-to stx/openstack-armada-app/upstream/openstack/python-heatclient stx/upstream openstack/python-ironicclient move-to stx/openstack-armada-app/upstream/openstack/python-ironicclient stx/upstream openstack/python-keystoneclient move-to stx/openstack-armada-app/upstream/openstack/python-keystoneclient stx/upstream openstack/python-neutronclient move-to stx/openstack-armada-app/upstream/openstack/python-neutronclient stx/upstream openstack/python-novaclient move-to stx/openstack-armada-app/upstream/openstack/python-novaclient stx/upstream openstack/python-openstacksdk move-to stx/openstack-armada-app/upstream/openstack/python-openstacksdk stx/upstream openstack/python-osc-lib move-to stx/openstack-armada-app/upstream/openstack/python-osc-lib stx/upstream openstack/python-oslo-messaging move-to stx/openstack-armada-app/upstream/openstack/python-oslo-messaging stx/upstream openstack/python-pankoclient move-to stx/openstack-armada-app/upstream/openstack/python-pankoclient stx/upstream openstack/python-wsme move-to stx/openstack-armada-app/upstream/openstack/python-wsme stx/upstream openstack/rabbitmq-server move-to stx/openstack-armada-app/upstream/openstack/rabbitmq-server The OpenStack Distro Team will create a new directory under stx/openstack-armada-app to store all application needed packages. This will include clients and the stx-openstack Docker images we build only for the application. This way, on stx-openstack build we can build the same packages (name) but using different versions/source code. Manifest does not include upstream repo. ------------------------ We have discussed it between a small group of people so I would like to bring it to the attention of everyone and let the community speak in case there are any concerns against it and/or to support this change proposal. This work will be done in a couple of phases, progressively moving towards achieving the end goal explained here. Looking forward for hearing back from you đ
participants (2)
-
Cervi, Thales Elero
-
Waines, Greg