From ildiko at openinfra.dev Thu Jun 1 00:35:48 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Wed, 31 May 2023 17:35:48 -0700 Subject: [Starlingx-discuss] StarlingX activities at the upcoming OpenInfra Summit Message-ID: Hi StarlingX Community, I hope you are doing well. The next OpenInfra Summit[1] is coming up fast, the conference will be in Vancouver, Canada on June 13-15. I?m very excited as there will be many StarlingX related activities happening during the conference. * StarlingX conference sessions, as of today: - StarlingX: Next generation infrastructure for cloud native - A private 5G campus network enabled and powered by OpenStack and StarlingX - Enabling the Intelligent Edge with StarlingX - Full Featured PTP in the Cloud for Telcos - From Legacy to Agility: Why stx-openstack and Containers are the Key to Modernizing your IT Infrastructure - StarlingX at scale - Infrastructure management of 10s of 1000s of geographically distributed clouds - StarlingX: Next Generation Security with Zero Trust Architecture - Using enclave technology to help secure secrets in a distributed world! - StarlingX Evolution - New Deployment Architectures - StarlingX: Using OSTree Atomic Updates to Drastically Reduce Outage Times for Upgrades of Remote Single-Server Edge Clouds You can find the overall conference schedule here: https://vancouver2023.openinfra.dev/a/schedule The conference sessions will be recorded and made available after the conference. * StarlingX hands-on workshop: The community is doing a hands-on workshop at the OpenInfra Summit to guide attendees through the deployment and configuration of the platform. The session will also show how to deploy an application, if time allows. You can find more information about the session here: https://openinfra.dev/summit-schedule#event=25866&view=list * StarlingX 5th anniversary gathering: As you might have already heard, the StarlingX project is turning 5 years old this year! If you are planning to be on site for the OpenInfra Summit, I would like to invite you to a small gathering that we are organizing to celebrate this anniversary with some drinks and snacks on Wednesday (June 14) at 6:30pm - 8pm local time, which is after the Marketplace Mixer on the second day of the event. Please __RSVP__ if you will be joining us: https://openinfrafoundation.formstack.com/forms/starlingx_5th_anniversary_celebration * Project Teams Gathering (PTG) There will be an in-person PTG held in Vancouver co-located with the OpenInfra Summit on June 14-15. The starlingX community signed up to participate in the event and discuss topics related to the platform as well as the community. The community currently grabbed slots for Wednesday (June 14) afternoon starting at 2:30pm local time. As the schedule might change, please check the PTG schedule closer to the event: https://ptg.opendev.org/ptg.html I hope to see you in Vancouver! Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From Bruno.Muniz at encora.com Thu Jun 1 14:35:52 2023 From: Bruno.Muniz at encora.com (Bruno Drugowick Muniz) Date: Thu, 1 Jun 2023 14:35:52 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: References: Message-ID: I too +1 on moving the "deployment" directory into its own repo. Everything there is related to deployment in virtualized (via libvirt or VirtualBox) environments. -- Bruno ________________________________ From: Church, Robert Sent: Wednesday, May 31, 2023 14:08 To: Panech, Davlet ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple You don't often get email from robert.church at windriver.com. Learn why this is important External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 for moving ?deployment? out of tools and into its own repo with a set of core reviewers that use the scripts. As a core reviewer that does not use the scripts provided here, I don?t have the bandwidth to review these. Bob From: Panech, Davlet Date: Wednesday, May 31, 2023 at 10:09 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at eng.windriver.com Thu Jun 1 15:21:40 2023 From: scott.little at eng.windriver.com (Scott.Little) Date: Thu, 1 Jun 2023 11:21:40 -0400 Subject: [Starlingx-discuss] StarlingX engagement In-Reply-To: References: Message-ID: Windriver Ottawa is unable to host the equipment at this time. You'll have to find another location, or host it yourself for now. Scott On 2023-05-25 03:54, Trevor Tao wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hi Greg, StarlingX community: > > For the StarlingX arm enablement issue, we would like to ask about the support of Starlingx building infrastructure for arm platform. > Could you provide the requirement or any suggestion for the building infrastructure for arm from the community side? > > After talking with Windriver guys, we imagine there would be 2 build servers and 4 testing servers, the initial required config for those servers that we thought of is listed below as a reference, but it may still be under discussion and support by our LoB and vendors since it still has gaps between the desired config here and their initial provision we got to know: > > 1. 2 Build servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 2 x 1T SSD storage > ? 1 x 1GB onboard NIC > 2. 4 testing servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 3 x 500G SSD storage > ? 2 x 10GB ports on NIC (preferably Mellanox) > ? 2 x 1GB > > Thanks for your support, > > Best Regards, > > Zijin Tao(Trevor Tao, ???) > ARM Electronic Technology (Shanghai) Co., Ltd > ?????????????? > Building 11, Shanghai Busininess Park? , > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > ?????????1016???????2??10??200233 > Cell: +86-153 7109 6192 > > -----Original Message----- > From: Huang, Jie (Jackie) > Sent: Tuesday, May 23, 2023 1:55 PM > To: starlingx-discuss at lists.starlingx.io > Cc: Waines, Greg ; Outback Dingo ; Trevor Tao > Subject: RE: [Starlingx-discuss] StarlingX engagement > > Hi StarlingX community, > > As mentioned in the last call of the StarlingX OS Distro Project Meeting (Minutes: https://etherpad.opendev.org/p/stx-distro-other), > I would like to share the development status of the work to support ARM, which I started three months ago: > - It's a native build solution on HPE RL300 Gen11 server (Ampere Altra 1x80 cores) > - All code changes are POC level with many hard-codes and workarounds. > - Built out a bootable ISO image and tested deployment of AIO-SX and AIO-DX > > Detail status please refer to: > https://github.com/jackiehjm/stx-builds/blob/master/docs/2023_stx_on_arm_status.md > > And as follow-up in the call, I have the following questions need to ask here: > 1. For container images re-generated for ARM64 arch, how can I push them to docker hub https://hub.docker.com/u/starlingx? > Or can I ask for help on creating all container images for ARM64 and push to docker hub automatically so all container images > on https://hub.docker.com/u/starlingx will support both x86 and ARM64? > 2. Pre-built packages for x86_64 are in CENGN as package mirror, how can push ARM packages there as well? > > Thanks, > Jackie > >> -----Original Message----- >> From: Outback Dingo >> Sent: Wednesday, May 17, 2023 2:50 PM >> To: Trevor Tao >> Cc: Waines, Greg ; starlingx- >> discuss at lists.starlingx.io; Huang, Jie (Jackie) >> >> Subject: Re: [Starlingx-discuss] StarlingX engagement >> >> might i also suggest a good start down that path might be to get >> meta-stx to build for arm64 under yocto ?? >> >> On Wed, May 17, 2023 at 12:50?PM Trevor Tao wrote: >>> Hi Greg: >>> >>> >>> >>> It?s glad to get your support and suggestion here, especially on the >>> arm >> support. >>> I would attend the meeting if available. >>> >>> Thank you. >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> From: Waines, Greg >>> Sent: Monday, May 15, 2023 7:08 PM >>> To: Trevor Tao ; >>> starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: RE: StarlingX engagement >>> >>> >>> >>> Welcome Trevor. >>> >>> Thanks for your interest. Arm support is a topic that has come up a >>> lot >> recently in StarlingX discussions and one we are very interested in. >>> >>> >>> I would suggest by starting to attend the Bi-Weekly StarlingX OS >>> Distro >> Project Meeting. >>> I have attached the calendar event. >>> >>> >>> >>> Greg. >>> >>> >>> >>> From: Trevor Tao >>> Sent: Friday, May 12, 2023 9:27 AM >>> To: starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: [Starlingx-discuss] StarlingX engagement >>> >>> >>> >>> CAUTION: This email comes from a non Wind River email account! >>> Do not click links or open attachments unless you recognize the >>> sender and >> know the content is safe. >>> Hi StarlingX community: >>> >>> >>> >>> I am a software engineer from CE-OSS(Open Source Software) of Arm >>> ltd, >> now I would like to engage and give contribution in the development >> work of StarlingX project and community. >>> I am interested in StarlingX development, tests and especially the >> porting/enablement work on arm, so I would like to know which working >> groups would be best for me to join. >>> >>> >>> Thanks, >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io From scott.little at eng.windriver.com Thu Jun 1 15:29:44 2023 From: scott.little at eng.windriver.com (Scott.Little) Date: Thu, 1 Jun 2023 11:29:44 -0400 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: References: Message-ID: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: > Good day, > > We are considering splitting the git repository starlingx/tools into > multiple. Reason: it contains files & scripts from unrelated domains > and it is difficult to find Git reviewers whose expertise covers all > of them. > > At a minimum, I suggest we separate out the "deployment" directory in > its own repository. > > Would it make sense to separate out any other directories? > > D. > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Thu Jun 1 13:47:40 2023 From: scott.little at windriver.com (Scott Little) Date: Thu, 1 Jun 2023 09:47:40 -0400 Subject: [Starlingx-discuss] [build-report] r/stx.7.0 STX_7.0_build_layer_containers - Build # 37 - Still Failing! In-Reply-To: References: <1086513388.122.1682851547530.JavaMail.javamailuser@localhost> <1082637732.288.1684665705124.JavaMail.javamailuser@localhost> <99fb590f-07fa-cdb1-316b-2c01b51de652@windriver.com> Message-ID: I have disabled the container build step of the r/stx.7.0 build. Scott On 2023-05-29 16:46, Waines, Greg wrote: > > Any one else with any concerns over discontinuing container builds > from r/stx.7.0 ? > > As Thales mentioned, we have the official release container images > built and tagged in r/stx.7.0 . > So this would only impact someone building stx 7 ?AND? requiring > container images to be rebuilt ? probably a small chance. > > Plus, as previously mentioned, STX 7 is EOL in September. > > Any last concerns ? ? before we discontinue container builds in stx 7 ? > > Greg. > > *From:* Scott Kamp > *Sent:* Thursday, May 25, 2023 7:26 PM > *To:* Waines, Greg ; Cervi, Thales Elero > ; starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] [build-report] r/stx.7.0 > STX_7.0_build_layer_containers - Build # 37 - Still Failing! > > *CAUTION: This email comes from a non Wind River email account!* > Do not click links or open attachments unless you recognize the sender > and know the content is safe. > > no we are not... > > Thanks, > > Scott > > ------------------------------------------------------------------------ > > *From:*Waines, Greg > *Sent:* Thursday, May 25, 2023 11:53 PM > *To:* Cervi, Thales Elero ; > starlingx-discuss at lists.starlingx.io > > *Subject:* Re: [Starlingx-discuss] [build-report] r/stx.7.0 > STX_7.0_build_layer_containers - Build # 37 - Still Failing! > > Scott Kamp ?? ?(or anyone else) > > Can you comment on whether you are building STX 7 that would require > container builds ? > > Greg. > > *From:* Cervi, Thales Elero > *Sent:* Wednesday, May 24, 2023 2:55 PM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] [build-report] r/stx.7.0 > STX_7.0_build_layer_containers - Build # 37 - Still Failing! > > Hi Scott, > > > From my point of view, since we already have the official release > images built and tagged, I don't see why not to discontinue container > builds from r/stx.7.0. > This would only affect re-builds of our older branch and apparently to > maintain that code base is starting to become a problematic task > without any rewards if no one is needing those docker images to be > re-build. > > I would agree with discontinuing it. > > Thales > > ------------------------------------------------------------------------ > > *From:*Scott Little > > *Sent:*Wednesday, May 24, 2023 10:52 AM > *To:* starlingx-discuss at lists.starlingx.io > > *Subject:* Re: [Starlingx-discuss] [build-report] r/stx.7.0 > STX_7.0_build_layer_containers - Build # 37 - Still Failing! > > Branch r/stx.7.0 can build ISO's, but container builds remain broken on > stx-nova. > > stx-nova's issues started with spice-html5.? The first issue was > spice-html5's github repo, forcing a move to gitlab's copy of the > spice-html5.? The move to gitlab went smoothly for debian (master and > r/stx.8.0), but is failing to clone from r/stx.7.0 centos.? It appears > gitlab requires a newer version git.? Centos is using version 1.8.x. > Debain is using a version 2.x.x. > > r/stx.7.0 needs to find a way to inject a newer version of git into the > Loci CentOS container that stx-nova is based on. > > The alternative is to discontinue contained builds from r/stx.7.0 > > Thoughts? > > Scott > > > On 2023-05-21 06:41, starlingx.build at gmail.com wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the > sender and know the content is safe. > > > > Project: STX_7.0_build_layer_containers > > Build #: 37 > > Status: Still Failing > > Timestamp: 20230521T051649Z > > Branch: r/stx.7.0 > > > > Check logs at: > > > http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/containers/20230521T051649Z/logs > > > > -------------------------------------------------------------------------------- > > Parameters > > > > BUILD_CONTAINERS_DEV: false > > BUILD_CONTAINERS_STABLE: true > > FORCE_BUILD: true > > > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Thu Jun 1 15:19:36 2023 From: scott.little at windriver.com (Scott Little) Date: Thu, 1 Jun 2023 11:19:36 -0400 Subject: [Starlingx-discuss] StarlingX engagement In-Reply-To: References: Message-ID: <141af209-e87c-0a88-5c42-40660797391d@windriver.com> Windriver Ottawa is unable to host the equipment at this time. You'll have to find another location, or host it yourself for now. Scott On 2023-05-25 03:54, Trevor Tao wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hi Greg, StarlingX community: > > For the StarlingX arm enablement issue, we would like to ask about the support of Starlingx building infrastructure for arm platform. > Could you provide the requirement or any suggestion for the building infrastructure for arm from the community side? > > After talking with Windriver guys, we imagine there would be 2 build servers and 4 testing servers, the initial required config for those servers that we thought of is listed below as a reference, but it may still be under discussion and support by our LoB and vendors since it still has gaps between the desired config here and their initial provision we got to know: > > 1. 2 Build servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 2 x 1T SSD storage > ? 1 x 1GB onboard NIC > 2. 4 testing servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 3 x 500G SSD storage > ? 2 x 10GB ports on NIC (preferably Mellanox) > ? 2 x 1GB > > Thanks for your support, > > Best Regards, > > Zijin Tao(Trevor Tao, ???) > ARM Electronic Technology (Shanghai) Co., Ltd > ?????????????? > Building 11, Shanghai Busininess Park? , > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > ?????????1016???????2??10??200233 > Cell: +86-153 7109 6192 > > -----Original Message----- > From: Huang, Jie (Jackie) > Sent: Tuesday, May 23, 2023 1:55 PM > To: starlingx-discuss at lists.starlingx.io > Cc: Waines, Greg ; Outback Dingo ; Trevor Tao > Subject: RE: [Starlingx-discuss] StarlingX engagement > > Hi StarlingX community, > > As mentioned in the last call of the StarlingX OS Distro Project Meeting (Minutes: https://etherpad.opendev.org/p/stx-distro-other), > I would like to share the development status of the work to support ARM, which I started three months ago: > - It's a native build solution on HPE RL300 Gen11 server (Ampere Altra 1x80 cores) > - All code changes are POC level with many hard-codes and workarounds. > - Built out a bootable ISO image and tested deployment of AIO-SX and AIO-DX > > Detail status please refer to: > https://github.com/jackiehjm/stx-builds/blob/master/docs/2023_stx_on_arm_status.md > > And as follow-up in the call, I have the following questions need to ask here: > 1. For container images re-generated for ARM64 arch, how can I push them to docker hub https://hub.docker.com/u/starlingx? > Or can I ask for help on creating all container images for ARM64 and push to docker hub automatically so all container images > on https://hub.docker.com/u/starlingx will support both x86 and ARM64? > 2. Pre-built packages for x86_64 are in CENGN as package mirror, how can push ARM packages there as well? > > Thanks, > Jackie > >> -----Original Message----- >> From: Outback Dingo >> Sent: Wednesday, May 17, 2023 2:50 PM >> To: Trevor Tao >> Cc: Waines, Greg ; starlingx- >> discuss at lists.starlingx.io; Huang, Jie (Jackie) >> >> Subject: Re: [Starlingx-discuss] StarlingX engagement >> >> might i also suggest a good start down that path might be to get >> meta-stx to build for arm64 under yocto ?? >> >> On Wed, May 17, 2023 at 12:50?PM Trevor Tao wrote: >>> Hi Greg: >>> >>> >>> >>> It?s glad to get your support and suggestion here, especially on the >>> arm >> support. >>> I would attend the meeting if available. >>> >>> Thank you. >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> From: Waines, Greg >>> Sent: Monday, May 15, 2023 7:08 PM >>> To: Trevor Tao ; >>> starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: RE: StarlingX engagement >>> >>> >>> >>> Welcome Trevor. >>> >>> Thanks for your interest. Arm support is a topic that has come up a >>> lot >> recently in StarlingX discussions and one we are very interested in. >>> >>> >>> I would suggest by starting to attend the Bi-Weekly StarlingX OS >>> Distro >> Project Meeting. >>> I have attached the calendar event. >>> >>> >>> >>> Greg. >>> >>> >>> >>> From: Trevor Tao >>> Sent: Friday, May 12, 2023 9:27 AM >>> To: starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: [Starlingx-discuss] StarlingX engagement >>> >>> >>> >>> CAUTION: This email comes from a non Wind River email account! >>> Do not click links or open attachments unless you recognize the >>> sender and >> know the content is safe. >>> Hi StarlingX community: >>> >>> >>> >>> I am a software engineer from CE-OSS(Open Source Software) of Arm >>> ltd, >> now I would like to engage and give contribution in the development >> work of StarlingX project and community. >>> I am interested in StarlingX development, tests and especially the >> porting/enablement work on arm, so I would like to know which working >> groups would be best for me to join. >>> >>> >>> Thanks, >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io From douglas.pereira at encora.com Thu Jun 1 16:11:28 2023 From: douglas.pereira at encora.com (Douglas Lopes Pereira) Date: Thu, 1 Jun 2023 16:11:28 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> References: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> Message-ID: +1 on 'deployment' Douglas Lopes Pereira Software Development Manager M: +55 (19) 99212-3212 Campinas, BR [Encora] [We are proud to be recognized as Leaders in digital engineering services by Zinnov zones] ________________________________ From: Scott.Little Sent: Thursday, June 1, 2023 12:29 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple You don't often get email from scott.little at eng.windriver.com. Learn why this is important External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at optimcloud.com Thu Jun 1 16:36:27 2023 From: lists at optimcloud.com (lists at optimcloud.com) Date: Thu, 01 Jun 2023 16:36:27 +0000 Subject: [Starlingx-discuss] StarlingX engagement In-Reply-To: References: Message-ID: <1685637087457.909095029.2656062503@optimcloud.com> OptimCloud has rack space, ip and pipe available we could allocate for such a build infrastructure for furthering ARM64 development of StarlingX, as we understand there is a need for such infrastructure to be hosted and accessible for the community and developers to continue moving arm architecture builds and development forward. On Thursday 01 June 2023 10:21:40 PM (+07:00), Scott.Little wrote: > Windriver Ottawa is unable to host the equipment at this time. > > You'll have to find another location, or host it yourself for now. > > Scott > > > On 2023-05-25 03:54, Trevor Tao wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > Hi Greg, StarlingX community: > > > > For the StarlingX arm enablement issue, we would like to ask about the support of Starlingx building infrastructure for arm platform. > > Could you provide the requirement or any suggestion for the building infrastructure for arm from the community side? > > > > After talking with Windriver guys, we imagine there would be 2 build servers and 4 testing servers, the initial required config for those servers that we thought of is listed below as a reference, but it may still be under discussion and support by our LoB and vendors since it still has gaps between the desired config here and their initial provision we got to know: > > > > 1. 2 Build servers configuration requirement, for each: > > ? 1 x Q64-30 processor > > ? 128G MEM > > ? 2 x 1T SSD storage > > ? 1 x 1GB onboard NIC > > 2. 4 testing servers configuration requirement, for each: > > ? 1 x Q64-30 processor > > ? 128G MEM > > ? 3 x 500G SSD storage > > ? 2 x 10GB ports on NIC (preferably Mellanox) > > ? 2 x 1GB > > > > Thanks for your support, > > > > Best Regards, > > > > Zijin Tao(Trevor Tao, ???) > > ARM Electronic Technology (Shanghai) Co., Ltd > > ?????????????? > > Building 11, Shanghai Busininess Park? , > > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > > ?????????1016???????2??10??200233 > > Cell: +86-153 7109 6192 > > > > -----Original Message----- > > From: Huang, Jie (Jackie) > > Sent: Tuesday, May 23, 2023 1:55 PM > > To: starlingx-discuss at lists.starlingx.io > > Cc: Waines, Greg ; Outback Dingo ; Trevor Tao > > Subject: RE: [Starlingx-discuss] StarlingX engagement > > > > Hi StarlingX community, > > > > As mentioned in the last call of the StarlingX OS Distro Project Meeting (Minutes: https://etherpad.opendev.org/p/stx-distro-other), > > I would like to share the development status of the work to support ARM, which I started three months ago: > > - It's a native build solution on HPE RL300 Gen11 server (Ampere Altra 1x80 cores) > > - All code changes are POC level with many hard-codes and workarounds. > > - Built out a bootable ISO image and tested deployment of AIO-SX and AIO-DX > > > > Detail status please refer to: > > https://github.com/jackiehjm/stx-builds/blob/master/docs/2023_stx_on_arm_status.md > > > > And as follow-up in the call, I have the following questions need to ask here: > > 1. For container images re-generated for ARM64 arch, how can I push them to docker hub https://hub.docker.com/u/starlingx? > > Or can I ask for help on creating all container images for ARM64 and push to docker hub automatically so all container images > > on https://hub.docker.com/u/starlingx will support both x86 and ARM64? > > 2. Pre-built packages for x86_64 are in CENGN as package mirror, how can push ARM packages there as well? > > > > Thanks, > > Jackie > > > >> -----Original Message----- > >> From: Outback Dingo > >> Sent: Wednesday, May 17, 2023 2:50 PM > >> To: Trevor Tao > >> Cc: Waines, Greg ; starlingx- > >> discuss at lists.starlingx.io; Huang, Jie (Jackie) > >> > >> Subject: Re: [Starlingx-discuss] StarlingX engagement > >> > >> might i also suggest a good start down that path might be to get > >> meta-stx to build for arm64 under yocto ?? > >> > >> On Wed, May 17, 2023 at 12:50?PM Trevor Tao wrote: > >>> Hi Greg: > >>> > >>> > >>> > >>> It?s glad to get your support and suggestion here, especially on the > >>> arm > >> support. > >>> I would attend the meeting if available. > >>> > >>> Thank you. > >>> > >>> > >>> > >>> Best Regards, > >>> > >>> > >>> > >>> Zijin Tao(Trevor Tao, ???) > >>> > >>> ARM Electronic Technology (Shanghai) Co., Ltd > >>> > >>> ?????????????? > >>> > >>> Building 11, Shanghai Busininess Park? , > >>> > >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > >>> > >>> ?????????1016???????2??10??200233 > >>> > >>> Cell: +86-153 7109 6192 > >>> > >>> > >>> > >>> From: Waines, Greg > >>> Sent: Monday, May 15, 2023 7:08 PM > >>> To: Trevor Tao ; > >>> starlingx-discuss at lists.starlingx.io > >>> Cc: Huang, Jie (Jackie) > >>> Subject: RE: StarlingX engagement > >>> > >>> > >>> > >>> Welcome Trevor. > >>> > >>> Thanks for your interest. Arm support is a topic that has come up a > >>> lot > >> recently in StarlingX discussions and one we are very interested in. > >>> > >>> > >>> I would suggest by starting to attend the Bi-Weekly StarlingX OS > >>> Distro > >> Project Meeting. > >>> I have attached the calendar event. > >>> > >>> > >>> > >>> Greg. > >>> > >>> > >>> > >>> From: Trevor Tao > >>> Sent: Friday, May 12, 2023 9:27 AM > >>> To: starlingx-discuss at lists.starlingx.io > >>> Cc: Huang, Jie (Jackie) > >>> Subject: [Starlingx-discuss] StarlingX engagement > >>> > >>> > >>> > >>> CAUTION: This email comes from a non Wind River email account! > >>> Do not click links or open attachments unless you recognize the > >>> sender and > >> know the content is safe. > >>> Hi StarlingX community: > >>> > >>> > >>> > >>> I am a software engineer from CE-OSS(Open Source Software) of Arm > >>> ltd, > >> now I would like to engage and give contribution in the development > >> work of StarlingX project and community. > >>> I am interested in StarlingX development, tests and especially the > >> porting/enablement work on arm, so I would like to know which working > >> groups would be best for me to join. > >>> > >>> > >>> Thanks, > >>> > >>> > >>> > >>> Best Regards, > >>> > >>> > >>> > >>> Zijin Tao(Trevor Tao, ???) > >>> > >>> ARM Electronic Technology (Shanghai) Co., Ltd > >>> > >>> ?????????????? > >>> > >>> Building 11, Shanghai Busininess Park? , > >>> > >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > >>> > >>> ?????????1016???????2??10??200233 > >>> > >>> Cell: +86-153 7109 6192 > >>> > >>> > >>> > >>> IMPORTANT NOTICE: The contents of this email and any attachments are > >> confidential and may also be privileged. If you are not the intended > >> recipient, please notify the sender immediately and do not disclose > >> the contents to any other person, use it for any purpose, or store or > >> copy the information in any medium. Thank you. > >>> IMPORTANT NOTICE: The contents of this email and any attachments are > >> confidential and may also be privileged. If you are not the intended > >> recipient, please notify the sender immediately and do not disclose > >> the contents to any other person, use it for any purpose, or store or > >> copy the information in any medium. Thank you. > >>> _______________________________________________ > >>> Starlingx-discuss mailing list > >>> Starlingx-discuss at lists.starlingx.io > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com From amy at demarco.com Thu Jun 1 17:32:59 2023 From: amy at demarco.com (Amy Marrich) Date: Thu, 1 Jun 2023 12:32:59 -0500 Subject: [Starlingx-discuss] RDO Ice Cream Social at OpenInfra Summit Message-ID: Join members of the community for ice cream after the Marketplace Mixer on Wednesday at Soft Peaks in Gastown! Soft Peaks is known for using organic milk and their unique topics! For those with dairy related dietary needs who register we will have an alternative for you so don't feel left out! https://eventyay.com/events/231a963f From ildiko at openinfra.dev Thu Jun 1 19:16:57 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Thu, 1 Jun 2023 12:16:57 -0700 Subject: [Starlingx-discuss] TSC & Community call in the APAC-friendly time slot next week Message-ID: <3EDCFAEB-B651-4F10-9959-8182C926704A@openinfra.dev> Hi StarlingX Community, It is a friendly reminder that the TSC & Community call is happening in the APAC-friendly time slot next week! The call is scheduled to happen on June 7 at 7pm US Pacific Time / 10m pm US Eastern Time | June 8 at 0200 UTC / 10am China Standard Time. You can find dial-in information and further details here: https://wiki.openstack.org/wiki/Starlingx/Meetings#7pm_Pacific_on_Every_First_Wednesday_of_the_Month-_Technical_Steering_Committee_.26_Community_Call Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From Juanita.Balaraj at windriver.com Thu Jun 1 20:50:18 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Thu, 1 Jun 2023 20:50:18 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 31-05-2023 In-Reply-To: References: Message-ID: Hello All, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation Thanks, Juanita Balaraj ============ 31-May-23 Current StarlingX Release Stx 9.0 Release Tracking Spreadsheet: https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing. Created stories in Stx 9.0 related to doc updates submitted to the master branch. - AR Juanita to create additional stories for Features supported in Stx 9.0. (WIP) Gerrit Reviews: - Open Reviews pending; https://review.opendev.org/q/starlingx/docs+status:open - To be reviewed and merged - Merged ~9 reviews. (Focussed mainly on Gerrit Reviews) - Bruno Muniz / Gustavo Herzmann created a gerrit review to use the automated script for Vbox installs: To raise LP Bugs / Stories; https://storyboard.openstack.org/#!/story/2005051#comment-203593; Launchpad Doc Bugs: - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.docs Total 7 outstanding bugs - The DOC team to create LP defects corresponding with any DS defects - WIP. Teams to add all the impacted Releases when raising a LP bug Bug #2021896 "References to not supported Rook container-based C..." : Bugs : StarlingX (launchpad.net) - Bruno to check with Greg... Installation Virtual docs - Bruno to ask Greg at the community meeting or send an email Miscellaneous Updates: - Numbering in the Distributed Cloud Guide - AR Ron to check https://review.opendev.org/c/starlingx/docs/+/880085 - Ron to update the Verified H/W page with the automated script updates https://www.windriver.com/studio/operator/self-validated-and-certified-hosts# - Currently Commented out - Script needs to be updated- AR Ron General Updates: - Bruno Muniz showed interest in creating DOC Videos supporting the StarlingX Installation Process. To check with Ildiko / Greg whether this is ok. These Videos can be hosted in a location in StarlingX. The Installation Docs can point to these videos - AR Bruno / Juanita to get approvals from Ildiko / Greg - Sphinx Tools - Need to have further discussions about the version used upstream vs. downstream - AR Ron -To determine version. - Docker Container upstream / downstream - AR Ron (Discuss it with Greg / Ildiko) - Operations Guide Archive - On Hold until further clarifications are discussed with Greg (https://review.opendev.org/c/starlingx/docs/+/822030) - OpenInfra Summit & PTG: June 13-15, Vancouver, Canada - https://openinfra.dev/summit/vancouver-2023/; Schedule: https://vancouver2023.openinfra.dev/a/schedule Sessions: https://ptg.opendev.org/ptg.html - Workshop Details are tracked in https://etherpad.opendev.org/p/stx_hands_on_workshop_2023 - IRC: Everyone to use the IRC channel for communication with the community. Team can use https://www.icechat.net/site/icechat-9/ from their browser - The Doc Team will be moving their meeting on Wednesday 12.30 p.m. PST to Thursday 6.00 a.m. PST to meet Asia Pacific time zone effective July 2023. See https://wiki.openstack.org/wiki/Starlingx/Meetings for more details. Engineering Status: StarlingX Eng Stx Status: https://etherpad.opendev.org/p/stx-status StarlingX Eng Status 2023 https://etherpad.opendev.org/p/stx-cores ____________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Trevor.Tao at arm.com Fri Jun 2 02:48:18 2023 From: Trevor.Tao at arm.com (Trevor Tao) Date: Fri, 2 Jun 2023 02:48:18 +0000 Subject: [Starlingx-discuss] StarlingX engagement In-Reply-To: References: Message-ID: Hi Starlingx-discuss: Would you please also accept my subscription to the starlingx-discuss at list.starlingx.io mailing list? Thanks, Best Regards, Zijin Tao(Trevor Tao, ???) ARM Electronic Technology (Shanghai) Co., Ltd ?????????????? Building 11, Shanghai Busininess Park? , No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China ?????????1016???????2??10??200233 Cell: +86-153 7109 6192 -----Original Message----- From: Trevor Tao Sent: Thursday, May 25, 2023 3:55 PM To: Waines, Greg ; starlingx-discuss at lists.starlingx.io Cc: Outback Dingo ; Chris Wang ; Huang, Jie (Jackie) Subject: RE: [Starlingx-discuss] StarlingX engagement Hi Greg, StarlingX community: For the StarlingX arm enablement issue, we would like to ask about the support of Starlingx building infrastructure for arm platform. Could you provide the requirement or any suggestion for the building infrastructure for arm from the community side? After talking with Windriver guys, we imagine there would be 2 build servers and 4 testing servers, the initial required config for those servers that we thought of is listed below as a reference, but it may still be under discussion and support by our LoB and vendors since it still has gaps between the desired config here and their initial provision we got to know: 1. 2 Build servers configuration requirement, for each: ? 1 x Q64-30 processor ? 128G MEM ? 2 x 1T SSD storage ? 1 x 1GB onboard NIC 2. 4 testing servers configuration requirement, for each: ? 1 x Q64-30 processor ? 128G MEM ? 3 x 500G SSD storage ? 2 x 10GB ports on NIC (preferably Mellanox) ? 2 x 1GB Thanks for your support, Best Regards, Zijin Tao(Trevor Tao, ???) ARM Electronic Technology (Shanghai) Co., Ltd ?????????????? Building 11, Shanghai Busininess Park? , No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China ?????????1016???????2??10??200233 Cell: +86-153 7109 6192 -----Original Message----- From: Huang, Jie (Jackie) Sent: Tuesday, May 23, 2023 1:55 PM To: starlingx-discuss at lists.starlingx.io Cc: Waines, Greg ; Outback Dingo ; Trevor Tao Subject: RE: [Starlingx-discuss] StarlingX engagement Hi StarlingX community, As mentioned in the last call of the StarlingX OS Distro Project Meeting (Minutes: https://etherpad.opendev.org/p/stx-distro-other), I would like to share the development status of the work to support ARM, which I started three months ago: - It's a native build solution on HPE RL300 Gen11 server (Ampere Altra 1x80 cores) - All code changes are POC level with many hard-codes and workarounds. - Built out a bootable ISO image and tested deployment of AIO-SX and AIO-DX Detail status please refer to: https://github.com/jackiehjm/stx-builds/blob/master/docs/2023_stx_on_arm_status.md And as follow-up in the call, I have the following questions need to ask here: 1. For container images re-generated for ARM64 arch, how can I push them to docker hub https://hub.docker.com/u/starlingx? Or can I ask for help on creating all container images for ARM64 and push to docker hub automatically so all container images on https://hub.docker.com/u/starlingx will support both x86 and ARM64? 2. Pre-built packages for x86_64 are in CENGN as package mirror, how can push ARM packages there as well? Thanks, Jackie > -----Original Message----- > From: Outback Dingo > Sent: Wednesday, May 17, 2023 2:50 PM > To: Trevor Tao > Cc: Waines, Greg ; starlingx- > discuss at lists.starlingx.io; Huang, Jie (Jackie) > > Subject: Re: [Starlingx-discuss] StarlingX engagement > > might i also suggest a good start down that path might be to get > meta-stx to build for arm64 under yocto ?? > > On Wed, May 17, 2023 at 12:50?PM Trevor Tao wrote: > > > > Hi Greg: > > > > > > > > It?s glad to get your support and suggestion here, especially on the > > arm > support. > > > > I would attend the meeting if available. > > > > Thank you. > > > > > > > > Best Regards, > > > > > > > > Zijin Tao(Trevor Tao, ???) > > > > ARM Electronic Technology (Shanghai) Co., Ltd > > > > ?????????????? > > > > Building 11, Shanghai Busininess Park? , > > > > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > > > > ?????????1016???????2??10??200233 > > > > Cell: +86-153 7109 6192 > > > > > > > > From: Waines, Greg > > Sent: Monday, May 15, 2023 7:08 PM > > To: Trevor Tao ; > > starlingx-discuss at lists.starlingx.io > > Cc: Huang, Jie (Jackie) > > Subject: RE: StarlingX engagement > > > > > > > > Welcome Trevor. > > > > Thanks for your interest. Arm support is a topic that has come up a > > lot > recently in StarlingX discussions and one we are very interested in. > > > > > > > > I would suggest by starting to attend the Bi-Weekly StarlingX OS > > Distro > Project Meeting. > > > > I have attached the calendar event. > > > > > > > > Greg. > > > > > > > > From: Trevor Tao > > Sent: Friday, May 12, 2023 9:27 AM > > To: starlingx-discuss at lists.starlingx.io > > Cc: Huang, Jie (Jackie) > > Subject: [Starlingx-discuss] StarlingX engagement > > > > > > > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the > > sender and > know the content is safe. > > > > Hi StarlingX community: > > > > > > > > I am a software engineer from CE-OSS(Open Source Software) of Arm > > ltd, > now I would like to engage and give contribution in the development > work of StarlingX project and community. > > > > I am interested in StarlingX development, tests and especially the > porting/enablement work on arm, so I would like to know which working > groups would be best for me to join. > > > > > > > > Thanks, > > > > > > > > Best Regards, > > > > > > > > Zijin Tao(Trevor Tao, ???) > > > > ARM Electronic Technology (Shanghai) Co., Ltd > > > > ?????????????? > > > > Building 11, Shanghai Busininess Park? , > > > > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > > > > ?????????1016???????2??10??200233 > > > > Cell: +86-153 7109 6192 > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From amy at demarco.com Fri Jun 2 16:29:41 2023 From: amy at demarco.com (Amy Marrich) Date: Fri, 2 Jun 2023 11:29:41 -0500 Subject: [Starlingx-discuss] RDO Ice Cream Social at OpenInfra Summit - Correct link In-Reply-To: References: Message-ID: Sorry for the confusion, here is the correct link to register. https://eventyay.com/e/231a963f Looking forward to seeing everyone there! On Thu, Jun 1, 2023 at 12:32?PM Amy Marrich wrote: > > Join members of the community for ice cream after the Marketplace > Mixer on Wednesday at Soft Peaks in Gastown! Soft Peaks is known for > using organic milk and their unique topics! For those with dairy > related dietary needs who register we will have an alternative for you > so don't feel left out! > > https://eventyay.com/events/231a963f From ildiko at openinfra.dev Tue Jun 6 02:26:17 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Mon, 5 Jun 2023 19:26:17 -0700 Subject: [Starlingx-discuss] StarlingX engagement In-Reply-To: References: Message-ID: <58286014-C5D7-47C6-B2A7-0FE8836B2935@openinfra.dev> Hi Trevor, I just saw this email. The subscription process is automated. I will reach out to you directly to see where the issue might be. Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation > On Jun 1, 2023, at 19:48, Trevor Tao wrote: > > Hi Starlingx-discuss: > > Would you please also accept my subscription to the starlingx-discuss at list.starlingx.io mailing list? > Thanks, > > Best Regards, > > Zijin Tao(Trevor Tao, ???) > ARM Electronic Technology (Shanghai) Co., Ltd > ?????????????? > Building 11, Shanghai Busininess Park? , > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > ?????????1016???????2??10??200233 > Cell: +86-153 7109 6192 > > -----Original Message----- > From: Trevor Tao > Sent: Thursday, May 25, 2023 3:55 PM > To: Waines, Greg ; starlingx-discuss at lists.starlingx.io > Cc: Outback Dingo ; Chris Wang ; Huang, Jie (Jackie) > Subject: RE: [Starlingx-discuss] StarlingX engagement > > Hi Greg, StarlingX community: > > For the StarlingX arm enablement issue, we would like to ask about the support of Starlingx building infrastructure for arm platform. > Could you provide the requirement or any suggestion for the building infrastructure for arm from the community side? > > After talking with Windriver guys, we imagine there would be 2 build servers and 4 testing servers, the initial required config for those servers that we thought of is listed below as a reference, but it may still be under discussion and support by our LoB and vendors since it still has gaps between the desired config here and their initial provision we got to know: > > 1. 2 Build servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 2 x 1T SSD storage > ? 1 x 1GB onboard NIC > 2. 4 testing servers configuration requirement, for each: > ? 1 x Q64-30 processor > ? 128G MEM > ? 3 x 500G SSD storage > ? 2 x 10GB ports on NIC (preferably Mellanox) > ? 2 x 1GB > > Thanks for your support, > > Best Regards, > > Zijin Tao(Trevor Tao, ???) > ARM Electronic Technology (Shanghai) Co., Ltd > ?????????????? > Building 11, Shanghai Busininess Park? , > No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China > ?????????1016???????2??10??200233 > Cell: +86-153 7109 6192 > > -----Original Message----- > From: Huang, Jie (Jackie) > Sent: Tuesday, May 23, 2023 1:55 PM > To: starlingx-discuss at lists.starlingx.io > Cc: Waines, Greg ; Outback Dingo ; Trevor Tao > Subject: RE: [Starlingx-discuss] StarlingX engagement > > Hi StarlingX community, > > As mentioned in the last call of the StarlingX OS Distro Project Meeting (Minutes: https://etherpad.opendev.org/p/stx-distro-other), > I would like to share the development status of the work to support ARM, which I started three months ago: > - It's a native build solution on HPE RL300 Gen11 server (Ampere Altra 1x80 cores) > - All code changes are POC level with many hard-codes and workarounds. > - Built out a bootable ISO image and tested deployment of AIO-SX and AIO-DX > > Detail status please refer to: > https://github.com/jackiehjm/stx-builds/blob/master/docs/2023_stx_on_arm_status.md > > And as follow-up in the call, I have the following questions need to ask here: > 1. For container images re-generated for ARM64 arch, how can I push them to docker hub https://hub.docker.com/u/starlingx? > Or can I ask for help on creating all container images for ARM64 and push to docker hub automatically so all container images > on https://hub.docker.com/u/starlingx will support both x86 and ARM64? > 2. Pre-built packages for x86_64 are in CENGN as package mirror, how can push ARM packages there as well? > > Thanks, > Jackie > >> -----Original Message----- >> From: Outback Dingo >> Sent: Wednesday, May 17, 2023 2:50 PM >> To: Trevor Tao >> Cc: Waines, Greg ; starlingx- >> discuss at lists.starlingx.io; Huang, Jie (Jackie) >> >> Subject: Re: [Starlingx-discuss] StarlingX engagement >> >> might i also suggest a good start down that path might be to get >> meta-stx to build for arm64 under yocto ?? >> >> On Wed, May 17, 2023 at 12:50?PM Trevor Tao wrote: >>> >>> Hi Greg: >>> >>> >>> >>> It?s glad to get your support and suggestion here, especially on the >>> arm >> support. >>> >>> I would attend the meeting if available. >>> >>> Thank you. >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> From: Waines, Greg >>> Sent: Monday, May 15, 2023 7:08 PM >>> To: Trevor Tao ; >>> starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: RE: StarlingX engagement >>> >>> >>> >>> Welcome Trevor. >>> >>> Thanks for your interest. Arm support is a topic that has come up a >>> lot >> recently in StarlingX discussions and one we are very interested in. >>> >>> >>> >>> I would suggest by starting to attend the Bi-Weekly StarlingX OS >>> Distro >> Project Meeting. >>> >>> I have attached the calendar event. >>> >>> >>> >>> Greg. >>> >>> >>> >>> From: Trevor Tao >>> Sent: Friday, May 12, 2023 9:27 AM >>> To: starlingx-discuss at lists.starlingx.io >>> Cc: Huang, Jie (Jackie) >>> Subject: [Starlingx-discuss] StarlingX engagement >>> >>> >>> >>> CAUTION: This email comes from a non Wind River email account! >>> Do not click links or open attachments unless you recognize the >>> sender and >> know the content is safe. >>> >>> Hi StarlingX community: >>> >>> >>> >>> I am a software engineer from CE-OSS(Open Source Software) of Arm >>> ltd, >> now I would like to engage and give contribution in the development >> work of StarlingX project and community. >>> >>> I am interested in StarlingX development, tests and especially the >> porting/enablement work on arm, so I would like to know which working >> groups would be best for me to join. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Zijin Tao(Trevor Tao, ???) >>> >>> ARM Electronic Technology (Shanghai) Co., Ltd >>> >>> ?????????????? >>> >>> Building 11, Shanghai Busininess Park? , >>> >>> No.1016 Tianlin Rd, Minhang District, Shanghai, 200233 China >>> >>> ?????????1016???????2??10??200233 >>> >>> Cell: +86-153 7109 6192 >>> >>> >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io From ildiko at openinfra.dev Tue Jun 6 04:36:35 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Mon, 5 Jun 2023 21:36:35 -0700 Subject: [Starlingx-discuss] TSC & Community call in the APAC-friendly time slot this week In-Reply-To: <3EDCFAEB-B651-4F10-9959-8182C926704A@openinfra.dev> References: <3EDCFAEB-B651-4F10-9959-8182C926704A@openinfra.dev> Message-ID: <2DE757A7-E544-414E-9280-D9493CDF2033@openinfra.dev> Hi StarlingX Community, It is a friendly reminder that this week?s TSC & Community Call will be in the APAC friendly time slot. The call is scheduled to happen on June 7 at 7pm US Pacific Time / 10m pm US Eastern Time | June 8 at 0200 UTC / 10am China Standard Time. You can find dial-in information and further details here: https://wiki.openstack.org/wiki/Starlingx/Meetings#7pm_Pacific_on_Every_First_Wednesday_of_the_Month-_Technical_Steering_Committee_.26_Community_Call Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation > On Jun 1, 2023, at 12:16, Ildiko Vancsa wrote: > > Hi StarlingX Community, > > It is a friendly reminder that the TSC & Community call is happening in the APAC-friendly time slot next week! > > The call is scheduled to happen on June 7 at 7pm US Pacific Time / 10m pm US Eastern Time | June 8 at 0200 UTC / 10am China Standard Time. > > You can find dial-in information and further details here: https://wiki.openstack.org/wiki/Starlingx/Meetings#7pm_Pacific_on_Every_First_Wednesday_of_the_Month-_Technical_Steering_Committee_.26_Community_Call > > Best Regards, > Ildik? > > ??? > > Ildik? V?ncsa > Director of Community > Open Infrastructure Foundation > > > > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io From ildiko at openinfra.dev Tue Jun 6 15:00:15 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Tue, 6 Jun 2023 08:00:15 -0700 Subject: [Starlingx-discuss] [openstack] Cinder EM branches moving to EOL Message-ID: Hi StarlingX Community, I?m reaching out about a topic related to OpenStack, which came up earlier in the year. The Cinder team has been discussing to start to remove some of the Extended Maintenance (EM) branches, namely the ones before the Yoga release. They are still discussing the topic and looking for further feedback. You can find the mail thread with more details here: https://lists.openstack.org/pipermail/openstack-discuss/2023-June/033980.html If you have an input for that discussion, please reply to the above thread or reach out to the team in other ways. Their timeframe to make their decision is the week after next. Please note that the this change does not affect the code, it will still be accessible using tags. Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From Douglas.Pereira at windriver.com Tue Jun 6 16:32:10 2023 From: Douglas.Pereira at windriver.com (Pereira, Douglas) Date: Tue, 6 Jun 2023 16:32:10 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: References: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> Message-ID: Hi Davlet, based on the community feedback, can you go ahead and split the repositories? Regards, Doug ________________________________ From: Douglas Lopes Pereira Sent: Thursday, June 1, 2023 1:11 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 on 'deployment' Douglas Lopes Pereira Software Development Manager M: +55 (19) 99212-3212 Campinas, BR [Encora] [We are proud to be recognized as Leaders in digital engineering services by Zinnov zones] ________________________________ From: Scott.Little Sent: Thursday, June 1, 2023 12:29 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple You don't often get email from scott.little at eng.windriver.com. Learn why this is important External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peng.Peng at windriver.com Tue Jun 6 16:48:13 2023 From: Peng.Peng at windriver.com (Peng, Peng) Date: Tue, 6 Jun 2023 16:48:13 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20230604T060000Z Message-ID: Sanity Test from 2023 June 6th (https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230604T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso) Status: GREEN SX sanity Passed: 17 (100.0%) Failed: 0 (0.0%) Total Executed: 17 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_isolated_2p_2_big_pod_best_effort_HT_AIO PASS test_sriovdp_netdev_single_pod[1-1-lock/unlock] PASS test_sriovdp_netdev_connectivity_ipv4[1-1-calico-ipam] PASS test_sriovdp_mixed_add_vf_interface[1] PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] DX sanity Passed: 19 (100.0%) Failed: 0 (0.0%) Total Executed: 19 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_swact_controller_platform PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_push_docker_image_to_local_registry_standby PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_force_reboot_host[active_controller-True] PASS test_force_reboot_host[active_controller-False] PASS test_force_reboot_host[standby_controller-False] PASS test_bmc_verify_bm_type_ipmi PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] Regards, PV team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gabriel.CalixtodePaula at windriver.com Tue Jun 6 19:54:23 2023 From: Gabriel.CalixtodePaula at windriver.com (Calixto de Paula, Gabriel) Date: Tue, 6 Jun 2023 19:54:23 +0000 Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230604T060000Z] results - Jun-4 Message-ID: Hi all, StarlingX + STX-Openstack sanity and regression results: Overall status: RED Build Info: Build date: 4-Jun ISO: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230604T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso Helm Charts: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230604T060000Z/outputs/helm-charts/stx-openstack-1.0-1.stx.48-debian-stable-versioned.tgz We had a failed STX-Openstack apply on this StarlingX latest_build during the sanity execution, this might be related to the new changes on the platform and it's currently being investigated on : #2023085 - STX-Openstack | fails to apply - mariadb-server-1 pod in CrashLoopBackoff, regards, STX-Openstack Distro Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Davlet.Panech at windriver.com Wed Jun 7 13:05:10 2023 From: Davlet.Panech at windriver.com (Panech, Davlet) Date: Wed, 7 Jun 2023 13:05:10 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> References: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> Message-ID: We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config Good idea, but let's deal with integ first. ________________________________ From: Scott.Little Sent: June 1, 2023 11:29 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Wed Jun 7 13:12:59 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Wed, 7 Jun 2023 13:12:59 +0000 Subject: [Starlingx-discuss] Etherpad for inPerson PTG in Vancouver Message-ID: I have created an Etherpad for collecting Agenda Items for the inPerson PTG sessions in Vancouver. https://etherpad.opendev.org/p/stx-ptg-planning-june-2023 Please update etherpad with any items that you would like to discuss. Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Davlet.Panech at windriver.com Wed Jun 7 13:15:30 2023 From: Davlet.Panech at windriver.com (Panech, Davlet) Date: Wed, 7 Jun 2023 13:15:30 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: References: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> Message-ID: Good idea, but let's deal with integ first. I meant "deployment" ________________________________ From: Panech, Davlet Sent: June 7, 2023 9:05 AM To: starlingx-discuss at lists.starlingx.io ; Little, Scott Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config Good idea, but let's deal with integ first. ________________________________ From: Scott.Little Sent: June 1, 2023 11:29 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Wed Jun 7 20:13:52 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Wed, 7 Jun 2023 16:13:52 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 190 - Failure! Message-ID: <1829588831.373.1686168834762.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 190 Status: Failure Timestamp: 20230607T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230607T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From ildiko.vancsa at gmail.com Thu Jun 8 04:02:56 2023 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 7 Jun 2023 21:02:56 -0700 Subject: [Starlingx-discuss] Etherpad for inPerson PTG in Vancouver In-Reply-To: References: Message-ID: Hi Greg, Great, thank you! I added the ethrpad to the PTG page here: https://ptg.opendev.org/etherpads.html Best Regards, Ildik? > On Jun 7, 2023, at 06:12, Waines, Greg wrote: > > I have created an Etherpad for collecting Agenda Items for the inPerson PTG sessions in Vancouver. > > https://etherpad.opendev.org/p/stx-ptg-planning-june-2023 > > Please update etherpad with any items that you would like to discuss. > > Greg. > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io From ildiko at openinfra.dev Thu Jun 8 04:20:19 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Wed, 7 Jun 2023 21:20:19 -0700 Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep Message-ID: Hi StarlingX Community, As you know, the annual Open Infrastructure Summit[1] will happen next week (June 13-15), in Vancouver, Canada. The questions came up during today?s TSC & Community Call, that with the event happening, whether or not we would like to keep that and other meeting for next week? With a lot of activities and buzz around StarlingX, the conference will have a good number of contributors on site. To avoid conflicting with the conference, my suggestion would be to cancel next week?s TSC and Community Call (June 14), and reconvene the week after and include an overview and updates from the OpenInfra Summit. What do you think? Thanks and Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From starlingx.build at gmail.com Thu Jun 8 06:39:49 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Thu, 8 Jun 2023 02:39:49 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 191 - Still Failing! In-Reply-To: <194858596.371.1686168831367.JavaMail.javamailuser@localhost> References: <194858596.371.1686168831367.JavaMail.javamailuser@localhost> Message-ID: <1300827255.378.1686206390238.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 191 Status: Still Failing Timestamp: 20230608T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230608T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From Greg.Waines at windriver.com Thu Jun 8 10:44:49 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Thu, 8 Jun 2023 10:44:49 +0000 Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep In-Reply-To: References: Message-ID: +1 -----Original Message----- From: Ildiko Vancsa Sent: Thursday, June 8, 2023 12:20 AM To: StarlingX ML Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi StarlingX Community, As you know, the annual Open Infrastructure Summit[1] will happen next week (June 13-15), in Vancouver, Canada. The questions came up during today?s TSC & Community Call, that with the event happening, whether or not we would like to keep that and other meeting for next week? With a lot of activities and buzz around StarlingX, the conference will have a good number of contributors on site. To avoid conflicting with the conference, my suggestion would be to cancel next week?s TSC and Community Call (June 14), and reconvene the week after and include an overview and updates from the OpenInfra Summit. What do you think? Thanks and Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io From scott.kamp at xunison.com Thu Jun 8 10:55:13 2023 From: scott.kamp at xunison.com (Scott Kamp) Date: Thu, 8 Jun 2023 10:55:13 +0000 Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep In-Reply-To: References: Message-ID: +1 Get Outlook for Android ________________________________ From: Waines, Greg Sent: Thursday, June 8, 2023 5:44:49 PM To: Ildiko Vancsa ; StarlingX ML Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep +1 -----Original Message----- From: Ildiko Vancsa Sent: Thursday, June 8, 2023 12:20 AM To: StarlingX ML Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi StarlingX Community, As you know, the annual Open Infrastructure Summit[1] will happen next week (June 13-15), in Vancouver, Canada. The questions came up during today?s TSC & Community Call, that with the event happening, whether or not we would like to keep that and other meeting for next week? With a lot of activities and buzz around StarlingX, the conference will have a good number of contributors on site. To avoid conflicting with the conference, my suggestion would be to cancel next week?s TSC and Community Call (June 14), and reconvene the week after and include an overview and updates from the OpenInfra Summit. What do you think? Thanks and Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ramaswamy.Subramanian at windriver.com Thu Jun 8 12:58:32 2023 From: Ramaswamy.Subramanian at windriver.com (Subramanian, Ramaswamy) Date: Thu, 8 Jun 2023 12:58:32 +0000 Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep In-Reply-To: References: Message-ID: +1 From: Scott Kamp Sent: Thursday, June 8, 2023 6:55 AM To: Waines, Greg ; Ildiko Vancsa ; StarlingX ML Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 Get Outlook for Android ________________________________ From: Waines, Greg > Sent: Thursday, June 8, 2023 5:44:49 PM To: Ildiko Vancsa >; StarlingX ML > Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep +1 -----Original Message----- From: Ildiko Vancsa > Sent: Thursday, June 8, 2023 12:20 AM To: StarlingX ML > Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi StarlingX Community, As you know, the annual Open Infrastructure Summit[1] will happen next week (June 13-15), in Vancouver, Canada. The questions came up during today's TSC & Community Call, that with the event happening, whether or not we would like to keep that and other meeting for next week? With a lot of activities and buzz around StarlingX, the conference will have a good number of contributors on site. To avoid conflicting with the conference, my suggestion would be to cancel next week's TSC and Community Call (June 14), and reconvene the week after and include an overview and updates from the OpenInfra Summit. What do you think? Thanks and Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 --- Ildik? V?ncsa Director of Community Open Infrastructure Foundation _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.pereira at encora.com Fri Jun 9 10:59:42 2023 From: douglas.pereira at encora.com (Douglas Lopes Pereira) Date: Fri, 9 Jun 2023 10:59:42 +0000 Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep In-Reply-To: References: Message-ID: +1 Douglas Lopes Pereira Software Development Manager M: +55 (19) 99212-3212 Campinas, BR [Encora] [We are proud to be recognized as Leaders in digital engineering services by Zinnov zones] ________________________________ From: Subramanian, Ramaswamy Sent: Thursday, June 8, 2023 9:58 AM To: Scott Kamp ; Waines, Greg ; Ildiko Vancsa ; StarlingX ML Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep You don't often get email from ramaswamy.subramanian at windriver.com. Learn why this is important External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 From: Scott Kamp Sent: Thursday, June 8, 2023 6:55 AM To: Waines, Greg ; Ildiko Vancsa ; StarlingX ML Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 Get Outlook for Android ________________________________ From: Waines, Greg > Sent: Thursday, June 8, 2023 5:44:49 PM To: Ildiko Vancsa >; StarlingX ML > Subject: Re: [Starlingx-discuss] TSC & Community Call next week - cancel or keep +1 -----Original Message----- From: Ildiko Vancsa > Sent: Thursday, June 8, 2023 12:20 AM To: StarlingX ML > Subject: [Starlingx-discuss] TSC & Community Call next week - cancel or keep CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi StarlingX Community, As you know, the annual Open Infrastructure Summit[1] will happen next week (June 13-15), in Vancouver, Canada. The questions came up during today?s TSC & Community Call, that with the event happening, whether or not we would like to keep that and other meeting for next week? With a lot of activities and buzz around StarlingX, the conference will have a good number of contributors on site. To avoid conflicting with the conference, my suggestion would be to cancel next week?s TSC and Community Call (June 14), and reconvene the week after and include an overview and updates from the OpenInfra Summit. What do you think? Thanks and Best Regards, Ildik? [1] https://openinfra.dev/summit/vancouver-2023 ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Sun Jun 11 00:10:37 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Sat, 10 Jun 2023 20:10:37 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 3729 - Failure! Message-ID: <464297462.391.1686442239722.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 3729 Status: Failure Timestamp: 20230611T001025Z Branch: Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230610T230000Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/rc-7.0-compiler/20230610T230000Z DOCKER_BUILD_ID: jenkins-rc-7.0-compiler-20230610T230000Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/rc-7.0-compiler/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230610T230000Z/logs BUILD_IMG: false FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/rc/7.0/centos/compiler/20230610T230000Z/logs MASTER_JOB_NAME: STX_7.0_build_layer_compiler LAYER: compiler MY_REPO_ROOT: /localdisk/designer/jenkins/rc-7.0-compiler BUILD_ISO: false From starlingx.build at gmail.com Sun Jun 11 00:10:41 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Sat, 10 Jun 2023 20:10:41 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] r/stx.7.0 STX_7.0_build_layer_compiler - Build # 52 - Failure! Message-ID: <328515548.394.1686442242205.JavaMail.javamailuser@localhost> Project: STX_7.0_build_layer_compiler Build #: 52 Status: Failure Timestamp: 20230610T230000Z Branch: r/stx.7.0 Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230610T230000Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: true From ildiko at openinfra.dev Mon Jun 12 21:37:02 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Mon, 12 Jun 2023 14:37:02 -0700 Subject: [Starlingx-discuss] TSC & Community Call this week - CANCELED Message-ID: <60874CA5-70A2-4954-94ED-04F6E8C93D0B@openinfra.dev> Hi StarlingX Community, Based on the community?s preference, we are canceling this week?s (June 14) TSC & Community call due to its overlap with the OpenInfra Summit. The next TSC & Community call will happen next Wednesday (June 21) at 7am PST / 1300 UTC. You can find more information about the call here: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_Pacific_-_Technical_Steering_Committee_.26_Community_Call Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From ThalesElero.Cervi at windriver.com Tue Jun 6 18:26:31 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Tue, 6 Jun 2023 18:26:31 +0000 Subject: [Starlingx-discuss] Minutes: OpenStack Distro Team Call (June 06, 2023) Message-ID: Etherpad: https://etherpad.opendev.org/p/stx-distro-openstack-meetings Minutes from the OpenStack Distro team call June 06, 2023 Build Issues: None Installation Issues: # LP 2021672: STX-Openstack | fails to apply - yaml.load() require positional argument Loader - Fix Released: starlingx/master/debian/monolithic/20230601T060000Z/outputs/CHANGELOG.txt # LP 2023085: STX-Openstack | fails to apply - mariadb-server-1 pod in CrashLoopBackoff - In progress Debian Migration Tech Debt: # LP 2008124: DPDK support check broken with OVS-DPDK on Debian - In progress Sanity with stx-openstack (main branch): - Last Successful Execution: 05/22/2023: AIO-DX Baremetal with VSWITCH_TYPE=OVS - Overall status: GREEN ???? Sanity - Passed: 14 (93.33%) | Failed: 1 (6.67%) ??????Regression - Passed: 14 (100.00%) | Failed: 0 (0.00%) - Last execution trials: - 05/28/2023: Installation failed due to bug/2021672 - Fix was already released - 06/06/2023: Installation failed due to bug/2023085 - Open Launchpads: ??????bug/2012389: Will be selected for investigation soon. ??????bug/2007303: Will be selected for investigation soon. - StarlingX 9.0 Release: Created Storyboard/Tasks for OpenStack upversion (Antelope) - https://storyboard.openstack.org/#!/story/2010715 STX TSC chose to align release dates to accommodate the "Openstack services upversion: Ussuri -> Antelope" feature - stx.9.0 Release re-forecasted to: 10/18/2023 Best Regards, Thales -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.schmitt at starlab.io Mon Jun 12 21:59:19 2023 From: richard.schmitt at starlab.io (Richard Schmitt) Date: Mon, 12 Jun 2023 21:59:19 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX Message-ID: ?Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8404 bytes Desc: not available URL: From ildiko at openinfra.dev Mon Jun 12 23:25:31 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Mon, 12 Jun 2023 16:25:31 -0700 Subject: [Starlingx-discuss] StarlingX at the PTG on June 14 - remote participation Message-ID: <72724965-2DD7-44E4-A74A-42646721BD74@openinfra.dev> Hi StarlingX Community, I?m reaching out to you about the Project Teams Gathering (PTG) event, that will run in parallel to the Open Infrastructure Summit this week, as a co-located event. The StarlingX community booked a slot for Wednesday (June 14) afternoon at 2:30pm - 4:30pm PST. The PTG is primarily organized as an in-person event, where project teams will share a bigger room for their sessions. In an attempt to be as inclusive as possible, we will try to use the regular Zoom bridge, we use for the weekly meetings, to provide a possibility for remote participation. The Zoom bridge details are the following: * https://zoom.us/j/342730236?pwd=N21CUXNXVlJXMlcyZjZ0SE96cVNjQT09 * Dialing in from phone: - Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 - Meeting ID: 342 730 236 - Passcode: 419405 - International numbers available: https://zoom.us/u/ed95sU7aQ We will also discuss updates from the OpenInfra Summit and PTG at the Community Call next week (June 21). Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From Gabriel.CalixtodePaula at windriver.com Tue Jun 13 13:41:59 2023 From: Gabriel.CalixtodePaula at windriver.com (Calixto de Paula, Gabriel) Date: Tue, 13 Jun 2023 13:41:59 +0000 Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230611T060000Z] results - Jun-11 Message-ID: Hi all, StarlingX + STX-Openstack sanity and regression results: Overall status: Build Info: Build date: 11-Jun ISO: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230611T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso Helm Charts: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230611T060000Z/outputs/helm-charts/stx-openstack-1.0-1.stx.49-debian-stable-versioned.tgz AIO-DX Baremetal with VSWITCH_TYPE=OVS Sanity Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 15 (100.00%) Failed: 0 (0.00%) Total Executed: 15 List of Test Cases: ------------------------------------------------------ PASS??20230613 06:34:39?test_ssh_to_hosts PASS??20230613 06:36:02?test_lock_unlock_host PASS??20230613 06:55:50?test_openstack_services_healthy PASS??20230613 06:56:51?test_reapply_stx_openstack_no_change[controller-0] PASS??20230613 06:58:35?test_reapply_stx_openstack_no_change[controller-1] PASS??20230613 07:07:11?test_horizon_create_delete_instance PASS??20230613 07:10:19?test_swact_controllers PASS??20230613 07:17:43?test_ping_between_two_vms[tis-centos-guest-virtio-virtio] PASS??20230613 07:24:13?test_migrate_vm[tis-centos-guest-live-None] PASS??20230613 07:29:05?test_nova_actions[tis-centos-guest-dedicated-pause-unpause] PASS??20230613 07:33:37?test_nova_actions[tis-centos-guest-dedicated-suspend-resume] PASS??20230613 07:37:55?test_evacuate_vms PASS??20230613 08:09:59?test_system_coredumps_and_crashes[core_dumps] PASS??20230613 08:10:16?test_system_coredumps_and_crashes[crash_reports] PASS??20230613 08:10:23?test_system_alarms ----------------------------------------------------------------------- We'd like to point out that there is a Launchpad open for the TC test_reapply_stx_openstack_no_change[controller-1] : STX-O| config-out-of-date alarm won't disappear on controller-1 after swact and reapplying app This TC is passing on a re-run. Regression Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 12 (100.0%) Failed: 0 (0.0%) Total Executed: 12 List of Test Cases: ------------------------------------------------------ PASS 20230613 08:16:30 test_lldp_neighbor_remote_port PASS 20230613 08:17:56 test_kernel_module_signatures PASS 20230613 08:18:54 test_delete_heat_after_swact[OS_Cinder_Volume.yaml] PASS 20230613 08:23:28 test_multiports_on_same_network_vm_actions[virtio_x4] PASS 20230613 08:42:19 test_cpu_pol_vm_actions[2-dedicated-image-volume] PASS 20230613 08:54:35 test_vm_mem_pool_default_config[2048] PASS 20230613 08:57:26 test_vm_mem_pool_default_config[1048576] PASS 20230613 09:03:07 test_resize_vm_positive[local_image-4_1_512-5_2_1024-image] PASS 20230613 09:10:06 test_server_group_boot_vms[affinity-2] PASS 20230613 09:15:19 test_server_group_boot_vms[anti_affinity-2] PASS 20230613 09:20:47 test_vm_with_config_drive PASS 20230613 09:43:14 test_lock_with_vms ----------------------------------------------------------------------- regards, STX-Openstack Distro Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gabriel.CalixtodePaula at windriver.com Tue Jun 13 13:43:52 2023 From: Gabriel.CalixtodePaula at windriver.com (Calixto de Paula, Gabriel) Date: Tue, 13 Jun 2023 13:43:52 +0000 Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230611T060000Z] results - Jun-11 In-Reply-To: References: Message-ID: Hi all, Correction on last email: StarlingX + STX-Openstack sanity and regression results: Overall status: GREEN Regards STX Openstack Distro Team ________________________________ From: Calixto de Paula, Gabriel Sent: Tuesday, June 13, 2023 10:41 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230611T060000Z] results - Jun-11 Hi all, StarlingX + STX-Openstack sanity and regression results: Overall status: Build Info: Build date: 11-Jun ISO: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230611T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso Helm Charts: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230611T060000Z/outputs/helm-charts/stx-openstack-1.0-1.stx.49-debian-stable-versioned.tgz AIO-DX Baremetal with VSWITCH_TYPE=OVS Sanity Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 15 (100.00%) Failed: 0 (0.00%) Total Executed: 15 List of Test Cases: ------------------------------------------------------ PASS??20230613 06:34:39?test_ssh_to_hosts PASS??20230613 06:36:02?test_lock_unlock_host PASS??20230613 06:55:50?test_openstack_services_healthy PASS??20230613 06:56:51?test_reapply_stx_openstack_no_change[controller-0] PASS??20230613 06:58:35?test_reapply_stx_openstack_no_change[controller-1] PASS??20230613 07:07:11?test_horizon_create_delete_instance PASS??20230613 07:10:19?test_swact_controllers PASS??20230613 07:17:43?test_ping_between_two_vms[tis-centos-guest-virtio-virtio] PASS??20230613 07:24:13?test_migrate_vm[tis-centos-guest-live-None] PASS??20230613 07:29:05?test_nova_actions[tis-centos-guest-dedicated-pause-unpause] PASS??20230613 07:33:37?test_nova_actions[tis-centos-guest-dedicated-suspend-resume] PASS??20230613 07:37:55?test_evacuate_vms PASS??20230613 08:09:59?test_system_coredumps_and_crashes[core_dumps] PASS??20230613 08:10:16?test_system_coredumps_and_crashes[crash_reports] PASS??20230613 08:10:23?test_system_alarms ----------------------------------------------------------------------- We'd like to point out that there is a Launchpad open for the TC test_reapply_stx_openstack_no_change[controller-1] : STX-O| config-out-of-date alarm won't disappear on controller-1 after swact and reapplying app This TC is passing on a re-run. Regression Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 12 (100.0%) Failed: 0 (0.0%) Total Executed: 12 List of Test Cases: ------------------------------------------------------ PASS 20230613 08:16:30 test_lldp_neighbor_remote_port PASS 20230613 08:17:56 test_kernel_module_signatures PASS 20230613 08:18:54 test_delete_heat_after_swact[OS_Cinder_Volume.yaml] PASS 20230613 08:23:28 test_multiports_on_same_network_vm_actions[virtio_x4] PASS 20230613 08:42:19 test_cpu_pol_vm_actions[2-dedicated-image-volume] PASS 20230613 08:54:35 test_vm_mem_pool_default_config[2048] PASS 20230613 08:57:26 test_vm_mem_pool_default_config[1048576] PASS 20230613 09:03:07 test_resize_vm_positive[local_image-4_1_512-5_2_1024-image] PASS 20230613 09:10:06 test_server_group_boot_vms[affinity-2] PASS 20230613 09:15:19 test_server_group_boot_vms[anti_affinity-2] PASS 20230613 09:20:47 test_vm_with_config_drive PASS 20230613 09:43:14 test_lock_with_vms ----------------------------------------------------------------------- regards, STX-Openstack Distro Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Juanita.Balaraj at windriver.com Tue Jun 13 14:13:48 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Tue, 13 Jun 2023 14:13:48 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 07-06-2023 In-Reply-To: References: Message-ID: Hello All, Here are last week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation Thanks, Juanita Balaraj ============ 07-June-23 Current StarlingX Release Stx 9.0 Release Tracking Spreadsheet: Doc Stories are tracked in https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing. Gerrit Reviews: - Open Reviews pending; https://review.opendev.org/q/starlingx/docs+status:open - To be reviewed and merged - Merged ~5 reviews. - Bruno Muniz / Gustavo Herzmann created a gerrit review to use the automated script for Vbox installs: To raise LP Bugs / Stories; https://storyboard.openstack.org/#!/story/2005051#comment-203593; Launchpad Doc Bugs: - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.docs Total 7 outstanding bugs - The DOC team to create LP defects corresponding with any DS defects - WIP. Teams to add all the impacted Releases when raising a LP bug - Bug #2021896 "References to not supported Rook container-based C..." : Bugs : StarlingX (launchpad.net) - Bruno to check with Greg... Miscellaneous Updates: - Ron to update the Verified H/W page with the automated script updates https://www.windriver.com/studio/operator/self-validated-and-certified-hosts# - Currently Commented out - Script needs to be updated- AR Ron - Installation Virtual docs - Bruno to ask Greg at the community meeting or send an email General Updates: - As far as discussions go the OpenDev team meets regularly in #opendev-meeting (on the OFTC IRC network) on Tuesdays at 19:00 UTC. We also have the #opendev IRC channel and service-discuss at lists.opendev.org mailing list. Similarly Zuul has the https://matrix.to/#/#zuul:opendev.org Matrix room and zuul-discuss at lists.zuul-ci.org mailing list. - Bruno Muniz showed interest in creating DOC Videos supporting the StarlingX Installation Process. To check with Ildiko / Greg whether this is ok. These Videos can be hosted in a location in StarlingX. The Installation Docs can point to these videos - AR Bruno to get approvals from Ildiko / Greg - Sphinx Tools - Need to have further discussions about the version used upstream vs. downstream - AR Ron -To determine version. - Docker Container upstream / downstream - AR Ron (Discuss it with Greg / Ildiko) - Operations Guide Archive - On Hold until further clarifications are discussed with Greg (https://review.opendev.org/c/starlingx/docs/+/822030) - OpenInfra Summit & PTG: June 13-15, Vancouver, Canada - https://openinfra.dev/summit/vancouver-2023/; Schedule: https://vancouver2023.openinfra.dev/a/schedule Sessions: https://ptg.opendev.org/ptg.html - Workshop Details are tracked in https://etherpad.opendev.org/p/stx_hands_on_workshop_2023 - IRC: Everyone to use the IRC channel for communication with the community. Team can use https://www.icechat.net/site/icechat-9/ as an alternate text editor from their browser. IRC is a chat platform, for text-based communication. There's a web client for easy access: https://webchat.oftc.net/- You need to pick a nickname, and the channel name is #opendev. Once you are in the #opendev channel, you can talk to the group of people in that channel. To Setup IRC - contributor-guide documentation (openstack.org) IRC here: https://docs.openstack.org/contributors/common/irc.html; The Doc Team will be moving their meeting on Wednesday 12.30 p.m. PST to Thursday 6.00 a.m. PST to meet Asia Pacific time zone effective July 2023. See https://wiki.openstack.org/wiki/Starlingx/Meetings for more details. Engineering Status: StarlingX Eng Stx Status: https://etherpad.opendev.org/p/stx-status StarlingX Eng Status 2023 https://etherpad.opendev.org/p/stx-cores ____________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Tue Jun 13 20:38:49 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Tue, 13 Jun 2023 16:38:49 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 196 - Failure! Message-ID: <1556301598.401.1686688731062.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 196 Status: Failure Timestamp: 20230613T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230613T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From starlingx.build at gmail.com Wed Jun 14 06:25:39 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Wed, 14 Jun 2023 02:25:39 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 197 - Still Failing! In-Reply-To: <39131303.399.1686688727715.JavaMail.javamailuser@localhost> References: <39131303.399.1686688727715.JavaMail.javamailuser@localhost> Message-ID: <1261119348.406.1686723940121.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 197 Status: Still Failing Timestamp: 20230614T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230614T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From Juanita.Balaraj at windriver.com Thu Jun 15 15:08:55 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Thu, 15 Jun 2023 15:08:55 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 15/16-06-2023 In-Reply-To: References: Message-ID: Hello All, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings Please Note: From July 1st week we will be switching over to Stx Doc Team meetings on Thursdays 6.00 a.m. PST. See Starlingx/Meetings - OpenStack for more details. [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation Thanks, Juanita Balaraj ============ 15 / 16th-June-23 Current StarlingX Release Stx 9.0 Release Tracking Spreadsheet: Doc Stories are tracked in https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing. Gerrit Reviews: - Open Reviews pending; https://review.opendev.org/q/starlingx/docs+status:open - To be reviewed and merged - Merged ~2 reviews. - Bruno Muniz / Gustavo Herzmann created a gerrit review to use the automated script for Vbox installs: To raise LP Bugs / Stories; https://storyboard.openstack.org/#!/story/2005051#comment-203593; Launchpad Doc Bugs: - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.docs Total 9 outstanding bugs - The DOC team to create LP defects corresponding with any DS defects - WIP. Teams to add all the impacted Releases when raising a LP bug - Bug #2021896 "References to not supported Rook container-based C..." : Bugs : StarlingX (launchpad.net) - Bruno to check with Greg Miscellaneous Updates: - Ron to update the Verified H/W page with the automated script updates https://www.windriver.com/studio/operator/self-validated-and-certified-hosts# - Currently Commented out - Script needs to be updated- AR Ron - Installation Virtual docs - Bruno to ask Greg at the community meeting or send an email General Updates: - As far as discussions go the OpenDev team meets regularly in #opendev-meeting (on the OFTC IRC network) on Tuesdays at 19:00 UTC. We also have the #opendev IRC channel and service-discuss at lists.opendev.org mailing list. Similarly Zuul has the https://matrix.to/#/#zuul:opendev.org Matrix room and zuul-discuss at lists.zuul-ci.org mailing list. - Bruno Muniz showed interest in creating DOC Videos supporting the StarlingX Installation Process. To check with Ildiko / Greg whether this is ok. These Videos can be hosted in a location in StarlingX. The Installation Docs can point to these videos - AR Bruno to get approvals from Ildiko / Greg - Sphinx Tools - Need to have further discussions about the version used upstream vs. downstream - AR Ron -To determine version. - Docker Container upstream / downstream - AR Ron (Discuss it with Greg / Ildiko) - Operations Guide Archive - On Hold until further clarifications are discussed with Greg (https://review.opendev.org/c/starlingx/docs/+/822030) - OpenInfra Summit & PTG: June 13-15, Vancouver, Canada - https://openinfra.dev/summit/vancouver-2023/; Schedule: https://vancouver2023.openinfra.dev/a/schedule Sessions: https://ptg.opendev.org/ptg.html - Workshop Details are tracked in https://etherpad.opendev.org/p/stx_hands_on_workshop_2023 - IRC: Everyone to use the IRC channel for communication with the community. Team can use https://www.icechat.net/site/icechat-9/ as an alternate text editor from their browser. IRC is a chat platform, for text-based communication. There's a web client for easy access: https://webchat.oftc.net/- You need to pick a nickname, and the channel name is #opendev. Once you are in the #opendev channel, you can talk to the group of people in that channel. To Setup IRC - contributor-guide documentation (openstack.org) IRC here: https://docs.openstack.org/contributors/common/irc.html; The Doc Team will be moving their meeting on Wednesday 12.30 p.m. PST to Thursday 6.00 a.m. PST to meet Asia Pacific time zone effective July 2023. See https://wiki.openstack.org/wiki/Starlingx/Meetings for more details. Engineering Status: StarlingX Eng Stx Status: https://etherpad.opendev.org/p/stx-status StarlingX Eng Status 2023 https://etherpad.opendev.org/p/stx-cores ____________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Fri Jun 16 01:19:06 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 16 Jun 2023 01:19:06 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX In-Reply-To: References: Message-ID: Hey Richard ? sorry for the slow reply ? This is the right place to ask. I am not totally sure what you mean by ?We want to create user alarms in OpenStack.? * What software specifically do you want to generate alarms related to what specific fault conditions ? Some other background on alarms in StarlingX: * StarlingX Platform has a Fault Management system of its own * It is used by StarlingX Platform?s Infrastructure Services to raise alarms and logs related to fault conditions detected by StarlingX Platform?s Infrastructure Services * These alarms / logs are stored in a historical event (alarm or log) db * And an active alarm db is maintained to show alarms that are currently present within StarlingX * The historical event db and the active alarm db can be displayed thru * the starlingx API/CLI ?fm?, and * the starlingx horizon, on the Fault Management page * There is an internal developer?s API for FM for people coding StarlingX Platform Infrastructure Services code to raise and clear alarms/logs * Likely not documented well ? other than in the code (lol) * Let me know if this is what you are looking for * StarlingX OpenStack ? i.e. the containerized openstack solution * You?re right that the only pure openstack alarming that I am aware of is via aodh which does alarm thresholding of statistics collected by openstack telemetry / gnoochi ? which StarlingX OpenStack doesn?t fully support anymore ? we let it go stale and need to fix it * ? * However there is a StarlingX OpenStack VIM component that lives in the gray area between the StarlingX Platform on the host and StarlingX OpenStack in containers ? * One of the things VIM does, is watch openstack events and raises FM alarms and logs for many openstack events * I believe this is still operational and working today * At one time we were working on cloning FM and having a StarlingX Platform FM and a StarlingX OpenStack FM ? but I don?t believe that ever got completed. Anyways ? let me know if this helps, Greg From: Richard Schmitt Sent: Monday, June 12, 2023 5:59 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Question about alarms in StarlingX Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Fri Jun 16 06:33:37 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Fri, 16 Jun 2023 02:33:37 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 199 - Failure! Message-ID: <1078052465.414.1686897218467.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 199 Status: Failure Timestamp: 20230616T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230616T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From ThalesElero.Cervi at windriver.com Fri Jun 16 14:01:40 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Fri, 16 Jun 2023 14:01:40 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application Message-ID: 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lucas.DeAtaidesBarreto at windriver.com Fri Jun 16 15:51:02 2023 From: Lucas.DeAtaidesBarreto at windriver.com (De Ataides Barreto, Lucas) Date: Fri, 16 Jun 2023 15:51:02 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: +1 for splitting the manifests. It gives STX-Openstack the freedom to upversion and maintain its packages without affecting the platform side. ________________________________ From: Cervi, Thales Elero Sent: Friday, June 16, 2023 11:01 AM To: StarlingX ML 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From scott.kamp at xunison.com Sat Jun 17 00:39:14 2023 From: scott.kamp at xunison.com (Scott Kamp) Date: Sat, 17 Jun 2023 00:39:14 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: +1 Get Outlook for Android ________________________________ From: De Ataides Barreto, Lucas Sent: Friday, June 16, 2023 10:51:02 PM To: starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 for splitting the manifests. It gives STX-Openstack the freedom to upversion and maintain its packages without affecting the platform side. ________________________________ From: Cervi, Thales Elero Sent: Friday, June 16, 2023 11:01 AM To: StarlingX ML 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Church at windriver.com Sat Jun 17 01:26:51 2023 From: Robert.Church at windriver.com (Church, Robert) Date: Sat, 17 Jun 2023 01:26:51 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: +1 From: Scott Kamp Date: Friday, June 16, 2023 at 7:43 PM To: De Ataides Barreto, Lucas , starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 Get Outlook for Android ________________________________ From: De Ataides Barreto, Lucas Sent: Friday, June 16, 2023 10:51:02 PM To: starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 for splitting the manifests. It gives STX-Openstack the freedom to upversion and maintain its packages without affecting the platform side. ________________________________ From: Cervi, Thales Elero Sent: Friday, June 16, 2023 11:01 AM To: StarlingX ML 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Sun Jun 18 00:16:22 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Sat, 17 Jun 2023 20:16:22 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 3733 - Failure! Message-ID: <520790562.422.1687047383495.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 3733 Status: Failure Timestamp: 20230618T001605Z Branch: Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230617T230001Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/rc-7.0-compiler/20230617T230001Z DOCKER_BUILD_ID: jenkins-rc-7.0-compiler-20230617T230001Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/rc-7.0-compiler/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230617T230001Z/logs BUILD_IMG: false FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/rc/7.0/centos/compiler/20230617T230001Z/logs MASTER_JOB_NAME: STX_7.0_build_layer_compiler LAYER: compiler MY_REPO_ROOT: /localdisk/designer/jenkins/rc-7.0-compiler BUILD_ISO: false From starlingx.build at gmail.com Sun Jun 18 00:16:25 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Sat, 17 Jun 2023 20:16:25 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] r/stx.7.0 STX_7.0_build_layer_compiler - Build # 53 - Still Failing! In-Reply-To: <1224467681.392.1686442240321.JavaMail.javamailuser@localhost> References: <1224467681.392.1686442240321.JavaMail.javamailuser@localhost> Message-ID: <1711923181.425.1687047386229.JavaMail.javamailuser@localhost> Project: STX_7.0_build_layer_compiler Build #: 53 Status: Still Failing Timestamp: 20230617T230001Z Branch: r/stx.7.0 Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/centos/compiler/20230617T230001Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: true From Greg.Waines at windriver.com Sun Jun 18 10:47:55 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Sun, 18 Jun 2023 10:47:55 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX In-Reply-To: References: Message-ID: Ah ok ? Yeah in StarlingX / Kubernetes environment, it is the StarlingX Infrastructure / Flock Services that is responsible for management of the baremetal servers and platform software running on it. So it would make sense for the software that you are proposing to use StarlingX FM APIs to generate these alarms/logs. They would then be visible to the end user thru StarlingX Horizon GUI, StarlingX FM CLI/API and optionally SNMP. Although, you?re probably aware that StarlingX does support running Linux Auditd which also detects and logs security violation events ? with configurable auditd.rules. The logs by default go to /var/log/audit/audit.log ?. i.e. they are not currently forwarded to StarlingX FM. Does the software that you are thinking of contributing provide different capability than Linux Auditd ? Greg. From: Richard Schmitt Sent: Friday, June 16, 2023 10:11 AM To: Waines, Greg ; starlingx-discuss at lists.starlingx.io Subject: Re: Question about alarms in StarlingX Thanks for the detailed answer. Let me answer the question, ?What software specifically do you want to generate alarms?? We have software that monitors security events associated with the Linux kernel that we would like to expose to the cloud platform. These security events get logged to journald which in turn is picked up by syslog. We would make a syslog rule that selects these specific audit events and outputs them to a named pipe. We?d run a service on each node that would read from this pipe, massage the syslog message, and, our hope, would be to create an alarm within StarlingX that represents that security event. That?s really the crux of my question. I?ve read that Kubernetes generally does not handle platform events yet we are exploring a requirement that these security alarms be exposed to the cloud admin through the Horizon web GUI. I?m trying to understand if this is possible. Again, thanks for taking the time to read my question and help. Rich From: Waines, Greg > Date: Thursday, June 15, 2023 at 8:19 PM To: Richard Schmitt >, starlingx-discuss at lists.starlingx.io > Subject: RE: Question about alarms in StarlingX [EXTERNAL SENDER] Hey Richard ? sorry for the slow reply ? This is the right place to ask. I am not totally sure what you mean by ?We want to create user alarms in OpenStack.? * What software specifically do you want to generate alarms related to what specific fault conditions ? Some other background on alarms in StarlingX: * StarlingX Platform has a Fault Management system of its own * It is used by StarlingX Platform?s Infrastructure Services to raise alarms and logs related to fault conditions detected by StarlingX Platform?s Infrastructure Services * These alarms / logs are stored in a historical event (alarm or log) db * And an active alarm db is maintained to show alarms that are currently present within StarlingX * The historical event db and the active alarm db can be displayed thru * the starlingx API/CLI ?fm?, and * the starlingx horizon, on the Fault Management page * There is an internal developer?s API for FM for people coding StarlingX Platform Infrastructure Services code to raise and clear alarms/logs * Likely not documented well ? other than in the code (lol) * Let me know if this is what you are looking for * StarlingX OpenStack ? i.e. the containerized openstack solution * You?re right that the only pure openstack alarming that I am aware of is via aodh which does alarm thresholding of statistics collected by openstack telemetry / gnoochi ? which StarlingX OpenStack doesn?t fully support anymore ? we let it go stale and need to fix it * ? * However there is a StarlingX OpenStack VIM component that lives in the gray area between the StarlingX Platform on the host and StarlingX OpenStack in containers ? * One of the things VIM does, is watch openstack events and raises FM alarms and logs for many openstack events * I believe this is still operational and working today * At one time we were working on cloning FM and having a StarlingX Platform FM and a StarlingX OpenStack FM ? but I don?t believe that ever got completed. Anyways ? let me know if this helps, Greg From: Richard Schmitt > Sent: Monday, June 12, 2023 5:59 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Question about alarms in StarlingX Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Sun Jun 18 10:49:20 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Sun, 18 Jun 2023 10:49:20 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX In-Reply-To: References: Message-ID: K, np. I did have a question ?. you?re probably aware that StarlingX does support running Linux Auditd which also detects and logs security violation events ? with configurable auditd.rules. The logs by default go to /var/log/audit/audit.log ?. i.e. they are not currently forwarded to StarlingX FM. Does the software that you are thinking of contributing provide different capability than Linux Auditd ? Greg. From: Richard Schmitt Sent: Friday, June 16, 2023 4:28 PM To: Waines, Greg ; starlingx-discuss at lists.starlingx.io Subject: Re: Question about alarms in StarlingX Just an FYI. I kind of figured things out. There?s an api called ?fm_api? that let?s you instantiate a class FaultAPIv2 and call set_fault. This will add an Event to the Horizon Fault Manager, Event List. That?s essentially what I want. So, I figure I?d thank you for looking into this but also let you know that I probably have what I want. Thanks, Rich From: Waines, Greg > Date: Thursday, June 15, 2023 at 8:19 PM To: Richard Schmitt >, starlingx-discuss at lists.starlingx.io > Subject: RE: Question about alarms in StarlingX [EXTERNAL SENDER] Hey Richard ? sorry for the slow reply ? This is the right place to ask. I am not totally sure what you mean by ?We want to create user alarms in OpenStack.? * What software specifically do you want to generate alarms related to what specific fault conditions ? Some other background on alarms in StarlingX: * StarlingX Platform has a Fault Management system of its own * It is used by StarlingX Platform?s Infrastructure Services to raise alarms and logs related to fault conditions detected by StarlingX Platform?s Infrastructure Services * These alarms / logs are stored in a historical event (alarm or log) db * And an active alarm db is maintained to show alarms that are currently present within StarlingX * The historical event db and the active alarm db can be displayed thru * the starlingx API/CLI ?fm?, and * the starlingx horizon, on the Fault Management page * There is an internal developer?s API for FM for people coding StarlingX Platform Infrastructure Services code to raise and clear alarms/logs * Likely not documented well ? other than in the code (lol) * Let me know if this is what you are looking for * StarlingX OpenStack ? i.e. the containerized openstack solution * You?re right that the only pure openstack alarming that I am aware of is via aodh which does alarm thresholding of statistics collected by openstack telemetry / gnoochi ? which StarlingX OpenStack doesn?t fully support anymore ? we let it go stale and need to fix it * ? * However there is a StarlingX OpenStack VIM component that lives in the gray area between the StarlingX Platform on the host and StarlingX OpenStack in containers ? * One of the things VIM does, is watch openstack events and raises FM alarms and logs for many openstack events * I believe this is still operational and working today * At one time we were working on cloning FM and having a StarlingX Platform FM and a StarlingX OpenStack FM ? but I don?t believe that ever got completed. Anyways ? let me know if this helps, Greg From: Richard Schmitt > Sent: Monday, June 12, 2023 5:59 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Question about alarms in StarlingX Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Sun Jun 18 11:35:06 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Sun, 18 Jun 2023 11:35:06 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: +1 From: Church, Robert Sent: Friday, June 16, 2023 9:27 PM To: Scott Kamp ; De Ataides Barreto, Lucas ; starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 From: Scott Kamp > Date: Friday, June 16, 2023 at 7:43 PM To: De Ataides Barreto, Lucas >, starlingx-discuss at lists.starlingx.io > Cc: Cervi, Thales Elero > Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 Get Outlook for Android ________________________________ From: De Ataides Barreto, Lucas > Sent: Friday, June 16, 2023 10:51:02 PM To: starlingx-discuss at lists.starlingx.io > Cc: Cervi, Thales Elero > Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 for splitting the manifests. It gives STX-Openstack the freedom to upversion and maintain its packages without affecting the platform side. ________________________________ From: Cervi, Thales Elero > Sent: Friday, June 16, 2023 11:01 AM To: StarlingX ML > 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ThalesElero.Cervi at windriver.com Mon Jun 19 14:25:29 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Mon, 19 Jun 2023 14:25:29 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: Thank you all for the inputs on this ? Already created the Storyboard to map this change: https://storyboard.openstack.org/#!/story/2010797 Regards, Thales Cervi ________________________________ From: Waines, Greg Sent: Sunday, June 18, 2023 8:35 AM To: Church, Robert ; Scott Kamp ; De Ataides Barreto, Lucas ; starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: RE: Manifest decoupling: StarlingX and stx-openstack application +1 From: Church, Robert Sent: Friday, June 16, 2023 9:27 PM To: Scott Kamp ; De Ataides Barreto, Lucas ; starlingx-discuss at lists.starlingx.io Cc: Cervi, Thales Elero Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 From: Scott Kamp > Date: Friday, June 16, 2023 at 7:43 PM To: De Ataides Barreto, Lucas >, starlingx-discuss at lists.starlingx.io > Cc: Cervi, Thales Elero > Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 Get Outlook for Android ________________________________ From: De Ataides Barreto, Lucas > Sent: Friday, June 16, 2023 10:51:02 PM To: starlingx-discuss at lists.starlingx.io > Cc: Cervi, Thales Elero > Subject: Re: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application +1 for splitting the manifests. It gives STX-Openstack the freedom to upversion and maintain its packages without affecting the platform side. ________________________________ From: Cervi, Thales Elero > Sent: Friday, June 16, 2023 11:01 AM To: StarlingX ML > 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 : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ThalesElero.Cervi at windriver.com Mon Jun 19 15:27:10 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Mon, 19 Jun 2023 15:27:10 +0000 Subject: [Starlingx-discuss] Application repositories renaming after Armada deprecation Message-ID: Hi everyone. During our recent discussions on stx-openstack application manifest separation, something that our colleague Robert Church pointed out is that the repository for this application is still mentioning "armada" on its name: starlignx/openstack-armada-app. The naming does not make sense anymore, especially after our last release. The apps are now FluxCD apps and not Armada apps anymore. As he pointed out, this is true for other application repositories too, so there was the suggestion for renaming it. The list follows (as peer Bob's comments): audit-armada-app => app-audit cert-manager-armada-app => app-cert-manager metrics-server-armada-app => app-metrics-server nginx-ingress-controller-armada-app => app-nginx-ingress-controller oidc-auth-armada-app => app-oidc-auth openstack-armada-app => app-openstack portieris-armada-app => app-portieris ptp-notification-armada-app => app-ptp-notification rook-ceph => app-rook SDO-rv-service => app-sdo-rv snmp-armada-app => app-snmp vault-armada-app => app-vault platform-armada-app => app-ceph-storage NOTE: Initial naming was based on the assumption that we would include all platform apps here enabling helm charts as needed. This has proven to be incorrect as each app is its own repo. This contains only the bare-metal ceph application monitor-armada-app => app-monitor NOTE: Don?t think this is maintained anymore nor is part of stx-openstack. This might actually be able to be removed. Can rename at a minimum. Our colleague Scott Little is already looking into the best way to proceed with renaming those, but I am sending this email so anyone in the community can be heard in case there is some kind of concerns related to this repository renaming. Looking forward for hearing back from you : ) Thales Cervi -------------- next part -------------- An HTML attachment was scrubbed... URL: From starlingx.build at gmail.com Tue Jun 20 06:31:07 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Tue, 20 Jun 2023 02:31:07 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 202 - Failure! Message-ID: <627859223.433.1687242668863.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 202 Status: Failure Timestamp: 20230620T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230620T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From Greg.Waines at windriver.com Tue Jun 20 11:08:20 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 20 Jun 2023 11:08:20 +0000 Subject: [Starlingx-discuss] Application repositories renaming after Armada deprecation In-Reply-To: References: Message-ID: I am good with the renaming. Greg. From: Cervi, Thales Elero Sent: Monday, June 19, 2023 11:27 AM To: StarlingX ML Subject: [Starlingx-discuss] Application repositories renaming after Armada deprecation Hi everyone. During our recent discussions on stx-openstack application manifest separation, something that our colleague Robert Church pointed out is that the repository for this application is still mentioning "armada" on its name: starlignx/openstack-armada-app. The naming does not make sense anymore, especially after our last release. The apps are now FluxCD apps and not Armada apps anymore. As he pointed out, this is true for other application repositories too, so there was the suggestion for renaming it. The list follows (as peer Bob's comments): audit-armada-app => app-audit cert-manager-armada-app => app-cert-manager metrics-server-armada-app => app-metrics-server nginx-ingress-controller-armada-app => app-nginx-ingress-controller oidc-auth-armada-app => app-oidc-auth openstack-armada-app => app-openstack portieris-armada-app => app-portieris ptp-notification-armada-app => app-ptp-notification rook-ceph => app-rook SDO-rv-service => app-sdo-rv snmp-armada-app => app-snmp vault-armada-app => app-vault platform-armada-app => app-ceph-storage NOTE: Initial naming was based on the assumption that we would include all platform apps here enabling helm charts as needed. This has proven to be incorrect as each app is its own repo. This contains only the bare-metal ceph application monitor-armada-app => app-monitor NOTE: Don't think this is maintained anymore nor is part of stx-openstack. This might actually be able to be removed. Can rename at a minimum. Our colleague Scott Little is already looking into the best way to proceed with renaming those, but I am sending this email so anyone in the community can be heard in case there is some kind of concerns related to this repository renaming. Looking forward for hearing back from you : ) Thales Cervi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gabriel.CalixtodePaula at windriver.com Tue Jun 20 12:31:49 2023 From: Gabriel.CalixtodePaula at windriver.com (Calixto de Paula, Gabriel) Date: Tue, 20 Jun 2023 12:31:49 +0000 Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230618T060000Z] results - Jun-18 Message-ID: Hi all, StarlingX + STX-Openstack sanity and regression results: Overall run status: GREEN Build Info: Build date: 18-Jun ISO: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230618T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso Helm Charts: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230618T060000Z/outputs/helm-charts/stx-openstack-1.0-1.stx.50-debian-stable-versioned.tgz AIO-DX Baremetal with VSWITCH_TYPE=OVS Sanity Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 15 (100.00%) Failed: 0 (0.00%) Total Executed: 15 List of Test Cases: ------------------------------------------------------ PASS??20230620 04:00:12?test_ssh_to_hosts PASS??20230620 04:01:36?test_lock_unlock_host PASS??20230620 04:21:46?test_openstack_services_healthy PASS??20230620 04:22:48?test_reapply_stx_openstack_no_change[controller-0] PASS??20230620 04:24:35?test_reapply_stx_openstack_no_change[controller-1] PASS??20230620 04:33:30?test_horizon_create_delete_instance PASS??20230620 04:37:15?test_swact_controllers PASS??20230620 04:44:44?test_ping_between_two_vms[tis-centos-guest-virtio-virtio] PASS??20230620 04:51:29?test_migrate_vm[tis-centos-guest-live-None] PASS??20230620 04:56:28?test_nova_actions[tis-centos-guest-dedicated-pause-unpause] PASS??20230620 05:01:02?test_nova_actions[tis-centos-guest-dedicated-suspend-resume] PASS??20230620 05:05:39?test_evacuate_vms PASS??20230620 05:38:32?test_system_coredumps_and_crashes[core_dumps] PASS??20230620 05:38:47?test_system_coredumps_and_crashes[crash_reports] PASS??20230620 05:38:53?test_system_alarms ------------------------------------------------------ We'd like to point out that there is a Launchpad open for the TC test_reapply_stx_openstack_no_change[controller-1] : STX-O| config-out-of-date alarm won't disappear on controller-1 after swact and reapplying app This TC is passing on a re-run. Regression Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 12 (100.0%) Failed: 0 (0.0%) Total Executed: 12 List of Test Cases: ------------------------------------------------------ PASS??20230620 05:48:10?test_lldp_neighbor_remote_port PASS??20230620 05:49:44?test_kernel_module_signatures PASS??20230620 05:50:45?test_delete_heat_after_swact[OS_Cinder_Volume.yaml] PASS??20230620 05:55:37?test_multiports_on_same_network_vm_actions[virtio_x4] PASS??20230620 06:16:08?test_cpu_pol_vm_actions[2-dedicated-image-volume] PASS??20230620 06:28:11?test_vm_mem_pool_default_config[2048] PASS??20230620 06:31:07?test_vm_mem_pool_default_config[1048576] PASS??20230620 06:36:52?test_resize_vm_positive[local_image-4_1_512-5_2_1024-image] PASS??20230620 06:43:57?test_server_group_boot_vms[affinity-2] PASS??20230620 06:49:18?test_server_group_boot_vms[anti_affinity-2] PASS??20230620 06:54:55?test_vm_with_config_drive PASS??20230620 07:21:58?test_lock_with_vms ------------------------------------------------------ regards, STX-Openstack Distro Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.pereira at encora.com Tue Jun 20 14:38:15 2023 From: douglas.pereira at encora.com (Douglas Lopes Pereira) Date: Tue, 20 Jun 2023 14:38:15 +0000 Subject: [Starlingx-discuss] Application repositories renaming after Armada deprecation In-Reply-To: References: Message-ID: Hi Thales, the renaming suggestions look good to me as well. Regards, Douglas Lopes Pereira Software Development Manager M: +55 (19) 99212-3212 Campinas, BR [Encora] [We are proud to be recognized as Leaders in digital engineering services by Zinnov zones] ________________________________ From: Waines, Greg Sent: Tuesday, June 20, 2023 8:08 AM To: Cervi, Thales Elero ; StarlingX ML Subject: Re: [Starlingx-discuss] Application repositories renaming after Armada deprecation External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. I am good with the renaming. Greg. From: Cervi, Thales Elero Sent: Monday, June 19, 2023 11:27 AM To: StarlingX ML Subject: [Starlingx-discuss] Application repositories renaming after Armada deprecation Hi everyone. During our recent discussions on stx-openstack application manifest separation, something that our colleague Robert Church pointed out is that the repository for this application is still mentioning "armada" on its name: starlignx/openstack-armada-app. The naming does not make sense anymore, especially after our last release. The apps are now FluxCD apps and not Armada apps anymore. As he pointed out, this is true for other application repositories too, so there was the suggestion for renaming it. The list follows (as peer Bob's comments): audit-armada-app => app-audit cert-manager-armada-app => app-cert-manager metrics-server-armada-app => app-metrics-server nginx-ingress-controller-armada-app => app-nginx-ingress-controller oidc-auth-armada-app => app-oidc-auth openstack-armada-app => app-openstack portieris-armada-app => app-portieris ptp-notification-armada-app => app-ptp-notification rook-ceph => app-rook SDO-rv-service => app-sdo-rv snmp-armada-app => app-snmp vault-armada-app => app-vault platform-armada-app => app-ceph-storage NOTE: Initial naming was based on the assumption that we would include all platform apps here enabling helm charts as needed. This has proven to be incorrect as each app is its own repo. This contains only the bare-metal ceph application monitor-armada-app => app-monitor NOTE: Don?t think this is maintained anymore nor is part of stx-openstack. This might actually be able to be removed. Can rename at a minimum. Our colleague Scott Little is already looking into the best way to proceed with renaming those, but I am sending this email so anyone in the community can be heard in case there is some kind of concerns related to this repository renaming. Looking forward for hearing back from you : ) Thales Cervi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ThalesElero.Cervi at windriver.com Tue Jun 20 18:42:37 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Tue, 20 Jun 2023 18:42:37 +0000 Subject: [Starlingx-discuss] Minutes: OpenStack Distro Team Call (Jun 20, 2023) Message-ID: Etherpad: https://etherpad.opendev.org/p/stx-distro-openstack-meetings Minutes from the OpenStack Distro team call Jun 20, 2023 Build: - Build Issues: None Installation: - Installation Issues # LP 2023085: STX-Openstack | fails to apply - mariadb-server-1 pod in CrashLoopBackoff - Fix Released and Tested Sanity with stx-openstack (main branch): - Last Successful Execution: (OVS) Mon Jun 19 12:39:12 UTC 2023 - Overall status: GREEN ??????Sanity - Passed: 15 (100.00%) | Failed: 0 (0.0%) ??????Regression - Passed: 14 (100.00%) | Failed: 0 (0.0%) - Bugs Affecting Weekly Sanity/Regression: - No Reproducible bugs currently open. Only intermittent issues # LP 2012389: STX-Openstack: Failed to activate binding for port for live migration # LP 2007303: STX-Openstack: "nova live-migration" fails to live migrate after host is forcefully turned off/on - StarlingX 9.0 Release: - Storyboard/Tasks for containerizing OpenStack clients: https://storyboard.openstack.org/#!/story/2010797 - In progress - Storyboard/Tasks for decoupling platform and application manifests: https://storyboard.openstack.org/#!/story/2010797 - Discussion on a mail list thread, community has no concerns with it and agrees with this plan https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014205.html - Storyboard/Tasks for OpenStack upversion (Antelope): https://storyboard.openstack.org/#!/story/2010715 - Planned General Topics: - STX OpenStack Distro Team: OpenInfra Summit - Vancouver 2023 - Community interested on running OpenStack on K8S clusters: keep OpenStack services up to date (as much as we can) - How to make Users' life easier when they want to upversion stx-openstack services release (e.g., Antelope -> Bobcat) - STX Social Media and Documentation: make the stx-openstack more visible and understandable - Remove Armada related code: - Should we also rename the repository? starlingx/openstack-armada-app - Discussion on a mail list thread, community has no concerns with it and agrees with this plan https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014215.html -- Best Regards, Thales Cervi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peng.Peng at windriver.com Tue Jun 13 21:47:56 2023 From: Peng.Peng at windriver.com (Peng, Peng) Date: Tue, 13 Jun 2023 21:47:56 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20230611T060000Z Message-ID: Sanity Test from 2023 June 13 (https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230611T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso) Status: GREEN SX sanity Passed: 17 (100.0%) Failed: 0 (0.0%) Total Executed: 17 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_isolated_2p_2_big_pod_best_effort_HT_AIO PASS test_sriovdp_netdev_single_pod[1-1-lock/unlock] PASS test_sriovdp_netdev_connectivity_ipv4[1-1-calico-ipam] PASS test_sriovdp_mixed_add_vf_interface[1] PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] DX sanity Passed: 19 (100.0%) Failed: 0 (0.0%) Total Executed: 19 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_swact_controller_platform PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_push_docker_image_to_local_registry_standby PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_force_reboot_host[active_controller-True] PASS test_force_reboot_host[active_controller-False] PASS test_force_reboot_host[standby_controller-False] PASS test_bmc_verify_bm_type_ipmi PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] Regards, PV team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ThalesElero.Cervi at windriver.com Thu Jun 15 17:54:21 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Thu, 15 Jun 2023 17:54:21 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application Message-ID: 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ThalesElero.Cervi at windriver.com Fri Jun 16 13:59:34 2023 From: ThalesElero.Cervi at windriver.com (Cervi, Thales Elero) Date: Fri, 16 Jun 2023 13:59:34 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application Message-ID: 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.schmitt at starlab.io Fri Jun 16 14:10:38 2023 From: richard.schmitt at starlab.io (Richard Schmitt) Date: Fri, 16 Jun 2023 14:10:38 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX In-Reply-To: References: Message-ID: ?Thanks for the detailed answer. Let me answer the question, ?What software specifically do you want to generate alarms?? We have software that monitors security events associated with the Linux kernel that we would like to expose to the cloud platform. These security events get logged to journald which in turn is picked up by syslog. We would make a syslog rule that selects these specific audit events and outputs them to a named pipe. We?d run a service on each node that would read from this pipe, massage the syslog message, and, our hope, would be to create an alarm within StarlingX that represents that security event. That?s really the crux of my question. I?ve read that Kubernetes generally does not handle platform events yet we are exploring a requirement that these security alarms be exposed to the cloud admin through the Horizon web GUI. I?m trying to understand if this is possible. Again, thanks for taking the time to read my question and help. Rich From: Waines, Greg Date: Thursday, June 15, 2023 at 8:19 PM To: Richard Schmitt , starlingx-discuss at lists.starlingx.io Subject: RE: Question about alarms in StarlingX [EXTERNAL SENDER] Hey Richard ? sorry for the slow reply ? This is the right place to ask. I am not totally sure what you mean by ?We want to create user alarms in OpenStack.? * What software specifically do you want to generate alarms related to what specific fault conditions ? Some other background on alarms in StarlingX: * StarlingX Platform has a Fault Management system of its own * It is used by StarlingX Platform?s Infrastructure Services to raise alarms and logs related to fault conditions detected by StarlingX Platform?s Infrastructure Services * These alarms / logs are stored in a historical event (alarm or log) db * And an active alarm db is maintained to show alarms that are currently present within StarlingX * The historical event db and the active alarm db can be displayed thru * the starlingx API/CLI ?fm?, and * the starlingx horizon, on the Fault Management page * There is an internal developer?s API for FM for people coding StarlingX Platform Infrastructure Services code to raise and clear alarms/logs * Likely not documented well ? other than in the code (lol) * Let me know if this is what you are looking for * StarlingX OpenStack ? i.e. the containerized openstack solution * You?re right that the only pure openstack alarming that I am aware of is via aodh which does alarm thresholding of statistics collected by openstack telemetry / gnoochi ? which StarlingX OpenStack doesn?t fully support anymore ? we let it go stale and need to fix it * ? * However there is a StarlingX OpenStack VIM component that lives in the gray area between the StarlingX Platform on the host and StarlingX OpenStack in containers ? * One of the things VIM does, is watch openstack events and raises FM alarms and logs for many openstack events * I believe this is still operational and working today * At one time we were working on cloning FM and having a StarlingX Platform FM and a StarlingX OpenStack FM ? but I don?t believe that ever got completed. Anyways ? let me know if this helps, Greg From: Richard Schmitt Sent: Monday, June 12, 2023 5:59 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Question about alarms in StarlingX Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8404 bytes Desc: not available URL: From richard.schmitt at starlab.io Fri Jun 16 20:28:02 2023 From: richard.schmitt at starlab.io (Richard Schmitt) Date: Fri, 16 Jun 2023 20:28:02 +0000 Subject: [Starlingx-discuss] Question about alarms in StarlingX In-Reply-To: References: Message-ID: ?Just an FYI. I kind of figured things out. There?s an api called ?fm_api? that let?s you instantiate a class FaultAPIv2 and call set_fault. This will add an Event to the Horizon Fault Manager, Event List. That?s essentially what I want. So, I figure I?d thank you for looking into this but also let you know that I probably have what I want. Thanks, Rich From: Waines, Greg Date: Thursday, June 15, 2023 at 8:19 PM To: Richard Schmitt , starlingx-discuss at lists.starlingx.io Subject: RE: Question about alarms in StarlingX [EXTERNAL SENDER] Hey Richard ? sorry for the slow reply ? This is the right place to ask. I am not totally sure what you mean by ?We want to create user alarms in OpenStack.? * What software specifically do you want to generate alarms related to what specific fault conditions ? Some other background on alarms in StarlingX: * StarlingX Platform has a Fault Management system of its own * It is used by StarlingX Platform?s Infrastructure Services to raise alarms and logs related to fault conditions detected by StarlingX Platform?s Infrastructure Services * These alarms / logs are stored in a historical event (alarm or log) db * And an active alarm db is maintained to show alarms that are currently present within StarlingX * The historical event db and the active alarm db can be displayed thru * the starlingx API/CLI ?fm?, and * the starlingx horizon, on the Fault Management page * There is an internal developer?s API for FM for people coding StarlingX Platform Infrastructure Services code to raise and clear alarms/logs * Likely not documented well ? other than in the code (lol) * Let me know if this is what you are looking for * StarlingX OpenStack ? i.e. the containerized openstack solution * You?re right that the only pure openstack alarming that I am aware of is via aodh which does alarm thresholding of statistics collected by openstack telemetry / gnoochi ? which StarlingX OpenStack doesn?t fully support anymore ? we let it go stale and need to fix it * ? * However there is a StarlingX OpenStack VIM component that lives in the gray area between the StarlingX Platform on the host and StarlingX OpenStack in containers ? * One of the things VIM does, is watch openstack events and raises FM alarms and logs for many openstack events * I believe this is still operational and working today * At one time we were working on cloning FM and having a StarlingX Platform FM and a StarlingX OpenStack FM ? but I don?t believe that ever got completed. Anyways ? let me know if this helps, Greg From: Richard Schmitt Sent: Monday, June 12, 2023 5:59 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Question about alarms in StarlingX Sorry if this isn?t the right place to ask this question. We want to create user alarms in OpenStack. We are not very knowledgeable of OpenStack. Ultimately, we?d like to raise alarms and have them appear in the Horizon Fault Management page or via the fm CLI. It does not appear that StarlingX has anything to do with creating or raising alarms. There are some references in OpenStack documentation on aodh but that service is not deployed in our configuration. I?m not entirely sure whether OpenStack supports extensible alarms. Perhaps that?s why I?m finding so little info on it. Any pointers on where I should look? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8404 bytes Desc: not available URL: From Peng.Peng at windriver.com Tue Jun 20 18:01:36 2023 From: Peng.Peng at windriver.com (Peng, Peng) Date: Tue, 20 Jun 2023 18:01:36 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20230618T060000Z Message-ID: Sanity Test from 2023 June 19 (https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230618T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso) Status: GREEN SX sanity Passed: 17 (100.0%) Failed: 0 (0.0%) Total Executed: 17 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_isolated_2p_2_big_pod_best_effort_HT_AIO PASS test_sriovdp_netdev_single_pod[1-1-lock/unlock] PASS test_sriovdp_netdev_connectivity_ipv4[1-1-calico-ipam] PASS test_sriovdp_mixed_add_vf_interface[1] PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] DX sanity Passed: 19 (100.0%) Failed: 0 (0.0%) Total Executed: 19 List of Test Cases: ------------------------------------------------------ PASS test_system_health_pre_session[pods] PASS test_system_health_pre_session[alarms] PASS test_system_health_pre_session[system_apps] PASS test_horizon_host_inventory_display PASS test_lock_unlock_host PASS test_swact_controller_platform PASS test_pod_to_pod_connection PASS test_pod_to_service_connection PASS test_host_to_service_connection PASS test_push_docker_image_to_local_registry_active PASS test_push_docker_image_to_local_registry_standby PASS test_upload_charts_via_helm_upload PASS test_host_operations_with_custom_kubectl_app PASS test_force_reboot_host[active_controller-True] PASS test_force_reboot_host[active_controller-False] PASS test_force_reboot_host[standby_controller-False] PASS test_bmc_verify_bm_type_ipmi PASS test_system_coredumps_and_crashes[core_dumps] PASS test_system_coredumps_and_crashes[crash_reports] Regards, PV team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openinfra.dev Wed Jun 21 17:19:55 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Wed, 21 Jun 2023 10:19:55 -0700 Subject: [Starlingx-discuss] OpenInfra Summit, PTG and Forum summary Message-ID: <3B8694A6-DF9C-48DC-9350-24298E29A5F2@openinfra.dev> Hi StarlingX Community, I?m reaching out about the OpenInfra Summit, that happened last week in Vancouver, BC, Canada. We had a great event with people from all around the world. We had StarlingX contributors and people interested in the project attending in person, to make connections and bring discussions forward. Contributors and users presented at the conference to talk about their Starling X use cases or the capabilities of the project. The conference sessions were recorded and will be made available in the coming weeks on the event?s YouTube playlist: https://www.youtube.com/playlist?list=PLKqaoAnDyfgqsxQDbLj4LVpKiZSDbntuC The StarlingX related videos will be added to the StarlingX playlist on YouTube, once available: https://www.youtube.com/playlist?list=PLKqaoAnDyfgp7KWad7EAHnZ30Mdg3Ejqf * Forum Forum sessions are interactive sessions to provide the space and opportunity for users and project contributors to get together and discuss feedback, priorities and next steps. The StarlingX community had a short session to learn about use cases that people are considering StarlingX for. Main discussion topics included: - Connectivity in rural areas - Industrial IoT and sensors - MSPs (Managed Services Providers) Please see the Forum etherpad for notes: https://etherpad.opendev.org/p/r.65f95cd991ecd9d4de6934b865ec0f80 * PTG Contributors and newcomers to the project had a small PTG session to discuss current work items and challenges. Main discussion topics included: - Project communication - Follow-up email is in progress - Onboarding users and new contributors - Activities to move forward with implementing Arm support for StarlingX Please see the PTG etherpad for notes: https://etherpad.opendev.org/p/r.ff22c936a2ed93cc90a8d5d342c323d1 Thanks and Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From starlingx.build at gmail.com Thu Jun 22 06:35:46 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Thu, 22 Jun 2023 02:35:46 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 204 - Failure! Message-ID: <1247796318.441.1687415747854.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 204 Status: Failure Timestamp: 20230622T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230622T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From Greg.Waines at windriver.com Thu Jun 22 12:21:05 2023 From: Greg.Waines at windriver.com (Waines, Greg) Date: Thu, 22 Jun 2023 12:21:05 +0000 Subject: [Starlingx-discuss] Manifest decoupling: StarlingX and stx-openstack application In-Reply-To: References: Message-ID: +1 From: Cervi, Thales Elero Sent: Thursday, June 15, 2023 1:54 PM To: StarlingX ML 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 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openinfra.dev Thu Jun 22 17:53:54 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Thu, 22 Jun 2023 10:53:54 -0700 Subject: [Starlingx-discuss] Community Communication Channels Message-ID: Hi StarlingX Community, I?m reaching out to you about a recurring topic that came up during the PTG last week again. While the community is actively using the mailing list, it is not always the best platform, as it doesn?t allow for more synchronous chat. Contributors at the event had a growing interest in finding a way to provide the opportunity for more synchronous communication to capture the project teams? chatters, and enable newcomers to reach out and start to participate. Challenges: * Tooling: People raised that while it is an open protocol, IRC still doesn?t feel inclusive due to its simplicity. * Format: The current one-channel setup doesn?t feel efficient and comfortable, since people need to address everyone in the channel with every topic they have a question or comment about. Proposal to move forward: * Tooling: The preferred tool in last week?s conversation was Matrix - https://matrix.org - It is an open tool, which ensures continued access to the platform and its features - It is more modern than IRC * Format: The idea came up to create multiple channels for the StarlingX project - We can keep the all-community channel - We can create channels for each project team, that are more topic specific - We also have the option to create a channel for newcomers, which could include troubleshooting type of conversations as well In order to identify next steps, please share your feedback about the proposal above. Ie: What do you think about Matrix? Would you be more comfortable using a chat tool with the more fine grained configuration of having multiple channels? Thanks and Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From fungi at yuggoth.org Thu Jun 22 18:54:26 2023 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 22 Jun 2023 18:54:26 +0000 Subject: [Starlingx-discuss] Community Communication Channels In-Reply-To: References: Message-ID: <20230622185425.vjlsjs2c6ndmbny5@yuggoth.org> On 2023-06-22 10:53:54 -0700 (-0700), Ildiko Vancsa wrote: [...] > Proposal to move forward: > * Tooling: The preferred tool in last week?s conversation was > Matrix - https://matrix.org > - It is an open tool, which ensures continued access to the > platform and its features - It is more modern than IRC > > * Format: The idea came up to create multiple channels for the > StarlingX project > - We can keep the all-community channel > - We can create channels for each project team, that are more > topic specific > - We also have the option to create a channel for newcomers, > which could include troubleshooting type of conversations as > well [...] If it assists in the decision making, the OpenDev Collaboratory has a Matrix homeserver which can host channels. The Zuul community is making use of this option, with their primary discussion channel being #zuul:opendev.org for the past few years already. Our GerritBot can be told to join specific Matrix channels and report on change events similarly to how it works on IRC (feel free to join the Zuul channel if you want to see what that ends up looking like). We have plans to port some of our other IRC bots to Matrix as well, and help with that is always welcome of course. A middle ground, instead of a pure Matrix channel, is to join IRC channels through Matrix's OFTC bridge. Users who are connecting to IRC that way get access to basically all of Matrix's native features, while people connecting with a traditional IRC client can still mostly see what they're saying and vice versa (Matrix features like multi-line comments, inline media and fancy formatting are transformed into summaries with URLs to view the rest in a browser). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From fungi at yuggoth.org Thu Jun 22 18:58:51 2023 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 22 Jun 2023 18:58:51 +0000 Subject: [Starlingx-discuss] Community Communication Channels In-Reply-To: <20230622185425.vjlsjs2c6ndmbny5@yuggoth.org> References: <20230622185425.vjlsjs2c6ndmbny5@yuggoth.org> Message-ID: <20230622185851.mdpa2l545j2tsq6d@yuggoth.org> On 2023-06-22 18:54:26 +0000 (+0000), Jeremy Stanley wrote: [...] > The Zuul community is making use of this option, with their > primary discussion channel being #zuul:opendev.org for the past > few years already. [...] > A middle ground, instead of a pure Matrix channel, is to join IRC > channels through Matrix's OFTC bridge. [...] Oh, I meant to mention, Zuul also has some fairly straightforward documentation about using Matrix, including as a way of accessing traditional IRC networks: https://zuul-ci.org/docs/zuul/latest/howtos/matrix.html As always, the documentation is published under an open license, so if someone wanted to use it as the basis for a similar set of documents for the StarlingX community, that would get you a nice head-start for newcomers too. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From Ghada.Khalil at windriver.com Fri Jun 23 12:49:46 2023 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Fri, 23 Jun 2023 12:49:46 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meeting - Jun 21/2023 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases Release Team Meeting - Jun 21 2023 stx.9.0 - Release/Feature Planning: https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing - PTG Release Discussion - Walked through the candidate feature list for stx.9.0 - Discussed the more interesting features - Upcoming Feature Milestones - A number of features are past due their Code Merge Date - Armada Deprecation / Replacement - FluxCD (cont'd) / Bruce Jones / Code Merge: 6/12 - K8S Upversion Duration Reduction for AIO-SX / Bruce Jones / Code Merge: 6/6 - remove Armada / Bruce Jones / Code Merged: 6/12 << duplicate of "Armada Deprecation / Replacement - FluxCD (cont'd)"? - Containerization Component Refresh - k8s 1.26 / Bruce Jones / Code Merge: 6/13 - WAD Users sudo and local linux group assignment / Ghada Khalil / Code Merge: 5/19 - Subcloud Error Root Cause Correction Action / Carlos Fleck / Code Merge: 5/27 - Support for long latency between SystemController and Subclouds / Ram S / Code Merge: 6/19 - Action: Ghada to follow up with feature primes for updates Blogs - FEC Device Configurability (fec-operator Integration) for ACC100 & N3000 - Prime: Balendu (Mouli) Burla - Forecast: May 1 >> May 19 >> need re-forecast - Status: Confirmed / Not posted - Platform Single Core Tuning - Prime: Guilherme Batista Leite - Forecast: May 9 >> Jun 6 - Status: Posted for review - Pull Request: https://github.com/StarlingXWeb/starlingx-website/pull/238 - PTP O-RAN Compliant API Notification - Prime: Ghada Khalil - Forecast: Jun 30 - Status: Confirmed / Not posted From Ghada.Khalil at windriver.com Fri Jun 23 23:22:26 2023 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Fri, 23 Jun 2023 23:22:26 +0000 Subject: [Starlingx-discuss] Minutes: Community Call (Jun 21, 2023) Message-ID: Etherpad: https://etherpad.opendev.org/p/stx-status Minutes from the community call June 21, 2023 Standing topics - Build - Main Branch Debian Builds - Some build failures during the last week - One build issue with the container images due to a Debian package upgrade >> already fixed - Build failed yesterday due to a networking outage; this is now happening once/twice per week - There's a build currently in progress - stx.6.0 Weekly RC Builds - Green - Build Output: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/6.0/ - stx.7.0 Weekly RC Builds - Failed due to a recent change to faciliate transition off of CENGN; ScottL is investigating - Build Output: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/7.0/ - Note: No container image builds are done for stx.7.0 - stx.8.0 Weekly RC Builds - Green - Build Output: https://mirror.starlingx.cengn.ca/mirror/starlingx/rc/8.0/ - Transition from CENGN - Build team is working on transitioning the builds to WR infrastructure as CENGN will no longer be able to host the StarlingX builds. - Timing: Tentatively end-July / early-Aug - Status: - All mirror jobs are working - Able to build Debian: the main branch builds (iso+container) as well as stx.8.0 RC builds with similar reliability - Now working on building stx.7.0 (CentOS build) and investigating issues - Working w/ WR IT on publicly posting build results << still under discussion - Sanity - Debian Main Branch Platform Sanity - Last sanity email sent on June 20: https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014226.html - Status: Green for SX and DX - Debian Main Branch stx-openstack Sanity - Last sanity email sent on June 18: https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014218.html - Status: Green - Gerrit Reviews in Need of Attention - tools repo reviews - Virtual Env Setup - https://review.opendev.org/c/starlingx/tools/+/880870 - Key reviewers have not been active in reviewing the code - The changes are isolated and should be low risk - Agreed that Davlet will merge the changes based on the current +1s - Also agreed that the tools repo will be split into smaller repos. This action is with the build team to plan/implement. - From previous meetings: Fixes to libvirt env: https://review.opendev.org/c/starlingx/tools/+/863735 - Review comments provided in Nov; still waiting for author (Scott Kamp) to respond/address review comments - Jan 18: Some activity in the review as of Jan 15 - Feb 1: Alternative fix proposed on Jan 18; waiting for ScottK's review - Feb 15: ScottK is going back to this - Mar 22: Next action is w/ ScottK; As per today's meeting, he'll be looking at the comments - Apr 11: Review is still open. Next action is w/ ScottK (the author) - May 4: ScottK lost his setup, so needs to recover the review - Jun 21: No updates - Reference Links: - Active Branch (open): https://review.opendev.org/q/projects:starlingx+is:open+branch:+master - Active Branch (merged): https://review.opendev.org/q/projects:starlingx+is:merged+branch:master Topics for this week - Manifest repo re-configuration / split to allow stx-openstack to be built independently from the platform - https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014206.html - No concerns from the community regarding this proposal. - The key issue is scheduling time for the build team to implement the change. - Action: Build team to propose a timeline based on their priorities/availability. - StoryBoard tracking the work: https://storyboard.openstack.org/#!/story/2010797 - Renaming App Repos to remove the "armada" - https://lists.starlingx.io/pipermail/starlingx-discuss/2023-June/014215.html - Minor / cosematic change. Lower priority, but would be nice to do. Should have no impact on runtime. - Action: Build team to propose a timeline based on their priorities/availability. (lower priority than the manifest repo re-config) ARs from Previous Meetings - Restarting the containers subproject meeting? - Action: Bruce to send the question to the mailing list to see if there is any interest in restarting the meetings - Status: Open / No update - github Mirroring - Action: Greg to review the requirements for github mirroring to confirm if it's required for all repos or just a subset to meet k8s conformance requirements. - Status: Closed - Greg reviewed his notes from the discussion w/ CNCF and confirmed that the requirement is to only mirror the core repos (the config repo is considered the core repo). - There is no explicit requirement to mirror new repos. - ARM Support - Action: Scott Kamp to respond to Jackie/the mailing list to provide assistance/access to some arm machines - Action: Scott Little to respond regarding build questions - Cannot mirror more files on CENGN; will need to wait until we transition away from CENGN - Action: Scott Kamp to explore providing a hosting env temporarily - No plan to publish images to dockerhub/starlingx until they are part of the official build infrastructure - Under discussion in the OS subproject meeting - Jackie is donating hardware, but it needs to be managed by someone - Status: Open - Greg took the action to identify the right prime to drive the ARM Support project within StarlingX - StarlingX Subproject Meetings Update - Action: Scott Little to confirm w/ Mike Matteson on the build meeings - Scott is suggesting to cover build topics as part of the OS-distro meeting. Scott to discuss with the PL/TL. - Status Open / No Update - Action: Chris Friesen to provide an update on the containerization meetings - Bruce will follow up on whether to restart the containerization meetings on the mailing list - Status: Open / No Update Open Requests for Help - Issue w/ pxebooting a second node on StarlingX - Question raised on the community call (Apr 26) by Kevin - The initial node installs/boots correctly, but but an identical second node doesn't. This setup is using vmare to run StarlingX in VMs. - Status: Open / Greg has some information to share, but isn't sure how to get in touch w/ Kevin - Build System Setup - Question was posted on IRC by Kevin - StarlingX documentation has a lot of outdated information. It took a lot of digging to find the right documentation for setting up a build env with minikube. - Requested that Kevin open an LP to the doc team and/or send an email to the mailing list w/ more details to the mailing list - Status: Open / No email sent to the mailing list yet. Unsure if LP was opened. - Support for StarlingX 8 setup bring up - Reported by Prashanthi - Email thread: https://lists.starlingx.io/pipermail/starlingx-discuss/2023-April/014026.html - Status: - Open / Discussion is active on the mailing list. Greg providing assistance. The issues are related to date/time issues on servers being setup as well as firewall issues - CURRENTLY PAUSED ... Prashanthi had higher internal priorities that have taken her away from looking at StarlingX for the time being; waiting for Prashanthi to get back to us. From starlingx.build at gmail.com Tue Jun 27 06:06:22 2023 From: starlingx.build at gmail.com (starlingx.build at gmail.com) Date: Tue, 27 Jun 2023 02:06:22 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] master STX_build_debian_master - Build # 208 - Failure! Message-ID: <1886914908.2.1687845983599.JavaMail.javamailuser@localhost> Project: STX_build_debian_master Build #: 208 Status: Failure Timestamp: 20230627T060000Z Branch: master Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230627T060000Z/logs -------------------------------------------------------------------------------- Parameters BUILD_PACKAGES_LIST: CLEAN_DOWNLOADS: false BUILD_HELM_CHARTS: true USE_DOCKER_CACHE: true DOCKER_IMAGE_LIST: PUSH_DOCKER_IMAGES: true CLEAN_DOCKER: true REFRESH_SOURCE: true DRY_RUN: false CLEAN_PACKAGES: true BUILD_RT: true BUILD_PACKAGES: true CLEAN_REPOMGR: true PKG_REUSE: false JENKINS_SCRIPTS_BRANCH: master BUILD_DOCKER_BASE_IMAGE: true BUILD_DOCKER_IMAGES: true FORCE_BUILD: false REBUILD_BUILDER_IMAGES: true CLEAN_ISO: true BUILD_ISO: true From ildiko at openinfra.dev Tue Jun 27 15:15:11 2023 From: ildiko at openinfra.dev (Ildiko Vancsa) Date: Tue, 27 Jun 2023 08:15:11 -0700 Subject: [Starlingx-discuss] New blog post - Single-core platform Message-ID: <87CFF71F-4BB1-4E57-A6DF-794CE4B2338F@openinfra.dev> Hi StarlingX Community, I?m reaching out to draw your attention to a new post on the StarlingX blog: StarlingX Single-core Platform by Davi Fossard. The article describes the new functionality in the platform that allows the services to run on a single CPU core, with the right hardware setup. You can find the article here: https://www.starlingx.io/blog/starlingx-single-core-platform/ Best Regards, Ildik? ??? Ildik? V?ncsa Director of Community Open Infrastructure Foundation From Gabriel.CalixtodePaula at windriver.com Wed Jun 28 14:19:52 2023 From: Gabriel.CalixtodePaula at windriver.com (Calixto de Paula, Gabriel) Date: Wed, 28 Jun 2023 14:19:52 +0000 Subject: [Starlingx-discuss] Sanity and Regression - StarlingX + STX-Openstack MASTER build [20230625T060000Z] results - Jun-25 Message-ID: Hi all, StarlingX + STX-Openstack sanity and regression results: Overall run status: GREEN Build Info: Build date: 25-Jun ISO: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230625T060000Z/outputs/iso/starlingx-intel-x86-64-cd.iso Helm Charts: https://mirror.starlingx.cengn.ca/mirror/starlingx/master/debian/monolithic/20230625T060000Z/outputs/helm-charts/stx-openstack-1.0-1.stx.52-debian-stable-versioned.tgz AIO-DX Baremetal with VSWITCH_TYPE=OVS Sanity Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 15 (100.00%) Failed: 0 (0.0%) Total Executed: 15 List of Test Cases: ------------------------------------------------------ PASS??20230628 01:13:44?test_ssh_to_hosts PASS??20230628 01:15:05?test_lock_unlock_host PASS??20230628 01:34:07?test_openstack_services_healthy PASS??20230628 01:35:06?test_reapply_stx_openstack_no_change[controller-0] PASS??20230628 01:37:10?test_reapply_stx_openstack_no_change[controller-1] PASS??20230628 01:45:59?test_horizon_create_delete_instance PASS??20230628 01:48:37?test_swact_controllers PASS??20230628 01:56:23?test_ping_between_two_vms[tis-centos-guest-virtio-virtio] PASS??20230628 02:03:04?test_migrate_vm[tis-centos-guest-live-None] PASS??20230628 02:08:00?test_nova_actions[tis-centos-guest-dedicated-pause-unpause] PASS??20230628 02:12:29?test_nova_actions[tis-centos-guest-dedicated-suspend-resume] PASS??20230628 02:16:56?test_evacuate_vms PASS??20230628 02:50:18?test_system_coredumps_and_crashes[core_dumps] PASS??20230628 02:50:34?test_system_coredumps_and_crashes[crash_reports] PASS??20230628 02:50:41?test_system_alarms ------------------------------------------------------ We'd like to point out that there is a Launchpad open for the TC test_reapply_stx_openstack_no_change[controller-1] : STX-O| config-out-of-date alarm won't disappear on controller-1 after swact and reapplying app This TC is passing on a re-run. Regression Results: Overall Status: GREEN Automated Test Results Summary: ------------------------------------------------------ Passed: 12 (100.0%) Failed: 0 (0.0%) Total Executed: 12 List of Test Cases: ------------------------------------------------------ PASS 20230628 02:57:04 test_lldp_neighbor_remote_port PASS 20230628 02:58:30 test_kernel_module_signatures PASS 20230628 02:59:29 test_delete_heat_after_swact[OS_Cinder_Volume.yaml] PASS 20230628 03:04:37 test_multiports_on_same_network_vm_actions[virtio_x4] PASS 20230628 03:25:19 test_cpu_pol_vm_actions[2-dedicated-image-volume] PASS 20230628 03:37:02 test_vm_mem_pool_default_config[2048] PASS 20230628 03:39:55 test_vm_mem_pool_default_config[1048576] PASS 20230628 03:45:34 test_resize_vm_positive[local_image-4_1_512-5_2_1024-image] PASS 20230628 03:52:41 test_server_group_boot_vms[affinity-2] PASS 20230628 03:57:50 test_server_group_boot_vms[anti_affinity-2] PASS 20230628 04:03:30 test_vm_with_config_drive PASS 20230628 04:30:03 test_lock_with_vms ------------------------------------------------------ regards, STX-Openstack Distro Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peng.Peng at windriver.com Tue Jun 27 21:33:04 2023 From: Peng.Peng at windriver.com (Peng, Peng) Date: Tue, 27 Jun 2023 21:33:04 +0000 Subject: [Starlingx-discuss] StarlingX sanity is not available this week. Message-ID: Hi, Since lab resources were not available, Sanity was not run this week. We will resume next week. Regards, PV team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Davlet.Panech at windriver.com Thu Jun 29 14:42:52 2023 From: Davlet.Panech at windriver.com (Panech, Davlet) Date: Thu, 29 Jun 2023 14:42:52 +0000 Subject: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple In-Reply-To: References: <89e390cc-6fe3-5639-03c1-3baa2350fe11@eng.windriver.com> Message-ID: Done. After discussing with the new repo cores, we settled on a slightly different name: https://opendev.org/starlingx/virtual-deployment ________________________________ From: Panech, Davlet Sent: June 7, 2023 9:15 AM To: starlingx-discuss at lists.starlingx.io ; Little, Scott Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple Good idea, but let's deal with integ first. I meant "deployment" ________________________________ From: Panech, Davlet Sent: June 7, 2023 9:05 AM To: starlingx-discuss at lists.starlingx.io ; Little, Scott Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config Good idea, but let's deal with integ first. ________________________________ From: Scott.Little Sent: June 1, 2023 11:29 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Input needed - split starlingx/tools git repo into multiple +1 on 'deployment' We should also consider separate repo(s) for config files like ... stx-tools/debian-mirror-tools/config stx-tools/debian-mirror-tools/config Scott On 2023-05-31 11:06, Panech, Davlet wrote: Good day, We are considering splitting the git repository starlingx/tools into multiple. Reason: it contains files & scripts from unrelated domains and it is difficult to find Git reviewers whose expertise covers all of them. At a minimum, I suggest we separate out the "deployment" directory in its own repository. Would it make sense to separate out any other directories? D. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Thu Jun 29 22:41:16 2023 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Thu, 29 Jun 2023 22:41:16 +0000 Subject: [Starlingx-discuss] Canceled: Bi-weekly StarlingX Release Meeting Message-ID: The stx release meeting is cancelled on July 5 as I'm out of office and there is nobody available to chair the meeting. Updated meeting series for the StarlingX Release Meeting Starting from Nov 9, 2022 and meeting every other week. Bi-weekly meeting on Wednesday 06:30AM PT / 09:30AM ET / 02:30PM UTC Zoom Link: https://zoom.us/j/342730236?pwd=N21CUXNXVlJXMlcyZjZ0SE96cVNjQT09 Meeting agenda/minutes: https://etherpad.openstack.org/p/stx-releases Regards, Ghada -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2070 bytes Desc: not available URL: From Juanita.Balaraj at windriver.com Fri Jun 30 14:59:39 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Fri, 30 Jun 2023 14:59:39 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 21/22-06-2023 In-Reply-To: References: Message-ID: Hello All, Here are last week's doc team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings Please Note: From July 1st week we will be switching over to Stx Doc Team meetings on Thursdays 6.00 a.m. PST. See Starlingx/Meetings - OpenStack for more details. [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation Thanks, Juanita Balaraj ============ 21 / 22-June-23 Note: From July 1st week we will be switching over to Stx Doc Team meetings on Thursday 6.00 a.m. PST. See https://wiki.openstack.org/wiki/Starlingx/Meetings for more details. Current StarlingX Release Stx 9.0 Release Tracking Spreadsheet: Doc Stories are tracked in https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing. Gerrit Reviews: - Open Reviews pending; https://review.opendev.org/q/starlingx/docs+status:open - To be reviewed and merged - Merged ~2 reviews. - Bruno Muniz / Gustavo Herzmann created a gerrit review to use the automated script for Vbox installs: To raise LP Bugs / Stories; https://storyboard.openstack.org/#!/story/2005051#comment-203593; Launchpad Doc Bugs: - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.docs Total 11 outstanding bugs - The DOC team to create LP defects corresponding with any DS defects - WIP. Teams to add all the impacted Releases when raising a LP bug - Bug #2021896 "References to not supported Rook container-based C..." : Bugs : StarlingX (launchpad.net) - Bruno to check with Greg Miscellaneous Updates: - Ron to update the Verified H/W page with the automated script updates https://www.windriver.com/studio/operator/self-validated-and-certified-hosts# - Currently Commented out - Script needs to be updated- AR Ron - Installation Virtual docs - Bruno to ask Greg at the community meeting or send an email General Updates: - We had a new participant in the Docs Team meeting on Wednesday, an attendee at the OpenInfra Summit at Vancouver. - Bruno Muniz showed interest in creating DOC Videos supporting the StarlingX Installation Process. To check with Ildiko / Greg whether this is ok. These Videos can be hosted in a location in StarlingX. The Installation Docs can point to these videos - AR Bruno to get approvals from Ildiko / Greg - Sphinx Tools - Need to have further discussions about the version used upstream vs. downstream - AR Ron -To determine version. - Docker Container upstream / downstream - AR Ron (Discuss it with Greg / Ildiko) - Operations Guide Archive - On Hold until further clarifications are discussed with Greg (https://review.opendev.org/c/starlingx/docs/+/822030) - OpenInfra Summit & PTG: June 13-15, Vancouver, Canada - https://openinfra.dev/summit/vancouver-2023/; Schedule: https://vancouver2023.openinfra.dev/a/schedule Sessions: https://ptg.opendev.org/ptg.html - Workshop Details are tracked in https://etherpad.opendev.org/p/stx_hands_on_workshop_2023 - IRC: Everyone to use the IRC channel for communication with the community. Team can use https://www.icechat.net/site/icechat-9/ as an alternate text editor from their browser. IRC is a chat platform, for text-based communication. There's a web client for easy access: https://webchat.oftc.net/- You need to pick a nickname, and the channel name is #opendev. Once you are in the #opendev channel, you can talk to the group of people in that channel. To Setup IRC - contributor-guide documentation (openstack.org) IRC here: https://docs.openstack.org/contributors/common/irc.html; Engineering Status: StarlingX Eng Stx Status: https://etherpad.opendev.org/p/stx-status StarlingX Eng Status 2023 https://etherpad.opendev.org/p/stx-documentation ____________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Juanita.Balaraj at windriver.com Fri Jun 30 15:13:40 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Fri, 30 Jun 2023 15:13:40 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 28/29-06-2023 In-Reply-To: References: Message-ID: Hello All, Here are this week's doc team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings Please Note: From July 1st week we will be switching over the StarlingX Doc Team meetings to Thursdays 6.00 a.m. PST. See Starlingx/Meetings - OpenStack for more details. [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation Thanks, Juanita Balaraj ============ 28/29-June-23 Note: From July 1st week the StarlingX DOC meetings will be switching over to Thursday 6.00 a.m. PST. See https://wiki.openstack.org/wiki/Starlingx/Meetings for more details. Password to be set by the first participant at the meeting. Note: We will be cancelling the Wednesday StarlingX Doc Team Meetings from July 1st. Current StarlingX Release Stx 9.0 Release Tracking Spreadsheet: Doc Stories are tracked in https://docs.google.com/spreadsheets/d/1aTjYzUkExodfayt-rjTv466jE-DP8b_YjrTHhXW6G9w/edit?usp=sharing. Gerrit Reviews: - Open Reviews pending; https://review.opendev.org/q/starlingx/docs+status:open - To be reviewed and merged - Merged ~10 reviews. - Bruno Muniz / Gustavo Herzmann created a gerrit review to use the automated script for Vbox installs: To raise LP Bugs / Stories; https://storyboard.openstack.org/#!/story/2005051#comment-203593; Launchpad Doc Bugs: - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.docs Total 7 outstanding bugs - (4 were fixed) The DOC team to create LP defects corresponding with any DS defects - WIP. Teams to add all the impacted Releases when raising a LP bug - To update Ildiko about LP bugs not closing automatically when Gerrit reviews merge. - AR Juanita - Bug #2021896 "References to not supported Rook container-based C..." : Bugs : StarlingX (launchpad.net) - Bruno to check with Greg - Bug #1932314 "Virtual AIO-SX install documentation presents data..." : Bugs : StarlingX (launchpad.net) - To discuss with Greg Miscellaneous Updates: - Ron to update the Verified H/W page with the automated script updates https://www.windriver.com/studio/operator/self-validated-and-certified-hosts# - Currently Commented out - Script needs to be updated- Waiting for updates to the script -AR Ron - Installation Virtual docs - Bruno to ask Greg at the community meeting or send an email General Updates: - We had a new participant continue to attend the Docs Team meeting on Wednesday/Thursday, an attendee at the OpenInfra Summit at Vancouver. - As far as discussions go the OpenDev team meets regularly in #opendev-meeting (on the OFTC IRC network) on Tuesdays at 19:00 UTC. We also have the #opendev IRC channel and service-discuss at lists.opendev.org mailing list. Similarly Zuul has the https://matrix.to/#/#zuul:opendev.org Matrix room and zuul-discuss at lists.zuul-ci.org mailing list. - Bruno Muniz showed interest in creating DOC Videos supporting the StarlingX Installation Process. To check with Ildiko / Greg whether this is ok. These Videos can be hosted in a location in StarlingX. The Installation Docs can point to these videos - AR Bruno to get approvals from Ildiko / Greg - Sphinx Tools - Need to have further discussions about the version used upstream vs. downstream - AR Ron -To determine version. - Docker Container upstream / downstream - AR Ron (Discuss it with Greg / Ildiko) - Operations Guide Archive - On Hold until further clarifications are discussed with Greg (https://review.opendev.org/c/starlingx/docs/+/822030) - OpenInfra Summit & PTG Recording: https://ptg.opendev.org/etherpads.html - Workshop Details are tracked in https://etherpad.opendev.org/p/stx_hands_on_workshop_2023 - IRC: Everyone to use the IRC channel for communication with the community. Team can use https://www.icechat.net/site/icechat-9/ as an alternate text editor from their browser. IRC is a chat platform, for text-based communication. There's a web client for easy access: https://webchat.oftc.net/- You need to pick a nickname, and the channel name is #opendev. Once you are in the #opendev channel, you can talk to the group of people in that channel. To Setup IRC - contributor-guide documentation (openstack.org) IRC here: https://docs.openstack.org/contributors/common/irc.html; Engineering Status: StarlingX Eng Stx Status: https://etherpad.opendev.org/p/stx-status StarlingX Eng Status 2023 https://etherpad.opendev.org/p/stx-cores ____________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.friesen at windriver.com Thu Jun 29 15:22:02 2023 From: chris.friesen at windriver.com (Chris Friesen) Date: Thu, 29 Jun 2023 09:22:02 -0600 Subject: [Starlingx-discuss] proposal to add Jim Gauld for core reviewer in the "config" repo Message-ID: Jim Gauld has been around for a long time and has a deep historical knowledge of the StarlingX project.? He has been dealing with quite a few issues in the config repo, mostly related to Kubernetes issues and upgrades and has an excellent understanding of how the pieces fit together. As such, I'd like to propose Jim as an addition to the core reviewer list for the config repo. Thanks, Chris From Michel.Thebeau at windriver.com Wed Jun 28 19:50:53 2023 From: Michel.Thebeau at windriver.com (Thebeau, Michel) Date: Wed, 28 Jun 2023 19:50:53 +0000 Subject: [Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization Message-ID: Hi, I prepared the following description of enhancements I intend towards the libvirt virtual deployment method. Please let me know I should follow a particular procedure. Otherwise I intend to create a story in storyboard. Mitch. === Starlingx Libvirt deployment method host utilization enhancements References: "Install StarlingX Kubernetes in a virtual environment" - https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html#index-install-r7-8966076f0e81 Libvirt deployment method in starlingx/tools - https://opendev.org/starlingx/tools/src/branch/master/deployment/libvirt Libvirt deployment method moved this week to starlingx/virtual-deployment - https://opendev.org/starlingx/virtual-deployment/src/branch/master/libvirt Motivation is to: A) maintain attributes for more than one virtual lab B) improve the usage and selection of the host's resources for disk, memory and cpu C) isolate cluster networks where more than one virtual lab may be running Philosophy of continuity: Introduce changes and developments in continuity with established examples and approaches. - Maintain the existing examples for default setting and the 'mad' override. - Establish regression test based on the default setting and 'mad' override to ensure that a user of the deployment method can continue to do the same thing they used to do. - Maintain and extend the use of overridable variable definitions for the attributes of a lab. - Maintain and extend the use of command line parameters for configuration selection, such as "-c 'simplex'". - Maintain and extend the existing workflow: "exporting variables, setup_network.sh, setup_configation.sh, destroy_configuration.sh, destroy_network.sh". A) Maintain configurations for more than one virtual cluster: Motivation: allow a lab's attributes to be recalled from a configuration file and operate upon that lab specifically. Establish a precedent for a configuration file used to override the default attributes. Refer to the README.rst "Overview" section which lists environment variables CONTROLLER, WORKER, BRIDGE_INTERFACE, EXTERNAL_NETWORK, EXTERNAL_IP. Provide a default configuration file that will reset the variables to defaults as they currently exist within the deployment/libvirt scripts, including: BRIDGE_INTERFACE=${BRIDGE_INTERFACE:-stxbr} EXTERNAL_NETWORK=${EXTERNAL_NETWORK:-10.10.10.0/24} EXTERNAL_IP=${EXTERNAL_IP:-10.10.10.1/24} CONFIGURATION=${CONFIGURATION:-simplex} CONTROLLER=${CONTROLLER:-controller} WORKER=${WORKER:-worker} STORAGE=${STORAGE:-storage} WORKER_NODES_NUMBER=${WORKER_NODES_NUMBER:-1} STORAGE_NODES_NUMBER=${STORAGE_NODES_NUMBER:-1} Provide an example configuration file that sets a lab's attributes deviating from the default. Especially, the default and the example should co-exist. Consider honouring the "mad" example in README.rst. If necessary provide an option to select values, or a script to set variables, from that configuration file. B) Improve usage and selection of host's resources: Motivation: allow lab specific attributes for the host's resources and provide tools to inspect those resources within the contexts of the virtual labs and/or overall Note: Ensure that all changes are providing defaults that are equivalent to the existing implementation. Values to add to the lab's attributes: Add DOMAIN_DIRECTORY to the set of overridable variables Add an override variable for the DISK file location for each node in a virtual lab. (currently hardcoded /var/lib/libvirt/images in functions.sh) Add an override variable for the MEMORY setting for each node (currently XML hardcoded ) Add an override variable for the CPU setting of each node (currently XML hardcoded ) Add scripting to assist with supervising the host's resources, such as: - listing the lab's nodes and networks; - inspecting the lab's network configurations; - inspecting the host's and lab's disk usage per configured disk; - listing a lab's nodes' cpu and memory allocations C) Isolate cluster networks where more than one cluster may be running: Motivation: on a host that has a capacity to run virtual clusters, ensure that there is no networking crosstalk between the running clusters. Provide scripting to add/remove iptables restrictions for a lab's networks. Initially assume no inter-cluster communication, and only the OAM network will route to external networks. Include: - ipv4 and/or ipv6 - a lab specific iptables CHAIN Probably: omit running this script automatically, since it changes the deployment behaviour. Consider adding an optional parameter to setup_network.sh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Juanita.Balaraj at windriver.com Fri Jun 30 15:40:51 2023 From: Juanita.Balaraj at windriver.com (Balaraj, Juanita) Date: Fri, 30 Jun 2023 15:40:51 +0000 Subject: [Starlingx-discuss] Canceled: StarlingX Docs Team Call Message-ID: Cancelling the Wednesday StarlingX DOCS Team Meeting at 3.30 EST and moving it to Thursday's 9.00 a.m. EST. See Details below. New time slot starting from July on Thursday's each week for the StarlingX Docs Team call: 6:00 am PST. Call Details: * Meeting Link: https://meetpad.opendev.org/stx-documentation * Password: stxdocs Agenda and meeting minutes * The agenda and notes for each call are kept here: https://etherpad.openstack.org/p/stx-documentation -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3246 bytes Desc: not available URL: