October 2021 - openstack-discuss - lists.openstack.org

[tc][operators][all] TC tags framework to be dropped
by Radosław Piliszek 30 Oct '21

30 Oct '21

Dear OpenStack Operators, Due to no response to the original query about usefulness of the TC tags framework [1] (which was repeated in each and every following TC newsletter), the TC has decided to drop the tags framework entirely. [2] [3] [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02480… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.… [3] https://etherpad.opendev.org/p/tc-yoga-ptg Kind regards, -yoctozepto

2 2

[OpenStack-Ansible] LXC containers apt upgrade
by Taltavull Jean-Francois 29 Oct '21

29 Oct '21

Hi All, Following the recent Let's Encrypt certificates expiration, I was wondering what was the best policy to apt upgrade the operating system used by LXC containers running on controller nodes. Has anyone ever defined such a policy ? Is there an OSA tool to do this ? Regards, Jean-François

2 2

[masakari] Yoga PTG summary
by Radosław Piliszek 29 Oct '21

29 Oct '21

Hi! This is a quick summary of Masakari's Yoga PTG. Quick as the PTG itself was quite quick. :-) We have summarised the progress made in Xena and decided to continue the efforts related to supporting monitoring with Consul and tracking issued evacuations. We have also discussed one new topic regarding circuit breaking in case of a mass failure of instances (e.g., due to a storage network failing in one location). To this end, the proposal is to introduce a protection mechanism (circuit breaking) based on a static time window (static at least in the first iteration) per segment. suzhengwei is to write the spec for this. Raw notes are available at https://etherpad.opendev.org/p/masakari-yoga-ptg Kind regards, -yoctozepto

1 0

[sahara][ptg] Yoga PTG Summary
by Juntingqiu Qiujunting (邱军婷) 29 Oct '21

29 Oct '21

Hi all: Thank everyone for taking time and attending session. The discussion content of the PTG meeting is as follows: https://etherpad.opendev.org/p/sahara-yoga-ptg 1、Sahara has supported boot virtual machine from volume. https://specs.openstack.org/openstack/sahara-specs/specs/backlog/boot-from-… 2、Sahara deploys a dedicated clusters need the network to be a flat one for instances. Could set up a "jumphost" which can be reached by the controllers, and that can reach the instances, need not the network to be a flat one for instance. https://docs.openstack.org/sahara/latest/admin/advanced-configuration-guide… 3、Discuss about which Plugins should be kept and updated and which ones should be dropped? The conclusion is that such as HDP、CDH、MapR Storm and Spark can be deleted in Yoga. 4、Improve the unit testing and documentation of Sahara project. Currently, the activity of the Sahara project is relatively low. We can discover its potential and expand its usage scenarios. Thank you Fossen --------------------------------- Fossen Qiu | 邱军婷 CBRD | 云计算与大数据研发部 T: 18249256272 E: qiujunting(a)inspur.com<mailto:qiujunting@inspur.com> 浪潮云海

1 0

[ptg][cinder] yoga virtual PTG summary
by Brian Rosmaita 29 Oct '21

29 Oct '21

Sorry for the delay, it's posted here: https://wiki.openstack.org/wiki/CinderYogaPTGSummary The wiki page contains links to all the recordings. It's a wiki page, so feel free to make clarifications or corrections. Action items are noted in the "conclusions" sections of most of the summaries, so please look to remind yourself what you have committed yourself to. cheers, brian

1 0

Problems with Openstack internal:external router
by Jibsan Joel Rosa Toirac 29 Oct '21

29 Oct '21

Hello I finished to set up a brand new Openstack server, I had already other up and running without any problems, yet on mine the router wich allows the external connection has all the interfaces down and I don't know what else to do. I've tried everything but it still not working. Please any help with this? I let you here a couple of screenshots of my network topology

1 0

[manila] FIPS compliance (Notice: third party drivers)
by Carlos Silva 29 Oct '21

29 Oct '21

Hello Zorillas and interested stackers! During the PTG week, we had a session where we discussed FIPS compatibility and compliance. In this PTG recording [1] you can see the discussion around this topic and our motivations to achieve such things for Manila. We're writing to follow up on the PTG discussion we had, and to update you on our move towards FIPS compatibility and compliance. We're aiming for manila FIPS compatibility with the Yoga cycle, meaning our CI jobs should be passing. FIPS compliance is a Z(orilla) cycle goal. For third party maintainers, to test if your code is FIPS compatible, use an image with fips enabled as discussed in [3]. In the etherpad we used in our previous discussion [2], there's a mention for some drivers that are using non-FIPS compliant libraries, and some examples of libraries that shouldn't be used. If FIPS is enabled in the controller where the driver is, and the driver is using one of the non permitted libraries, it will possibly lead the driver to malfunctioning. If you have any questions, please feel free to reach out to us (carloss and ashrod98) in #openstack-manila. We're always here to support our community. [1] https://youtu.be/mlTx71GIp1w?t=4864 [2] https://etherpad.opendev.org/p/yoga-manila-FIPS [3] https://etherpad.opendev.org/p/state-of-fips-in-openstack-ci-yoga Thanks! ---- Carlos da Silva (carloss) Ashley Rodriguez (ashrod98)

1 0

[kolla] Yoga PTG summary
by Michał Nasiadka 28 Oct '21

28 Oct '21

Hi everyone, Thank you all who participated in the PTG discussions and shared their thoughts and opinions. Here is the summary of the topics we have discussed: # General ## We agreed to stop using Launchpad’s Blueprints functionality (which was inconsistently used by us). ## We’ve discussed recently proposed services to Kolla: Adjutant has a complicated status now (vacant PTL seat and looking for contributors) Skyline Venus We agreed that a project can be added to Kolla/Kolla-Ansible once it fulfills following the criteria of being in OpenStack governance for 1 cycle and having 1 release. An exception to this criteria is when the patch content is in good quality and there are core reviewers interested in making this functionality merged (but still the project needs to be in OpenStack governance). ## We also discussed adding OSISM collection of Grafana dashboards and Prometheus Alertmgr rules in order to improve the “default deployment” experience for Kolla-Ansible users. ## There was a decision taken to finally retire kolla-cli (since it has been deprecated long time ago). # Kolla ## We have discussed deprecating and dropping of binary type of Kolla images: Pros: * less CI load, less maintenance burden (for a limited Kolla team), users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images CI jobs as voting) Cons: * User survey showed that a considerable amount of users is using them - unclear if because that’s a default - or they have chosen to do so. * Overriding package versions in source variant can be more troublesome than it is in binary Action plan: * Improve documentation for source images, especially focusing on its advantages and what might change for current users of binary (when they make the transition) * Mark binary images as deprecated in Yoga cycle (add a note about deprecation in kolla-build CLI output) * Improve override options for source images (upper-constraints, etc) ## The next discussion item was to use a common base (single Linux distribution) for Kolla images Action plan (to make it possible): * Fix Bifrost and OVN builds for Debian (which are broken now) * Create CI jobs for mixed host-os/in-container-image-os (including upgrade jobs) * Deprecate binary images after those two actions are done * Provide a decent plan with justification and operator feedback in https://etherpad.opendev.org/p/kolla-only-on-debian <https://etherpad.opendev.org/p/kolla-only-on-debian> * Deprecate CentOS only images (like qdrouterd) At the same time we agreed on not pursuing CentOS Stream 9 or Ubuntu 22.04 LTS image builds, when those will show up/be required. ## Migration from ElasticSearch to AWS OpenSearch (Elasticsearch fork after ES changed license) Action items: * Deprecate Elasticsearch in Yoga * Build OpenSearch in Yoga # Kolla-Ansible ## Podman support We agreed to implement it with as minimum Ansible playbooks/roles changes as possible (mainly rework kolla_docker.py) Action plan: * Reduce scope of existing patch to deploy a single service (e.g. MariaDB) * Write up a rough implementation plan in https://etherpad.opendev.org/p/kolla-docker-systemd-podman <https://etherpad.opendev.org/p/kolla-docker-systemd-podman> * Add systemd units support for existing Docker implementation * Add podman installation in Kolla-Ansible’s baremetal role * Add podman support upon systemd support for Docker ## Change default deployment to use ML2/OVN (instead of ML2/OVS) We agreed on the criteria to do so: * Debian OVN packages in Yoga * Working and reliable migration path * A way to prevent accidental migration to OVN for existing deployments And until that is resolved - we’re not going to pursue that decision. ## Keystone system scope continued Action plan: * Proposed to split into 3 parts ** use system scope for keystone admin user (done in Xena) ** assign admin role to service users with system scope ** provide flags to enable scope enforcement and new defaults ## Let’s Encrypt Resume efforts to implement it (since we upgraded to HaProxy 2.2 which enables seamless TLS key/cert replacement) ## More HA settings by default Action plan: * Add a docs HA page that describes typical Kolla-Ansible deployment (haproxy, galera cluster, etc) with references to other projects HA configurations (e.g. neutron, octavia) ## Rocky Linux Host OS support Proposal: Replace CentOS Stream support to Rocky Linux in the longer run Action plan: * Add support for Rocky Linux as Host OS (no Kolla container images) # Kayobe ## Multiple environments part 3 Proposed improvements: * merge OpenStack custom configs * merge Kolla Ansible group_vars * dependencies between environments * CI testing ## Support RAID with Bifrost via cleaning steps and deploy steps Action plan: * Add support to baremetal_node_action Ansible module for manual cleaning and passing deploy steps * Option: Enable automated cleaning to erase metadata * Add support for using this functionality to Bifrost * Add passing of deploy_steps and cleaning_steps from Kayobe to Bifrost ## Create collection(s) for external Ansible roles that Kayobe depends on (those from StackHPC namespace) * Group Kayobe external roles to collections (the whole ,,ecosystem’’ of stackhpc.* roles) * Encourage Kayobe role users to move to collections * Add/improve CI testing for the collection For details please check the Kolla Yoga PTG etherpad: https://etherpad.opendev.org/p/kolla-yoga-ptg <https://etherpad.opendev.org/p/kolla-yoga-ptg> And see you on the weekly meetings: https://meetings.opendev.org/#Kolla_Team_Meeting <https://meetings.opendev.org/#Kolla_Team_Meeting> Best Regards, Michal Nasiadka

1 0

答复: [cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

More details on etherpad: https://etherpad.opendev.org/p/cyborg-yoga-ptg brinzhang 发件人: Brin Zhang(张百林) 发送时间: 2021年10月28日 19:37 收件人: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> 抄送: 'xin-ran.wang(a)intel.com' <xin-ran.wang(a)intel.com>; Alex Song (宋文平) <songwenping(a)inspur.com>; Jorhson Deng (邓兆森) <dengzhaosen(a)inspur.com>; Juntingqiu Qiujunting (邱军婷) <qiujunting(a)inspur.com>; 'eric_xiett(a)163.com' <eric_xiett(a)163.com> 主题: [cyborg][ptg] Yoga PTG Summary Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0

[cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0