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

Retire openstack/networking-ovn
by Maciej Jozefczyk 21 Apr '20

21 Apr '20

Hello, During Ussuri cycle code from openstack/networking-ovn repository has been moved to openstack/neutron [1]. Neutron team will not accept any new changes to openstack/networking-ovn repository and we should retire this project. Patches are pushed with the topic:retire-networking-ovn <https://review.opendev.org/#/q/topic:retire-networking-ovn+(status:open+OR+…>, starting at [2]. [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge [2] https://review.opendev.org/#/c/721565/ -- Best regards, Maciej Józefczyk

2 3

[Watcher]IRC meeting on April 22
by licanwei 21 Apr '20

21 Apr '20

Hi, Tomorrow at 08:00 UTC on #openstack-meeting-alt. pls update the meeting agenda if you have something want to be discussed. Thanks, | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制

1 0

[tc] Self-nominations (or non-nominations) for TC Chair
by Jean-Philippe Evrard 20 Apr '20

20 Apr '20

Hello everyone, As we already have multiple candidates for chairing the TC candidates, we'll need to run some elections (create a poll), it will be easier than to vote on the multiple candidacies in governance. But before I can proceed ahead, I need the full list of candidates. As I haven't seen the reply from everyone in the tc channel, we'll need to have a nomination period. If you're interested to be the chair of the TC, please propose a patch in governance before Monday April 20, 2020 at 1100 UTC. If you don't intend to run, please also tell me: if I have answers from all the tc members before Monday (I already know the plans for mnaser, mugsie, evrardjp, njohnston, knikolla), we can proceed earlier. I will proceed with a private poll to your email addresses mentioned in governance repo. I am not specialist in civs, though, so any help is welcomed. The poll results will be as much anonymous as possible, and I will publish the anonymized results over the ML, as we did previously. Good luck to the candidates! Regards, Jean-Philippe Evrard (evrardjp)

1 2

[tc][congress] Retiring the Congress project
by Nate Johnston 20 Apr '20

20 Apr '20

Recently the TC has worked on determining the criteria for when an OpenStack project should be retired. When there was not a PTL nominee, that triggered the TC to review the health of the Congress project per [1], and the TC has determined [2] that development work on the Congress project has ceased. Based on that we are going to start the process of governance removal in the Victoria cycle as specified in the Mandatory Repository Retirement resolution [3] and detailed in the infra manual [4]. Pursuant to these procedures, Congress will move out of the opendev.org/openstack/ namespace and into the opendev.org/x/ namespace. If interest in Congress revives, development can restart in it's new location and potentially Congress could be re-added to OpenStack governance. Our thanks and appreciation to Eric and all of those who have contributed to the Congress project over the years. Thanks, Nate Johnston [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t202… [3] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [4] https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#retiring-…

2 2

[tc] TC Meeting time for Victoria cycle Leaderless projects discussions
by Ghanshyam Mann 20 Apr '20

20 Apr '20

Hello Everyone, As you know, PTL election is finished for the Victoria cycle and we have 6 projects without PTL nomination and 1 project with two late candidiacy[1]. TC will hold the two adhoc meetings for the leadership or the next plan discussions for these projects on IRC #openstack-tc channel. 1. April 20th: 3PM-4PM UTC 2. April 21th: 3PM-4PM UTC [1] https://etherpad.opendev.org/p/victoria-leaderless -gmann

1 0

OpenStack Murano "yaql" error
by İzzettin Erdem 20 Apr '20

20 Apr '20

Hello folk, Is there anyone who used murano before? I am trying to install Murano on devstack stable/train release. When i try to deploy an environment, it throws an error. At murona-engine logs error is: "func.__yaql_function__ = fd: murano.dsl.dsl_exception.MuranoPlException: [AttributeError]: 'method' object has no attribute '__yaql_function__'" Any suggestioıns? Thanks. Regards.

1 0

[keystone][horizon][keycloak] Custom error page possible?
by Paweł Cituk 20 Apr '20

20 Apr '20

Hi All, openstack version: Stain keycloak version: 8.0.0 I have configured keystone+horizon to use SSO (Keycloak). In Keycloak database there are two sorts of users: 1. Those who have attribute "domain" which is mapped into openstack's domain 2. Those who do not have this attribute If Keycloak's user without attribute "domian" or it is a non-existent user in keystone, is successfully authenticated (in Keycloak) then keystone returns json: {u'error': {u'message': u'The request you have made requires authentication.', u'code': 401, u'title': u'Unauthorized'}} How to configure keystone to return more user friendly error page (custom one)? If it's possible, then what about other services which they parse this reponse? Regards, Pawel

1 0

Edge sessions on the virtual PTG - ACTION NEEDED
by Ildiko Vancsa 20 Apr '20

20 Apr '20

Hi, I’m reaching out to you as I’m organizing the sessions for the OSF Edge Computing Group to go through edge related topics that are in interest on the official schedule[2] of the virtual PTG[1]. As this area is relevant for several OpenStack projects as well it would be great to have contributors of these projects attending the edge sessions and contribute to our discussions including cross-project collaboration related items. The working group members are currently considering to book three blocks (~2 hours) to cover reference architecture and testing discussions as well as topics that are in interest for cross—project collaboration. More details are on our PTG planning etherpad[3]. I created a Doodle poll[4] with time slots that are doable around the globe. Please __fill it out as soon as you can__ if you are interested in joining. The current approach is to look into the most popular slot to turn it into a cross-project discussion as well as booking the three most popular slots overall to cover the aforementioned topics. Please let me know if you have any questions. Thanks and Best Regards, Ildikó [1] http://lists.openstack.org/pipermail/edge-computing/2020-April/000699.html [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/ecg_virtual_ptg_planning_june_2020 [4] https://doodle.com/poll/gpd4hg6ambryi8c9

1 1

[all] Lower-constraints in some projects broken - update your repos
by Andreas Jaeger 20 Apr '20

20 Apr '20

Lower-constraints should test that the minimal requirements work together. The way we use the install-command in tox.ini, pip often ignores the constraints and install a newer package then requested. First Example: cloudkitty (see [1], [2] ,[3] , [4]) The repo has: install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master} {opts} {packages} and in lower-constraints.txt: "python-keystoneclient==1.9.0" And this runs the test with "keystoneclient==4.0.0" [1] Removing the install_command [3] or moving constraints from install_command into deps [2] gives "ERROR: Could not find a version that satisfies the requirement python-keystoneclient==1.9.0" So, this works as expected - but means this repo never tested what it expected to test. Second example: kolla-cli [5] Removing the install_command with constraints, suddenly lower-constraints fails with: "Could not find a version that satisfies the requirement mypy==0.6" Same problem as with cloudkitty. I fear that every repo that has constraints in its install_command has broken lower-constraints file. Just remove it and see that nothing works anymore ;/ Therefore, I suggest for repos to remove install_command - the default is just fine in newer tox (3.x) - and fix their lower-constraints.txt to really test that the specified package versions work together. Information about lower-constraints.txt is at [6], Andreas References: [1] https://review.opendev.org/720767 [2] https://review.opendev.org/720768 [3] https://review.opendev.org/720770 [4] https://review.opendev.org/720775 [5] https://review.opendev.org/#/c/720754/3 [6] https://docs.openstack.org/project-team-guide/dependency-management.html -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

6 22

[barbican] Question about container policy rule:container_acl_read
by Krzysztof Pawłowski 19 Apr '20

19 Apr '20

Hi, I have a question about policy for container consumers. Am I correctly understanding that the below policy in code should allow users with read acl to create consumer for container? policy.DocumentedRuleDefault( name='consumers:post', check_str='rule:admin or rule:container_non_private_read or ' + 'rule:container_project_creator or ' + 'rule:container_project_admin or rule:container_acl_read', scope_types=[], description='Creates a consumer.', operations=[ { 'path': '/v1/containers/{container-id}/consumers', 'method': 'POST' } ] ), policy.RuleDefault( name='container_acl_read', check_str="'read':%(target.container.read)s"), It's not working for me and I want to be sure if I'm doing something wrong or it's designed to work other ways. My current solution is below policy to allow role 'creator' to update consumers: {"consumers:post": "rule:admin or rule:creator or rule:container_non_private_read or rule:container_project_creator or rule:container_project_admin or rule:container_acl_read"} Greets, Krzysztof Pawłowski

1 0

[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

[tripleo] ptg meetings and time zones
by Wesley Hayutin 16 Apr '20

16 Apr '20

Greetings, Looking to see if there are strong preferences for our time slots for the PTG. I would suggest we try to shoot for 13-17 UTC slot [1] as much as possible. Any strong preference in not utilizing that time slot? Reminder.. topics topics topics Thanks all 0/ [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.opendev.org/p/tripleo-victoria-topics <https://etherpad.opendev.org/p/tripleo-victoria-topics>

3 2

[TripleO][Ironic] pxe boot remote host
by Ruslanas Gžibovskis 16 Apr '20

16 Apr '20

Hi all, Could someone help me, I do not get, I try to boot remote host (behind Firewall). I have dhcp-relay configured. And finally, I see the DHCP request, but nothing else happens... except me crying ;'( "D DHCP request captured on undercloud vnet5 where dhcp is listening also on eth1, But I am not able to load a remote host. I had a thought, maybe DHCP is generally not working, but one node which is local, I am able to introspect and provide it. completely nothing in /var/log/containers/ironic-inspector/dnsmasq.log Any suggestions? My network, which I used and have configured on undercloud host is: 10.120.191.80/28 and IP for DHCP which is configured as dhcp relay is 94. output from tcpdump: 21:19:00.058565 40:a6:77:4b:07:cb > 52:54:00:20:c1:dc, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 58, id 60458, offset 0, flags [none], proto UDP (17), length 576) 10.41.94.241.67 > 10.120.191.94.67: [udp sum ok] BOOTP/DHCP, Request from 24:6e:96:14:a1:a4, length 548, hops 1, xid 0x9614a1a4, secs 12, Flags [Broadcast] (0x8000) Gateway-IP 10.41.94.241 Client-Ethernet-Address 24:6e:96:14:a1:a4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 36: Subnet-Mask, Time-Zone, Default-Gateway, Time-Server IEN-Name-Server, Domain-Name-Server, RL, Hostname BS, Domain-Name, SS, RP EP, RSZ, TTL, BR YD, YS, NTP, Vendor-Option Requested-IP, Lease-Time, Server-ID, RN RB, Vendor-Class, TFTP, BF Option 128, Option 129, Option 130, Option 131 Option 132, Option 133, Option 134, Option 135 MSZ Option 57, length 2: 1260 GUID Option 97, length 17: 0.68.69.76.76.57.0.16.56.128.80.200.192.79.56.68.50 ARCH Option 93, length 2: 0 NDI Option 94, length 3: 1.2.1 Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001" -- Ruslanas Gžibovskis +370 6030 7030

2 4

[kolla][ptg] virtual PTG
by Mark Goddard 16 Apr '20

16 Apr '20

Hi, For Victoria we will again be having a virtual PTG, however this time due to "you know what" we will be holding it at the same time as the other teams. The PTG will take place from 1st - 5th June, with various slots [1] available throughout the day from which we can select. Looking at previous events [2][3], we had two four hour slots. For Train this was 12:00 - 16:00 UTC, and for Ussuri 14:00 - 18:00 UTC. Note that Train was during daylight savings, Ussuri was not. We also held a mid-Train planning session for Kayobe [4], which took two hours. Based on the above, I suggest we go with the same as Ussuri: Monday 1st: 14:00 - 18:00 UTC (kolla) Tuesday 2nd: 14:00 - 18:00 UTC (kolla) Wednesday 3rd: 14:00 - 16:00 UTC (kayobe) This is just a proposal - if you would like to attend these sessions and the above time slots do not work for you, please get in touch. In particular, please speak up if these slots are significantly out of your working day - with sufficient interest we could split sessions across timezones. [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.openstack.org/p/kolla-ussuri-ptg [3] https://etherpad.openstack.org/p/kolla-train-ptg [4] https://etherpad.opendev.org/p/kayobe-train-planning Cheers, Mark

2 4

[tc] [ironic] Promoting ironic to a top-level opendev project?
by Dmitry Tantsur 16 Apr '20

16 Apr '20

Hi everyone! This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion. TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. (And no, it’s not an April 1st joke) Background ========= Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it. And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team. Okay, so why? =========== The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it? Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here. Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above). What we will do ============ This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule. In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication). What we will NOT do ================ At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely. What do you think? =============== Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome. Cheers, Dmitry

24 93

OpenStack should be buildable with sphinx 2.4: FTBFS in many packages
by Thomas Goirand 16 Apr '20

16 Apr '20

Hi, Sphinx 2.4 has been uploaded to Experimental. I just received bug reports against the OpenStack packages because some of them cannot be built with Sphinx 2.4. Here's the list: - ironic - os-api-ref - aodh - cloudkitty - kombu - panko - ceilometerclient - ceilometermiddleware - doc8 - dracclient - glareclient - murano-pkg-check - os-xenapi - scciclient - sahara - sphinxcontrib-programoutput - tempest-horizon It'd be nice if those affected could be fixed for Ussuri. IMO, it's just the doc, so fixing it wouldn't hurt code quality. In other words: help would be more than welcome writing patch or reviewing them, and testing Sphinx 2.4 compatibility. Cheers, Thomas Goirand (zigo)

7 13