May 2020 - openstack-discuss - lists.openstack.org

[tc] changing meeting time
by Mohammed Naser 01 Jun '20

01 Jun '20

Hello everyone, The PTG is happening online next week, on the same day as our TC monthly meeting. Since the PTG is only every six months, and we will meet the month after, how does everyone feel about skipping this month's meeting and considering the PTG as our meeting instead? Your comments are appreciated, Thanks, -- Mohammed Naser VEXXHOST, Inc.

5 4

[nova][ptg] Documentation in nova
by Stephen Finucane 01 Jun '20

01 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Our documentation in nova is suffering from bit rot, the ongoing effects of the documentation migration during Pike (I think), and general lack of attention. I've been working to tackle this but progress has been very slow. I suggested this a couple of PTGs ago, but once again I'd like to explore going on a solo run with these by writing and self-approving (perhaps after a agreed interval) *multiple* large doc refactors. I've left some notes below, copied from the Etherpad, but in summary I believe this is the only realistic way we will ever be able to fix our documentation. Cheers, Stephen [0] https://etherpad.opendev.org/p/nova-victoria-ptg --- Documentation reviews are appreciated but are generally seen as low priority. See: * https://review.opendev.org/667165 (docs: Rewrite quotas documentation) * https://review.opendev.org/667133 (docs: Rewrite host aggregate, availability zone docs) * https://review.opendev.org/664396 (docs: Document how to revert, confirm a cold migration) * https://review.opendev.org/635243 (docs: Rework the PCI passthrough guides) * https://review.opendev.org/640730 (docs: Rework all things metadata'y) * https://review.opendev.org/625878 (doc: Rework 'resize' user doc) * ... I (stephenfin) want permission to iterate on documentation and merge unilaterally unless someone expresses a clear interest Pros: * Documentation gets better * I can iterate *much* faster Cons: * Possibility of mistakes or "bad documentation is worse than no documentation" * Counterpoint: Our documentation is already bad/wrong and is getting worse due to bitrot. * Better is subjective * Counterpoints: The general structure of the patches I listed above was accepted in each case, I have other projects I have authored to point to (e.g. patchwork.readthedocs.io/) * Merge conflicts * Counterpoint: It's docs. Just drop these (non-functional) hunks if it's awkward.

4 4

[openstack-helm] IRC Meeting Cancelled - June 02nd
by Gage Hugo 31 May '20

31 May '20

Hello everyone, The openstack-helm meeting this week, June 02nd, will be cancelled due to the PTG happening this week. We will continue regular meetings again next week.

1 0

[security] Security SIG meeting June 04th Cancellation
by Gage Hugo 31 May '20

31 May '20

Hello everyone, The Security SIG meeting this week, June 04th, will be cancelled due to the PTG happening this week. We will continue regular meetings again next week.

1 0

[openstack-helm] OpenStack-Helm PTG Schedule
by Gage Hugo 31 May '20

31 May '20

Hello, The OpenStack-Helm team will be meeting for the PTG on Tue, June 2nd and Wednesday, June 3rd from 1300-1700 UTC. The current agenda etherpad can be found here[0]. Hope to see you there! [0] https://etherpad.opendev.org/p/openstack-helm-ptg-victoria

1 0

[security] Security SIG PTG Schedule
by Gage Hugo 31 May '20

31 May '20

Hello, The Security SIG will be meeting for the PTG on Monday, June 1st from 1500-1700 UTC & 2100-2300 UTC. The current agenda etherpad can be found here[0]. Hope to see you there! [0] https://etherpad.opendev.org/p/security-sig-ptg-victoria

1 0

[neutron] Drivers meeting on Friday 5.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, It's PTG time so lets cancel this week meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] CI meeting on Wednesday 03.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, It's PTG time so lets cancel this week CI meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] Team meeting on Tuesday 02.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, We have PTG sessions in same time, so lets cancel IRC meeting this week. See You all on the PTG sessions :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[scientific-sig] Virtual PTG sessions on Monday
by Stig Telfer 31 May '20

31 May '20

Hi All - We have the Scientific SIG sessions at the PTG on Monday at 15:00-17:00 UTC and 21:00-23:00 UTC. Everyone is welcome. We have been gathering details and planning content in the Etherpad provided at https://etherpad.opendev.org/p/victoria-ptg-scientific-sig <https://etherpad.opendev.org/p/victoria-ptg-scientific-sig> The broad plan is to try to get a little more in-depth than our usual discussions on IRC and Slack, and for people to bring topics for discussion to share information with other science cloud operators in the SIG. Good topics would be pain points, problems, functional gaps, etc, for which others might have creative solutions. Cheers, Stig

1 0

[swift] Object Versioning: How to retrieve old versions of deleted objects?
by Bernd Bausch 31 May '20

31 May '20

According to documentation of Swift's new object versioning middleware [1], a deleted object won't be visible but previous version content is still recoverable. Documentation doesn't say how, though. After deleting /myobject/, I can see its versions: $ openstack object delete testcontainer myobject $ curl http://192.168.1.200:8080/v1/$ACCOUNT/testcontainer?versions -H "x-auth-token: $T" | python -m json.tool | grep -e version_id -e name "name": "myobject", "version_id": "1590896642.07497" "name": "myobject", "version_id": "1590892906.83929" "name": "myobject", "version_id": "1590892899.36921" But I can't GET old versions of /myobject/: $ curl -i http://192.168.1.200:8080/v1/$ACCOUNT/testcontainer/myobject?version-id="1590896642.07497" -H "x-auth-token: $T" HTTP/1.1 404 Not Found After creating another object with the same name /myobject/, old versions are accessible again. This is a solution, but dare I say not a very elegant one. *Can **a deleted, versioned object be recovered without creating a dummy object with the same name?* [1] https://docs.openstack.org/swift/latest/middleware.html#object-crud-operati…

1 1

Dropping python2.7 from diskimage-builder
by Monty Taylor 29 May '20

29 May '20

Heya, I just pushed up: https://review.opendev.org/728889 Drop support for python2 Which drops support for installing diskimage-builder using python2. It doesn’t drop support for in-image python2, that would be a whole different story. It seems that since the two largest DIB users, OpenStack and Zuul, are both now python3 only, it’s a safe move to make. IBM PowerKVM CI is running third-party CI with python2-based tests. We should probably either update those or just drop it? Thoughts? Monty

8 9

[tripleo] TripleO CI Summary: Unified Sprint 27
by Rafael Folco 29 May '20

29 May '20

Greetings, The TripleO CI team has just completed **Unified Sprint 27** (May 07 thru May 27). The following is a summary of completed work during this sprint cycle [1]: - Completed stable branching work (ussuri). - Internal pipeline: created integration and component jobs. - Continued to fix promoter tests on CentOS8 and built an internal promoter server. - Submitted change reviews for the TripleO IPA multinode job. - Started backporting to train - Built CentOS8 train full promotion pipeline and a job to upgrade from train to ussuri. - Landing these jobs in upstream soon - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on creating tests for ci-config repository. The Ruck and Rover for this sprint are Rafael Folco (rfolco) and Poja Jadhav (pojadhav). 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 [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-27 [2] https://hackmd.io/2MdkNAUuT7aBcM0Yck4xnw [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-28 [4] https://hackmd.io/YAqFJrKMThGghTW4P2tabA -- Rafael Folco Senior Software Engineer

1 0

[Diversity] [PTG] Diversity WG at PTG
by Amy Marrich 29 May '20

29 May '20

The Diversity and Inclusion WG will be having a session at 16:00 UTC on Monday at https://meetpad.opendev.org/PTGDiversityAndInclusion As a WG reporting to the OSF Board we would like to invite all OSF projects to come and learn what the WG can do for their project. The WG oversees the Diversity and Inclusion surveys as well as the OpenStack mentoring program. Hope to see new faces on Monday! Amy Marrich (spotz)

1 0

[heat] Deprecations in heat stack / apis
by prakash RAMCHANDRAN 29 May '20

29 May '20

Hi all, Can heat team send us representation for Heat Interop testing. Based on the triplo deprecating tripleo-heat-template, appears there are deprications and we did have been requesting help to review the add-ons to interop refer : https://github.com/openstack/interop/blob/master/next.json& https://github.com/openstack/interop/blob/master/2020.06.json& https://github.com/openstack/heat-tempest-plugin/blob/master/heat_tempest_p… Add you topics to support Heat orchestrtion for interop.https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_20… ThanksPrakash - Chain Interop WG

3 3

[cinder] PTG schedule
by Brian Rosmaita 29 May '20

29 May '20

The Cinder team will be meeting in the zoom Diablo room, Tuesday-Friday 1300-1600 UTC. Make sure you register for the PTG so you will receive the passwords to the video meeting: https://virtualptgjune2020.eventbrite.com/ The complete schedule for the PTG is here: https://www.openstack.org/ptg#tab_schedule Although Cinder won't be meeting on Monday, there are plenty of interesting sessions you can attend. See this helpful email for general PTG info: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html The official Cinder etherpad for the PTG is: https://etherpad.opendev.org/p/victoria-ptg-cinder It contains the schedule. Please look it over so you can see when you'll be leading a discussion. Feel free to enhance any topic with additional information or questions. The schedule is organized like this: Tuesday - Current Cinder Issues Wednesday - Third Party Drivers Thursday - Cinder Improvements Friday - Cross-Project and Cinder Project Business see you next week! brian

1 0

[oslo] PTG Plans
by Ben Nemec 29 May '20

29 May '20

Hi, Sorry for the late notice on this. Many firedrills this week. I've made some updates to the etherpad[0] to reflect more concrete plans for both location and timing of topics. It worked out to just give everything 15 minutes for the first hour, and I reserved the second hour for cross-project discussions with Nova. As always, we can be flexible with the scheduling if something needs more or less discussion. The only timing constraint I saw mentioned was that Thierry needed the oslo.metrics topic to be early, so he gets to go first. :-) I also added a meetpad URL there. We used Jitsi pretty successfully for our previous virtual PTG so I don't see any reason to move off the open platform. I suggest trying to join ahead of time to make sure everything works for you. We do have a Zoom reserved for that time as well in case something catastrophic happens. If you have any concerns about the plan, let me know ASAP. Otherwise I'll see you all on Monday! -Ben 0: https://etherpad.opendev.org/p/oslo-victoria-topics

1 0

Re: [all][dev][qa] cirros 0.5.1
by Radosław Piliszek 29 May '20

29 May '20

Hello OpenStack Folks! Since it's early in the Victoria cycle, it's a good time to revisit the cirros 0.5.1 migration in common CI. The patch [1] is getting a cleanup due to nova fix increasing instance memory limits upfront but I propose to merge it as soon as we clean it up properly. It has been tested with Ussuri in Kolla CI and had positive results from Tempest jobs for Neutron and Ironic. It would be great if we made sure projects no longer use the old cirros 0.4.0 nor some old Ubuntus. [1] https://review.opendev.org/711492 -yoctozepto

1 1

[TripleO][rdo][train][centos7] fails at ovn_south_db_server: Start containers for step 4 using paunch
by Ruslanas Gžibovskis 29 May '20

29 May '20

Hi all, I am running this deployment described here [1]. I am getting error on: Start containers for step 4 using paunch Error in link bellow [2] Running podman containers [3] links: 1 - https://github.com/qw3r3wq/homelab/tree/master/overcloud 2 - https://pastebin.com/HTUbz7Ry 3 - https://pastebin.com/1ApfiEyE -- Ruslanas Gžibovskis +370 6030 7030

3 5

[puppet] Puppet 5 is officially unsupported in Victoria release
by Tobias Urdin 29 May '20

29 May '20

Hello, Just a heads up that we've had a warning in the Ussuri release about it being the last release where we are going to support Puppet 5. This patch [1] was now submitted to remove this warning and officially state that Puppet 5 is unsupported from the Victoria release. [1] https://review.opendev.org/726310?

4 20

[tripleo] better observability into containers management in the post-paunch world
by Bogdan Dobrelya 29 May '20

29 May '20

Hello, as you may know, Paunch [0] was originally developed for simple containers management in TripleO. Today we have Paunch deprecated for the preference of ansible module [1]. It uses ansible async executions and performs management actions in batches. While that's great and novel and works faster, Paunch's logs were simple to follow and its code was easy to debug with pdb breakpoints. Howewer, debugging experience and overall observability (please excuse me that buzzword) has changed [2], when switched it to ansible. In order improve that situation, I propose that data aggregator [3] for post-processing of the containers data under the module's management. It is based on setting facts, using already developed custom filters [4], and ansible's set_stats [5]. That data is just a (big) dictionary that contains: * input containers configs fetched from json files for all deploy steps, * snapshotted runtime info as it was consumed by the containers management tasks, * internal processing results (identified logical state, like 'changed' or 'broken') That is for all of the batches of managed containers in a deployment, per hosts basis. And that's basically it. How to use that data is out of scope at this point of discussion. Please share your thoughts on the topic. Note that the aggregator itiself is simple (~140 LOC). Please don't call it over-engineered :) It *only* allows users and tripleo devs to build whatever complex and over-engineered data analysing pipelines on top of it. Those may be colored graphs of dependencies and states, or simple json parsing, like that prototype [5] (WIP, only for a standalone deployments). Wrapping it up, it's up to devs and users how to use that data aggregator. Let's just simplify their lives with debugging containers management framework please. [0] https://opendev.org/openstack/paunch [1] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [2] https://launchpad.net/bugs/1879455 [3] https://review.opendev.org/#/q/topic:bug/1879455 [4] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [5] https://docs.ansible.com/ansible/latest/modules/set_stats_module.html -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[tripleo] Deprecating tripleo-heat-templates firstboot
by Steve Baker 28 May '20

28 May '20

Soon nova will be switched off by default on the undercloud and all overcloud deployments will effectively be deployed-server based (either provisioned manually or via the baremetal provision command) This means that the docs for running firstboot scripts[1] will no longer work, and neither will our collection of firstboot scripts[2]. In this email I'm going to propose what we could do about this situation and if there are still unresolved issues by the PTG it might be worth having a short session on it. The baremetal provisioning implementation already uses cloud-init cloud-config internally for user creation and key injection[3] so I'm going to propose an enhancement the the baremetal provisioning yaml format so that custom cloud-config instructions can be included either inline or as a file path. I think it is worth going through each firstboot script[2] and deciding what its fate should be (other than being deprecated in Ussuri): https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… This has no parameters, so it could be converted to a standalone cloud-config file, but should it? Can this be achieved with kernel args? Does it require a reboot anyway, and so can be done with extraconfig? https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… I'm not sure why this is implemented as first boot, it seems to consume the parameter |NetConfigDataLookup and transforms it to the format os-net-config needs for the file ||/etc/os-net-config/mapping.yaml. It looks like this functionality should be moved to where os-net-config is actually invoked, and the |||NetConfigDataLookup parameter should be officially supported. || | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_dev_rsync.yaml| |I suggest deleting this and including a cloud-config version in the baremetal provisioning docs.| |||| |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_heat_admin.yaml| |Delete this, there is already an abstraction for this built into the baremetal provisioning format[4]| | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_root_password.yaml| |Delete this and include it as an example in the baremetal provisioning docs.| | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_timesync.yaml| |Maybe this could be converted to an extraconfig/all_nodes script[5], but it would be better if this sort of thing could be implemented as an ansible role or playbook, are there any plans for an extraconfig mechanism which uses plain ansible semantics?| | | |cheers | [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… [2] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… [3] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [4] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [5] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/extr…

3 5

[tripleo] PTG next week
by Wesley Hayutin 28 May '20

28 May '20

Greetings, PTG is next week. Please update the schedule if you have posted a topic Please register if you have not yet.. https://virtualptgjune2020.eventbrite.com/ All the information you should need should be posted on the following link. https://etherpad.opendev.org/p/tripleo-ptg-victoria See ya next week :)

1 0

[tc] Monthly meeting
by Mohammed Naser 28 May '20

28 May '20

Hi everyone, Our monthly TC meeting is scheduled for next Thursday, June 4, at 1400 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, June 3, at 1900 UTC. Thank you. -- Mohammed Naser VEXXHOST, Inc.

1 0

[tripleo] Deprecating Paunch in Ussuri
by Emilien Macchi 28 May '20

28 May '20

Hi folks, In Ussuri we manage to successfully replace Paunch by Ansible (role + modules) to manage the container lifecycle in TripleO. As a reminder, this effort was part of the Simplification work that is being done in TripleO to reduce our number of tools and align it with our deployment framework based on Ansible. https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_contai… Paunch has been turned off for some time now and isn't tested anymore in upstream CI (master only). I would like to propose its deprecation in Ussuri and a removal in Victoria (or later if any valid pushback). https://review.opendev.org/#/c/720598/ Thanks, -- Emilien Macchi

2 3