[Starlingx-discuss] Challenges with the support to deploy stx-openstack in 7.0
Hi StarlingX TSC and Community, I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns. Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did. The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption? While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0? If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already? Thanks and Best Regards, Ildikó [1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595 ——— Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7. I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind. Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team. Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform. Greg. p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors. -----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0 [Please note: This e-mail is from an EXTERNAL e-mail address] Hi StarlingX TSC and Community, I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns. Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did. The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption? While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0? If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already? Thanks and Best Regards, Ildikó [1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595 ——— Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
On Thu, Jun 30, 2022 at 6:50 PM Waines, Greg <Greg.Waines@windriver.com> wrote:
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7.
I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind.
Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team.
Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform.
well, sh!t3 ... you might want to read my previous email from a few days ago, "subject: docker vs cri-o / centos vs alma / silverblue / coreos." As I for one, will no longer be able to deploy starlingx beyond 6.x if openstack is not onboard we in the process of deploying magmacore for a commercial telco, like other commercial telcos, your now basically shooting yourself in the foot, as if this is the case we end up never being able to upgrade the platforms we/I have already deployed for many. I would have to say, now i'm upset. I have always been a big advocate and where I can / am able to deploy it. It seems now that you might have boxed us in and are leaving us in the dust. And if that's the case then you might want to focus on at least making it work in VMs, since now we are going to have to utilize some other orchestrated virtualization product. Sorry, but I honestly feel it's complete and total BS to do this to your user base. And yes I have a super strong opinion about it being dropped. It really needs to stay or your going to literally alienate a good part of your current user base, and its further adoption in the telecom arena.
Greg.
p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors.
-----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi StarlingX TSC and Community,
I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns.
Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did.
The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod
Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption?
While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0?
If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already?
Thanks and Best Regards, Ildikó
[1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595
———
Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hey thanks for your feedback 😉 . The decision on what to do wrt STX 7 is not final. I was just voicing my opinion. We will discuss more in upcoming STX 7 release meetings. Greg. -----Original Message----- From: Outback Dingo <outbackdingo@gmail.com> Sent: Thursday, June 30, 2022 8:11 AM To: Waines, Greg <Greg.Waines@windriver.com> Cc: Ildiko Vancsa <ildiko.vancsa@gmail.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] Challenges with the support to deploy stx-openstack in 7.0 [Please note: This e-mail is from an EXTERNAL e-mail address] On Thu, Jun 30, 2022 at 6:50 PM Waines, Greg <Greg.Waines@windriver.com> wrote:
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7.
I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind.
Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team.
Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform.
well, sh!t3 ... you might want to read my previous email from a few days ago, "subject: docker vs cri-o / centos vs alma / silverblue / coreos." As I for one, will no longer be able to deploy starlingx beyond 6.x if openstack is not onboard we in the process of deploying magmacore for a commercial telco, like other commercial telcos, your now basically shooting yourself in the foot, as if this is the case we end up never being able to upgrade the platforms we/I have already deployed for many. I would have to say, now i'm upset. I have always been a big advocate and where I can / am able to deploy it. It seems now that you might have boxed us in and are leaving us in the dust. And if that's the case then you might want to focus on at least making it work in VMs, since now we are going to have to utilize some other orchestrated virtualization product. Sorry, but I honestly feel it's complete and total BS to do this to your user base. And yes I have a super strong opinion about it being dropped. It really needs to stay or your going to literally alienate a good part of your current user base, and its further adoption in the telecom arena.
Greg.
p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors.
-----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi StarlingX TSC and Community,
I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns.
Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did.
The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod
Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption?
While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0?
If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already?
Thanks and Best Regards, Ildikó
[1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595
———
Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Thursday 30 June 2022 18:42:35 PM (+07:00), Waines, Greg wrote:
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7. Why is it believed ??? We run k8s 1.21.3 on STX 6.x and openstack-helm deploys just fine, where are you finding this information.
controller-0:~$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE armada armada-api-dc8b94475-28hsg 2/2 Running 2 2d3h cert-manager cm-cert-manager-74cc8d687-rfhwz 1/1 Running 1 2d2h ----snip----------------- kube-system rbd-provisioner-759dfb8b6b-sjq5h 1/1 Running 0 2d2h openstack cinder-api-79b6497c55-9bzqs 1/1 Running 0 2d openstack cinder-backup-d7b4c8946-gnx49 1/1 Running 0 2d openstack cinder-scheduler-7fd896457c-82j7c 1/1 Running 0 2d openstack cinder-volume-57cfc5fcc-8ft7m 1/1 Running 0 2d openstack cinder-volume-usage-audit-27609840-v46qc 0/1 Completed 0 15m openstack cinder-volume-usage-audit-27609845-5dh89 0/1 Completed 0 10m openstack cinder-volume-usage-audit-27609850-qs4bb 0/1 Completed 0 5m29s openstack cinder-volume-usage-audit-27609855-6rglw 1/1 Running 0 29s openstack fm-db-init-7mnt2 0/1 Completed 0 2d openstack fm-db-sync-km7dp 0/1 Completed 0 2d openstack fm-ks-endpoints-htsfz 0/3 Completed 0 2d openstack fm-ks-service-9sqk2 0/1 Completed 0 2d openstack fm-ks-user-wtr27 0/1 Completed 0 2d openstack fm-rest-api-675d7867f6-bpv6w 1/1 Running 0 2d openstack glance-api-699b77f6db-xssfj 1/1 Running 0 2d openstack heat-api-cd74f79c6-kcdtm 1/1 Running 0 2d openstack heat-bootstrap-nhvzl 0/1 Completed 0 2d openstack heat-cfn-5c69ff4548-z7dgw 1/1 Running 0 2d openstack heat-db-init-88lkz 0/1 Completed 0 2d openstack heat-db-sync-df2dp 0/1 Completed 0 2d openstack heat-domain-ks-user-rv6c6 0/1 Completed 0 2d openstack heat-engine-6745946fd4-p6lr4 1/1 Running 0 2d openstack heat-engine-cleaner-27609840-skjm4 0/1 Completed 0 15m openstack heat-engine-cleaner-27609845-xdkj9 0/1 Completed 0 10m openstack heat-engine-cleaner-27609850-f5crb 0/1 Completed 0 5m29s openstack heat-engine-cleaner-27609855-4m6kr 1/1 Running 0 29s openstack heat-ks-endpoints-dfng4 0/6 Completed 0 2d openstack heat-ks-service-7czzq 0/2 Completed 0 2d openstack heat-ks-user-pk7p7 0/1 Completed 0 2d openstack heat-purge-deleted-27607700-mfbbz 0/1 Completed 0 35h openstack heat-purge-deleted-27609140-9sdlw 0/1 Completed 0 11h openstack heat-rabbit-init-74xhg 0/1 Completed 0 2d openstack heat-trustee-ks-user-45xd4 0/1 Completed 0 2d openstack heat-trusts-nsq8j 0/1 Completed 0 2d openstack horizon-5c4c9b79f4-s6v6b 1/1 Running 0 2d openstack horizon-db-init-bs6b5 0/1 Completed 0 2d openstack horizon-db-sync-59gbt 0/1 Completed 0 2d openstack ingress-7559b8d644-2qx6v 1/1 Running 0 2d openstack ingress-error-pages-7975fd4db5-jqn4q 1/1 Running 0 2d openstack keystone-api-84bb867c4c-2n2tj 1/1 Running 0 2d openstack keystone-fernet-rotate-27608400-vsscl 0/1 Completed 0 24h openstack keystone-fernet-rotate-27609120-k2zsv 0/1 Completed 0 12h openstack keystone-fernet-rotate-27609840-2fmmv 0/1 Completed 0 15m openstack libvirt-libvirt-default-ggp5l 1/1 Running 0 2d openstack mariadb-ingress-847cdb5dfb-7q59v 1/1 Running 0 2d openstack mariadb-ingress-error-pages-857f748f89-lvqqc 1/1 Running 0 2d openstack mariadb-server-0 1/1 Running 0 2d openstack neutron-dhcp-agent-controller-0-937646f6-p5nfg 1/1 Running 0 2d openstack neutron-l3-agent-controller-0-937646f6-w5zxp 1/1 Running 0 2d openstack neutron-metadata-agent-controller-0-937646f6-f2vqp 1/1 Running 0 2d openstack neutron-netns-cleanup-cron-default-jx9zr 1/1 Running 1 2d openstack neutron-ovs-agent-controller-0-937646f6-8rzpz 1/1 Running 0 2d openstack neutron-server-764ff69bbd-wqnh6 1/1 Running 0 2d openstack nova-api-metadata-75cf57b549-t97d8 1/1 Running 2 2d openstack nova-api-osapi-5f9d8b8d5d-j848v 1/1 Running 0 2d openstack nova-api-proxy-7c86f9dc4d-vjp66 1/1 Running 1 2d openstack nova-bootstrap-5t9jg 0/1 Completed 0 2d openstack nova-cell-setup-7dr9v 0/1 Completed 0 2d openstack nova-compute-controller-0-937646f6-g6748 2/2 Running 0 2d openstack nova-conductor-c9757f646-bzr5s 1/1 Running 0 2d openstack nova-db-sync-g5w7s 0/1 Completed 0 2d openstack nova-novncproxy-7f58c4dcdb-zxrql 1/1 Running 0 2d openstack nova-scheduler-7b98545d78-zpxvv 1/1 Running 0 2d openstack nova-service-cleaner-27609720-z8nh6 0/1 Completed 0 135m openstack nova-service-cleaner-27609780-vbj58 0/1 Completed 0 75m openstack nova-service-cleaner-27609840-7mb7r 0/1 Completed 0 15m openstack openvswitch-db-ltwlf 1/1 Running 1 2d openstack openvswitch-vswitchd-92tn6 1/1 Running 0 2d openstack osh-openstack-memcached-memcached-54cc965966-96bp9 1/1 Running 0 2d openstack osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 2d openstack pci-irq-affinity-agent-fnn94 1/1 Running 0 2d openstack placement-api-8759c476f-c4gfc 1/1 Running 0 2d controller-0:~$ kubectl version Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"archive", BuildDate:"2022-01-19T17:43:43Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind.
Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team.
Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform.
Greg.
p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors.
-----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi StarlingX TSC and Community,
I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns.
Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did.
The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod
Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption?
While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0?
If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already?
Thanks and Best Regards, Ildikó
[1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595
———
Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
I said that "It is believed that stx-openstack in STX7 w/k8s v1.21" ... simply because in STX7, we have not had a clean sanity run from the StarlingX Test subproject for over a month. Greg. -----Original Message----- From: Embedded Devel <lists@optimcloud.com> Sent: Thursday, June 30, 2022 8:17 AM To: Waines, Greg <Greg.Waines@windriver.com>; Ildiko Vancsa <ildiko.vancsa@gmail.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] Challenges with the support to deploy stx-openstack in 7.0 [Please note: This e-mail is from an EXTERNAL e-mail address] On Thursday 30 June 2022 18:42:35 PM (+07:00), Waines, Greg wrote:
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7. Why is it believed ??? We run k8s 1.21.3 on STX 6.x and openstack-helm deploys just fine, where are you finding this information.
controller-0:~$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE armada armada-api-dc8b94475-28hsg 2/2 Running 2 2d3h cert-manager cm-cert-manager-74cc8d687-rfhwz 1/1 Running 1 2d2h ----snip----------------- kube-system rbd-provisioner-759dfb8b6b-sjq5h 1/1 Running 0 2d2h openstack cinder-api-79b6497c55-9bzqs 1/1 Running 0 2d openstack cinder-backup-d7b4c8946-gnx49 1/1 Running 0 2d openstack cinder-scheduler-7fd896457c-82j7c 1/1 Running 0 2d openstack cinder-volume-57cfc5fcc-8ft7m 1/1 Running 0 2d openstack cinder-volume-usage-audit-27609840-v46qc 0/1 Completed 0 15m openstack cinder-volume-usage-audit-27609845-5dh89 0/1 Completed 0 10m openstack cinder-volume-usage-audit-27609850-qs4bb 0/1 Completed 0 5m29s openstack cinder-volume-usage-audit-27609855-6rglw 1/1 Running 0 29s openstack fm-db-init-7mnt2 0/1 Completed 0 2d openstack fm-db-sync-km7dp 0/1 Completed 0 2d openstack fm-ks-endpoints-htsfz 0/3 Completed 0 2d openstack fm-ks-service-9sqk2 0/1 Completed 0 2d openstack fm-ks-user-wtr27 0/1 Completed 0 2d openstack fm-rest-api-675d7867f6-bpv6w 1/1 Running 0 2d openstack glance-api-699b77f6db-xssfj 1/1 Running 0 2d openstack heat-api-cd74f79c6-kcdtm 1/1 Running 0 2d openstack heat-bootstrap-nhvzl 0/1 Completed 0 2d openstack heat-cfn-5c69ff4548-z7dgw 1/1 Running 0 2d openstack heat-db-init-88lkz 0/1 Completed 0 2d openstack heat-db-sync-df2dp 0/1 Completed 0 2d openstack heat-domain-ks-user-rv6c6 0/1 Completed 0 2d openstack heat-engine-6745946fd4-p6lr4 1/1 Running 0 2d openstack heat-engine-cleaner-27609840-skjm4 0/1 Completed 0 15m openstack heat-engine-cleaner-27609845-xdkj9 0/1 Completed 0 10m openstack heat-engine-cleaner-27609850-f5crb 0/1 Completed 0 5m29s openstack heat-engine-cleaner-27609855-4m6kr 1/1 Running 0 29s openstack heat-ks-endpoints-dfng4 0/6 Completed 0 2d openstack heat-ks-service-7czzq 0/2 Completed 0 2d openstack heat-ks-user-pk7p7 0/1 Completed 0 2d openstack heat-purge-deleted-27607700-mfbbz 0/1 Completed 0 35h openstack heat-purge-deleted-27609140-9sdlw 0/1 Completed 0 11h openstack heat-rabbit-init-74xhg 0/1 Completed 0 2d openstack heat-trustee-ks-user-45xd4 0/1 Completed 0 2d openstack heat-trusts-nsq8j 0/1 Completed 0 2d openstack horizon-5c4c9b79f4-s6v6b 1/1 Running 0 2d openstack horizon-db-init-bs6b5 0/1 Completed 0 2d openstack horizon-db-sync-59gbt 0/1 Completed 0 2d openstack ingress-7559b8d644-2qx6v 1/1 Running 0 2d openstack ingress-error-pages-7975fd4db5-jqn4q 1/1 Running 0 2d openstack keystone-api-84bb867c4c-2n2tj 1/1 Running 0 2d openstack keystone-fernet-rotate-27608400-vsscl 0/1 Completed 0 24h openstack keystone-fernet-rotate-27609120-k2zsv 0/1 Completed 0 12h openstack keystone-fernet-rotate-27609840-2fmmv 0/1 Completed 0 15m openstack libvirt-libvirt-default-ggp5l 1/1 Running 0 2d openstack mariadb-ingress-847cdb5dfb-7q59v 1/1 Running 0 2d openstack mariadb-ingress-error-pages-857f748f89-lvqqc 1/1 Running 0 2d openstack mariadb-server-0 1/1 Running 0 2d openstack neutron-dhcp-agent-controller-0-937646f6-p5nfg 1/1 Running 0 2d openstack neutron-l3-agent-controller-0-937646f6-w5zxp 1/1 Running 0 2d openstack neutron-metadata-agent-controller-0-937646f6-f2vqp 1/1 Running 0 2d openstack neutron-netns-cleanup-cron-default-jx9zr 1/1 Running 1 2d openstack neutron-ovs-agent-controller-0-937646f6-8rzpz 1/1 Running 0 2d openstack neutron-server-764ff69bbd-wqnh6 1/1 Running 0 2d openstack nova-api-metadata-75cf57b549-t97d8 1/1 Running 2 2d openstack nova-api-osapi-5f9d8b8d5d-j848v 1/1 Running 0 2d openstack nova-api-proxy-7c86f9dc4d-vjp66 1/1 Running 1 2d openstack nova-bootstrap-5t9jg 0/1 Completed 0 2d openstack nova-cell-setup-7dr9v 0/1 Completed 0 2d openstack nova-compute-controller-0-937646f6-g6748 2/2 Running 0 2d openstack nova-conductor-c9757f646-bzr5s 1/1 Running 0 2d openstack nova-db-sync-g5w7s 0/1 Completed 0 2d openstack nova-novncproxy-7f58c4dcdb-zxrql 1/1 Running 0 2d openstack nova-scheduler-7b98545d78-zpxvv 1/1 Running 0 2d openstack nova-service-cleaner-27609720-z8nh6 0/1 Completed 0 135m openstack nova-service-cleaner-27609780-vbj58 0/1 Completed 0 75m openstack nova-service-cleaner-27609840-7mb7r 0/1 Completed 0 15m openstack openvswitch-db-ltwlf 1/1 Running 1 2d openstack openvswitch-vswitchd-92tn6 1/1 Running 0 2d openstack osh-openstack-memcached-memcached-54cc965966-96bp9 1/1 Running 0 2d openstack osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 2d openstack pci-irq-affinity-agent-fnn94 1/1 Running 0 2d openstack placement-api-8759c476f-c4gfc 1/1 Running 0 2d controller-0:~$ kubectl version Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"archive", BuildDate:"2022-01-19T17:43:43Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind.
Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team.
Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform.
Greg.
p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors.
-----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi StarlingX TSC and Community,
I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns.
Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did.
The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod
Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption?
While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0?
If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already?
Thanks and Best Regards, Ildikó
[1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595
———
Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
Hi, Thank you all for chiming in on the topic with comments and updates. To quickly summarize the responses so far: * Users are currently relying on the OpenStack component within StarlingX —> if 7.0 does not support OpenStack that prevents them from being able upgrade * The FluxCD transition currently doesn’t support to deploy OpenStack as a StarlingX application * stx-openstack can be deployed with Armada, that is supposed to work in 7.0 with Kubernetes 1.21; however, Armada probably does not work with Kubernetes 1.22 or higher * The community is currently working on testing the 7.0 release and as part of that to verify if 7.0 in its current state can deploy OpenStack * Beyond using the mailing list, further discussions will happen in the Release Team meetings and TSC & Community calls based on the results of sanity testing I’m still somewhat confused about marking the FluxCD feature and work item ‘complete'. Since the spec lists the support of StarlingX applications I think it would be more accurate to mark the feature ‘incomplete’ or ‘limited functionality’. That is more transparent regarding the actual status of the implementation and testing work. Would you all agree? I would also like to encourage everyone who has questions or input to this topic to chime in to this mail thread. In addition, please also join the aforementioned meetings if you can, to follow and participate in the discussions. Thanks and Best Regards, Ildikó
On Jun 30, 2022, at 05:27, Waines, Greg <Greg.Waines@windriver.com> wrote:
I said that "It is believed that stx-openstack in STX7 w/k8s v1.21" ... simply because in STX7, we have not had a clean sanity run from the StarlingX Test subproject for over a month. Greg.
-----Original Message----- From: Embedded Devel <lists@optimcloud.com> Sent: Thursday, June 30, 2022 8:17 AM To: Waines, Greg <Greg.Waines@windriver.com>; Ildiko Vancsa <ildiko.vancsa@gmail.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Thursday 30 June 2022 18:42:35 PM (+07:00), Waines, Greg wrote:
I think what I heard yesterday is that we believe stx-openstack runs on STX 7 w/k8s v1.21 ... although there are two outstanding sanity problems that are currently open. Stx-openstack sanity has not been running for over a month because of transition of starlingx sanity from Intel to Wind River. It is believed that stx-openstack application (based on armada) will NOT work on STX 7 w/k8s v1.22 or v1.23; where v1.23 is the default for STX 7. Why is it believed ??? We run k8s 1.21.3 on STX 6.x and openstack-helm deploys just fine, where are you finding this information.
controller-0:~$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE armada armada-api-dc8b94475-28hsg 2/2 Running 2 2d3h cert-manager cm-cert-manager-74cc8d687-rfhwz 1/1 Running 1 2d2h ----snip----------------- kube-system rbd-provisioner-759dfb8b6b-sjq5h 1/1 Running 0 2d2h openstack cinder-api-79b6497c55-9bzqs 1/1 Running 0 2d openstack cinder-backup-d7b4c8946-gnx49 1/1 Running 0 2d openstack cinder-scheduler-7fd896457c-82j7c 1/1 Running 0 2d openstack cinder-volume-57cfc5fcc-8ft7m 1/1 Running 0 2d openstack cinder-volume-usage-audit-27609840-v46qc 0/1 Completed 0 15m openstack cinder-volume-usage-audit-27609845-5dh89 0/1 Completed 0 10m openstack cinder-volume-usage-audit-27609850-qs4bb 0/1 Completed 0 5m29s openstack cinder-volume-usage-audit-27609855-6rglw 1/1 Running 0 29s openstack fm-db-init-7mnt2 0/1 Completed 0 2d openstack fm-db-sync-km7dp 0/1 Completed 0 2d openstack fm-ks-endpoints-htsfz 0/3 Completed 0 2d openstack fm-ks-service-9sqk2 0/1 Completed 0 2d openstack fm-ks-user-wtr27 0/1 Completed 0 2d openstack fm-rest-api-675d7867f6-bpv6w 1/1 Running 0 2d openstack glance-api-699b77f6db-xssfj 1/1 Running 0 2d openstack heat-api-cd74f79c6-kcdtm 1/1 Running 0 2d openstack heat-bootstrap-nhvzl 0/1 Completed 0 2d openstack heat-cfn-5c69ff4548-z7dgw 1/1 Running 0 2d openstack heat-db-init-88lkz 0/1 Completed 0 2d openstack heat-db-sync-df2dp 0/1 Completed 0 2d openstack heat-domain-ks-user-rv6c6 0/1 Completed 0 2d openstack heat-engine-6745946fd4-p6lr4 1/1 Running 0 2d openstack heat-engine-cleaner-27609840-skjm4 0/1 Completed 0 15m openstack heat-engine-cleaner-27609845-xdkj9 0/1 Completed 0 10m openstack heat-engine-cleaner-27609850-f5crb 0/1 Completed 0 5m29s openstack heat-engine-cleaner-27609855-4m6kr 1/1 Running 0 29s openstack heat-ks-endpoints-dfng4 0/6 Completed 0 2d openstack heat-ks-service-7czzq 0/2 Completed 0 2d openstack heat-ks-user-pk7p7 0/1 Completed 0 2d openstack heat-purge-deleted-27607700-mfbbz 0/1 Completed 0 35h openstack heat-purge-deleted-27609140-9sdlw 0/1 Completed 0 11h openstack heat-rabbit-init-74xhg 0/1 Completed 0 2d openstack heat-trustee-ks-user-45xd4 0/1 Completed 0 2d openstack heat-trusts-nsq8j 0/1 Completed 0 2d openstack horizon-5c4c9b79f4-s6v6b 1/1 Running 0 2d openstack horizon-db-init-bs6b5 0/1 Completed 0 2d openstack horizon-db-sync-59gbt 0/1 Completed 0 2d openstack ingress-7559b8d644-2qx6v 1/1 Running 0 2d openstack ingress-error-pages-7975fd4db5-jqn4q 1/1 Running 0 2d openstack keystone-api-84bb867c4c-2n2tj 1/1 Running 0 2d openstack keystone-fernet-rotate-27608400-vsscl 0/1 Completed 0 24h openstack keystone-fernet-rotate-27609120-k2zsv 0/1 Completed 0 12h openstack keystone-fernet-rotate-27609840-2fmmv 0/1 Completed 0 15m openstack libvirt-libvirt-default-ggp5l 1/1 Running 0 2d openstack mariadb-ingress-847cdb5dfb-7q59v 1/1 Running 0 2d openstack mariadb-ingress-error-pages-857f748f89-lvqqc 1/1 Running 0 2d openstack mariadb-server-0 1/1 Running 0 2d openstack neutron-dhcp-agent-controller-0-937646f6-p5nfg 1/1 Running 0 2d openstack neutron-l3-agent-controller-0-937646f6-w5zxp 1/1 Running 0 2d openstack neutron-metadata-agent-controller-0-937646f6-f2vqp 1/1 Running 0 2d openstack neutron-netns-cleanup-cron-default-jx9zr 1/1 Running 1 2d openstack neutron-ovs-agent-controller-0-937646f6-8rzpz 1/1 Running 0 2d openstack neutron-server-764ff69bbd-wqnh6 1/1 Running 0 2d openstack nova-api-metadata-75cf57b549-t97d8 1/1 Running 2 2d openstack nova-api-osapi-5f9d8b8d5d-j848v 1/1 Running 0 2d openstack nova-api-proxy-7c86f9dc4d-vjp66 1/1 Running 1 2d openstack nova-bootstrap-5t9jg 0/1 Completed 0 2d openstack nova-cell-setup-7dr9v 0/1 Completed 0 2d openstack nova-compute-controller-0-937646f6-g6748 2/2 Running 0 2d openstack nova-conductor-c9757f646-bzr5s 1/1 Running 0 2d openstack nova-db-sync-g5w7s 0/1 Completed 0 2d openstack nova-novncproxy-7f58c4dcdb-zxrql 1/1 Running 0 2d openstack nova-scheduler-7b98545d78-zpxvv 1/1 Running 0 2d openstack nova-service-cleaner-27609720-z8nh6 0/1 Completed 0 135m openstack nova-service-cleaner-27609780-vbj58 0/1 Completed 0 75m openstack nova-service-cleaner-27609840-7mb7r 0/1 Completed 0 15m openstack openvswitch-db-ltwlf 1/1 Running 1 2d openstack openvswitch-vswitchd-92tn6 1/1 Running 0 2d openstack osh-openstack-memcached-memcached-54cc965966-96bp9 1/1 Running 0 2d openstack osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 2d openstack pci-irq-affinity-agent-fnn94 1/1 Running 0 2d openstack placement-api-8759c476f-c4gfc 1/1 Running 0 2d
controller-0:~$ kubectl version Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"archive", BuildDate:"2022-01-19T17:43:43Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
I agree that it is concerning that the work on stx-openstack support of fluxcd and k8s v1.22 & v1.23 is behind.
Generally the starlingx community support for stx-openstack sub-project has decreased significantly in the last few years. - A team from Intel (Bruce Jones, Austin Sun, Mingyuan Qi) supported this originally, but stopped supporting stx-openstack in StarlingX a year ago or so, - A team from Wind River (Douglas Periera) picked up support for stx-openstack in StarlingX a year and a half ago, but as mentioned at the last PTG, their level of contribution has been reduced due to internal Wind River priorities. I believe Douglas only has a team of ~4 working on stx-openstack. They are currently working on fluxcd support and Debian support for stx-openstack, but current plans don't show this being available until end of year, due to capacity of team.
Despite this, I still think it is the right decision to release STX 7 without stx-openstack fully supported. I believe the majority of users of StarlingX are not using stx-openstack. I believe the majority of users of StarlingX are only leveraging the Kubernetes Platform, and StarlingX's infrastructure management of that Kubernetes Platform.
Greg.
p.s. If we release STX 7, and we do get concerned feedback on limited support for stx-openstack in STX 7, perhaps this is good opportunity to seek help from these concerned StarlingX Users of stx-openstack to become contributors.
-----Original Message----- From: Ildiko Vancsa <ildiko.vancsa@gmail.com> Sent: Wednesday, June 29, 2022 11:24 PM To: Waines, Greg <Greg.Waines@windriver.com>; Qi, Mingyuan <mingyuan.qi@intel.com>; Shuquan Huang <huang.shuquan@99cloud.net>; Subramanian, Ramaswamy <Ramaswamy.Subramanian@windriver.com>; StarlingX ML <starlingx-discuss@lists.starlingx.io> Subject: Challenges with the support to deploy stx-openstack in 7.0
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi StarlingX TSC and Community,
I’m reaching out to you about one of the topics that came up during the Release Team meeting[1] earlier today, which is the replacement of Armada with FluxCD. The conversation got me a little confused and I would like to follow up on a few questions and concerns.
Background: According to the current state of the 7.0 release the work item is in a stage where it is operational and the feature is marked ‘Done’ in the release spreadsheet. At the same time, it does not support the deployment of OpenStack as part of StarlingX. I found this surprising, as my expectation was that the goal and expected outcome of the feature implementation was to provide the same functionality as Armada did.
The spec[2] also lists the following work items: * Update the application framework to use the Helm/Source controllers * Update all applications to use the Helm/Source controllers for deploying/updating applications * Provide upgrade support to update all applications to the Helm Controller and remove the Armada pod
Questions and concerns: My understanding was that ‘application’ refers to OpenStack among other components. Is that a false assumption?
While it can happen that a bigger work item gets released with partial functionality, it was raised during the call today that StarlingX 7.0 might get released without the support to deploy OpenStack potentially due to issues with the now deprecated Armada component. Is my understanding correct that it is a possible scenario for StarlingX 7.0?
If the above scenario happened, it would result in a very visible user-facing change which can provide issues to existing users or shrink the pool of potential new ones. While OpenStack is utilizing the advantages of being deployed in containers, it is still a dominant feature of StarlingX to provide infrastructure functionality. In that sense, I think there are concerns that would be worthwhile to evaluate to decide if it is a blocking issue to not being able to deploy it within StarlingX in the 7.0 release. What are your thoughts about this? Have the impacts of the above mentioned scenario been evaluated already?
Thanks and Best Regards, Ildikó
[1] https://etherpad.opendev.org/p/stx-releases [2] https://review.opendev.org/c/starlingx/specs/+/829595
———
Ildikó Váncsa Senior Manager, Community & Ecosystem Open Infrastructure Foundation
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
participants (4)
-
Embedded Devel
-
Ildiko Vancsa
-
Outback Dingo
-
Waines, Greg