April 2020 - openstack-discuss - lists.openstack.org

[PTL][SIG] Virtual PTG Layout & Signup
by Kendall Nelson 19 Apr '20

19 Apr '20

Greetings! I am sure you have all been anxiously awaiting more details on how we are going to virtualize the PTG :) After the community meetings we had last week/the week before to understand the key challenges and ideate on solutions, we have a plan! The virtual event will be held from Monday June 1 to Friday June 5. We set up available times in 3 different time windows where each window is a cross over time between at least 2 regions (Window A - Americas/Europe, Window B - Europe/APAC, and Window C - APAC/Americas). Here is an ethercalc[1]. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions in with 4 rules/guidelines. 1. Cross project discussions (i.e. SIGs and horizonal teams), try to schedule yourselves towards the start of the week so that any discussions that might shape those of vertical teams might happen first. 2. Vertical teams (ex. Nova, Cyborg, Manila) should wait till April 6th at 7:00 UTC to start signing up for slots to help prioritize the scheduling of cross project conversations. 3. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 4 hours per UTC day to help keep participants actively engaged. 4. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 16 hours across all time slots to avoid burning out our contributors and to enable participation in multiple teams discussions. Once every team has had a chance to sign up (lets say two weeks from today April 28th at 7:00 UTC) if signing up for more time makes sense, it will be possible. We want to encourage ANY team to sign up, even those that had originally said no to the initial outreach when the PTG was supposed to be in person. The more the merrier! Once you have signed up for time slots, please also fill out this survey[2] with your team information. We need this additional information to help shape other decisions down the road and coordinate other details closer to the event. If you have any issues with signing up your team, due to conflict or otherwise, please let me know! While we are trying to empower you to make your own decisions as to when you meet and for how long (after all, you know your needs and teams timezones better than we do), we are here to help! Continue to check back for updates at openstack.org/ptg. -the Kendalls (diablo_rojo & wendallkaters) [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey

11 20

[goals][Drop Python 2.7 Support] Week R-4 Update
by Ghanshyam Mann 18 Apr '20

18 Apr '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-4 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * Storlets wanted to keep py2.7 as Swift doing which is a valid request. Revert of py2.7 drop patches is ins progress. I am updating the goal doc also - https://review.opendev.org/#/c/720714/1 * Reaching out to individual projects PTL to merge the pending patches. If not done by next week. I am going to leave those from tracking which are pending for a long time but not getting attention from the team. They will fail the gate or already failing due to almost all projects are py3-only. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Pending Tempest plugins: ** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ I have replied to the comments on this patch. * Pending pythonclient: ** python-barbicanclient: https://review.opendev.org/#/c/699096/2 *** gate is already broken waiting for gate to be fixed. ** python-zaqarclient: https://review.opendev.org/#/c/692011/4 * Few more repo patches need to merge: ** masakari-specs: https://review.opendev.org/#/c/698982/ ** nova-powervm: https://review.opendev.org/#/c/700683/ ** paunch: https://review.opendev.org/#/c/703344/ * Deployment projects in progress: *** Openstack Charms - Most of them merged, few failing on func job. debugging. *** Openstackansible - In-progress. centos7 jobs are failing on few projects. ** Waiting from projects team to know the status: *** Openstack-Helm (Helm charts for OpenStack services) **** Discussion going on - http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013814.ht… * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work. I have started this and reaching out to projects need more work. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

1 0

[election][nova] PTL Candidacy for Victoria
by Balázs Gibizer 18 Apr '20

18 Apr '20

Hi, I'd like to announce my candidacy for Nova PTL for Train. I'm a long time Nova contributor and Nova core since 2017. I'm currently serving as temporary Nova PTL since we lost Eric during the Ussuri cycle. We are facing multiple challenges for Victoria. We have to organize the first fully virtual PTG to plan the Victoria cycle due to sever travel restrictions around the word. I have already proposed ways [1] to the Nova team and I will continue working on making the best out of the current situation. In the past months we have lost Matt and Eric, two key contributors and Nova maintainers. So I will work on regrowing the Nova core team to restore our review bandwidth. As a first step I proposed two new Nova core members [2][3]. But I will also look for more possible candidates and I will try to mentor them to further increase the size of the core team. We have many unfinished business from the Ussuri cycle. So as a PTL I have the intention to make the team focus on finishing these work before we start any new big change in Nova. Thanks, Balazs Gibizer (gibi) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013555.ht… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013511.ht… [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013519.ht…

3 2

[tripleo] TripleO CI Summary: Unified Sprint 25
by Rafael Folco 17 Apr '20

17 Apr '20

Greetings, The TripleO CI team has just completed **Unified Sprint 25** [0] (Mar 27 thru Apr 16). The following is a summary of completed work during this sprint cycle [1]: - Contributed for TripleO-Operator-Ansible. - Internal component pipeline prep work: created the artifact requirements to build the pipeline (container and overcloud image builds). - Created an unified tempest test skip list <https://opendev.org/openstack/openstack-tempest-skiplist>. - Started migrating promoter jobs to CentOS8 and a new design for loading promoter configurations from multiple sources. - Migrated fs039 free ipa job to CentOS8 and fixed podman molecule testing. - Worked on collect-logs fixes for openstack-ansible jobs. - Restarted work on an upstream standalone TLS job - Started work to validate ansible 2.9 and the latest ceph-ansible - Started work on an ironic tempest plugin - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on the following: - Stable branching work (ussuri): design ussuri jobs migration and do the prep work for moving upstream and periodic jobs. - TripleO-Operator-Ansible: contribute w/ code, docs, tests and zuul jobs. - Internal component pipeline: continue building the pipeline with the artifacts and jobs created in the previous sprint. - Shared Tempest role design. - 3rd party CI jobs naming alignment. - Continue work on an upstream standalone TLS job - Continue work to validate ansible 2.9 and the latest ceph-ansible - Refine the design for refactoring, consolidation and de-duplication of get_hash role across repositories. The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Amol Kahat (akahat). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [4]. Thanks, rfolco [0] Note: Unified Sprint 25 corresponds to “Sprint 45”. We also combined “Unified Sprints 24/25” to align with other TripleO DFGs after getting out of sync at the 2019 end of year shutdown. From now on we are going to refer to sprints with the “Unified Sprint” naming convention. [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-25 <https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-24> [2] https://hackmd.io/XMd_vskSTdGZl7ruZ1UckA [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-26 [4] https://hackmd.io/rKRieheXTtyIDtGHiiF-hQ

1 0

[ops] [nova] Default nova quota for project user
by Massimo Sgaravatto 17 Apr '20

17 Apr '20

Hello As far as I understand by default each project user is given the quota of the whole project. Is it possible to set a different default quota for users of a certain project ? And in general I'd like to be able to define different default values for different projects In: https://docs.openstack.org/nova/latest/admin/quotas.html it is explained how to update the quota for a specific project user, but I can't find how to set the default user quota for a given project Thanks, Massimo

3 5

[TripleO][Ansible] generating ansible.cfg for manual config-download
by Federico Iezzi 17 Apr '20

17 Apr '20

Hey there, I've recently played with Config-Download in TripleO. My aim was since the begging running Ansible standalone w/o relying on Mistral. TripleO Ansible [1] can introduce drastic flexibility, IMO much needed to improve the overall experience. Now, the major road blocker I found, was in relation of Ceph-Ansible. Without the nice ansible.cfg from Mistral, it's pretty much a bit hard running Ansible standalone. Yes, manually exporting the various Ansible paths can do the trick, but down the road, more and more roles may be introduced forcing users to always discover the latest ones. For example, in my case without the original ansible.cfg, the issue was the following braking ceph-ansible. $ ansible-playbook -i inventory.yaml --private-key ~/.ssh/id_rsa --become deploy_steps_playbook.yaml The error appears to be in '/home/stack/config-download/external_deploy_steps_tasks.yaml': line 13, column 13, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - import_role: role: ceph ^ here To solve it, I wrote this simple [2] Python script that relies on write_default_ansible_cfg from ansible in tripleo_common. The result is that, after the heat provisioning [3] I generate the config-download folder (with all its contents), the inventory and also the ansible.cfg file and ansible standalone can be executed called. You can find my templates and work at [4] What do you think about including the ansible.cfg as part of the config-download generation procedure? Cheers, Federico [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deploym… [2] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/write_defa… [3] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/005-deploy… [4] https://github.com/m4r1k/nfvi_lab/tree/osp16

3 4

[all] Removing Babel from requirements.txt
by Dmitry Tantsur 17 Apr '20

17 Apr '20

Hi folks, Many of the projects have [1] Babel in requirements.txt. I'm not sure why it was needed initially, but now Babel is only used in the translation infrastructure to manage the catalogs. Particularly, it's not imported in runtime by anything (oslo.i18n has recently removed [2] its usage). The problem is, Babel weighs nearly 30MiB (estimated on a venv), making it probably the heaviest dependency we have. According to amotoki, we don't need Babel anywhere in the requirements, since the translation infrastructure installs it explicitly [3][4]. Sphinx has a requirement on Babel, so doc and release note builds will be fine as well. I suggest that all projects remove an explicit requirement on Babel completely. I've started proposing changes [5] to implement it for repositories that are used by ironic projects (since it's my immediate area of interest). I'd appreciate help with the others. Dmitry [1] http://codesearch.openstack.org/?q=Babel&i=nope&files=requirements.txt&repo… [2] https://review.opendev.org/720550 [3] https://opendev.org/openstack/project-config/src/branch/master/playbooks/tr… [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-babel/tas… [5] https://review.opendev.org/#/q/topic:no-babel

3 2

[ops] RabbitMQ Config suggestions for > 100 nodes?
by Fabian Zimmermann 17 Apr '20

17 Apr '20

Hi, we run some openstack clusters and currently see issues with a lot connections in rabbitmq. So I would like to ask if someone here has some knowhow about running openstack on >100 nodes he is able to share. Our setup: * 3 Nodes Control-Plane * RabbitMQ Cluster with "sync_mode: all" (had issues during node-failure in the past without this) * transport_url contains all 3 nodes Most of the connections are neutron-based. We already played a bit with max_pool and max_pool_overload, but didnt change anything. As next try I would add some haproxy-lb and change the transport_url to the VIP, this should afaik reduce the amount of connections to 1/3, but I dont know if there are any drawbacks jet. Any suggestions? Thanks a lot, Fabian

3 2

[qa][devstack] Moving to release specific nodesets and jobs for Fedora
by Lee Yarwood 16 Apr '20

16 Apr '20

Hello all, $subject has come up with the last couple rounds of changes introducing support for the latest version of Fedora within devstack. I've pushed a change introducing version specific nodesets and jobs for Fedora 31 as a way of starting a discussion around this ahead of the PTG: WIP Fedora: Start using version specific nodesets and jobs https://review.opendev.org/#/c/719775/ I'm personally on the fence about this as while it would be nice to have version specific nodesets and jobs it does introduce a lot of churn with each new release of Fedora across many projects: http://codesearch.openstack.org/?q=fedora%5C-latest Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

4 5

[QA][barbican][cloudkitty][heat][ironic][magnum][manila][monasca][swift] Intermediary release reminder
by Sean McGinnis 16 Apr '20

16 Apr '20

Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest ussuri release available on release week. The following deliverables have done a ussuri release, but it has not been refreshed in the last two months: Quality Assurance patrole barbican barbican-ui cloudkitty cloudkitty heat heat-agents ironic bifrost ironic-inspector ironic-prometheus-exporter ironic-python-agent ironic-ui ironic networking-baremetal networking-generic-switch magnum magnum-ui manila manila-ui monasca monasca-thresh monasca-ui swift swift There are still a couple weeks to go, so this is just a reminder that you should consider making a new one very soon, so that we don't use an outdated version for the final release. Just let me know if there any questions. Thanks! Sean

3 4