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 21 Apr '20

21 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 20 Apr '20

20 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 17 Apr '20

17 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

[neutron] port binding issues after upgrade attempt
by Jean-Philippe Méthot 16 Apr '20

16 Apr '20

Hi, We’ve been running a somewhat old version of openstack-queens for a while (I don’t know the exact release number, you will understand why shortly). Our setup has dedicated network nodes which we set up to use l3ha not too long ago. The package version was more recent on the second network node than on the first one because of that, however, high availability worked fine. We then tried to upgrade to rocky and since then, we get binding failed errors for pretty much all our ports whenever a router change network node. The only way we’ve found to fix this is to shutdown our neutron services and then reimport our pre-upgrade openstack database backup. This way, every port gets created properly, as it was at the time. Since then we have: -Moved everything back to queens. -Reinstalled our controller and network nodes from scratch (which is why I don’t know which queens version we were using before). However, this issue still happens as soon as the router change network node. Most ports get binding failed errors and restoring the database backup is the only way we managed to get out of this issue each time. We use neutron-openvswitch for networking and tunneling is done with GRE. Our OS is centos 7. Is it possible that code pertaining to HA may have changed in the later versions of queens and rocky which could explain that we’re running into a bug of some sort? Is there a way I could get neutron to tell me exactly why port binding is failing? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

1 0

[all][elections][tc] Technical Committee Election Results
by Kendall Nelson 15 Apr '20

15 Apr '20

Hello Everyone! Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). Graham Hayes (mugsie) Kristi Nikolla (knikolla) Mohammed Naser (mnaser) Belmiro Moreira (belmoreira) Rico Lin (ricolin) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_95cb11614fb23566 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round! -Kendall Nelson (diablo_rojo) & the Election Officials

9 8

[tripleo] undercloud installation failed at "waiting for container to start"
by Giuseppe Sannino 15 Apr '20

15 Apr '20

Hi all, need a (hopefully) small help from you. I'm trying to deploy Openstack on RHLE8 using TripleO. The "openstack undercloud install" fails at this stage: 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 5 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 623.63s 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 4 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 304.39s Images are fetched from the RedHat registry and pushed on the local registry: *>> containers-prepare-parameter.yaml* ContainerImageRegistryCredentials: registry.redhat.io: xxx:yyy ContainerImagePrepare: - push_destination: rhosp-under.ctlplane.localdomain:8787 *>> From "/var/log/tripleo-container-image-prepare.log"* I can see images are properly pushed into local registry: 2020-04-10 17:17:22,339 587093 INFO tripleo_common.image.image_uploader [ ] [registry.redhat.io/rhosp-rhel8/openstack-nova-compute-ironic:16.0-91] Completed upload for image 2020-04-10 17:17:22,341 586855 INFO tripleo_common.image.image_uploader [ ] result [] 2020-04-10 17:17:22,370 586855 INFO root [ ] ContainerClustercheckConfigImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 ContainerClustercheckImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 : : : ContainerZaqarImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 DockerInsecureRegistryAddress: - rhosp-under.ctlplane.localdomain:8787 >> From "install-undercloud.log" I can see a smooth procedure till it gets to the "TASK [Debug output for task: Start containers for step XX ]" phase. Specifically, at step 5 it ends unsuccesfully. *>> podman image list* Empty *>> podman ps* Empty >> openstack tripleo container image list [stack@rhosp-under ~]$ openstack tripleo container image list +--------------------------------------------------------------------------------------------------------+ | Image Name | +--------------------------------------------------------------------------------------------------------+ | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-heat-engine:16.0-91 | : : : | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-cron:16.0-96 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-keystone:16.0-93 | +--------------------------------------------------------------------------------------------------------+ Any suggestion would be more than welcome Many thanks in advance /Giuseppe

3 5

[neutron] Bug deputy report for week of April 6th
by Lajos Katona 15 Apr '20

15 Apr '20

Hi, I was Neutron bug deputy last week, please read a short summary of last week's reported Neutron bugs. What I would like to highlight: 1871032 <https://bugs.launchpad.net/neutron/+bug/1871032> and 1871239 <https://bugs.launchpad.net/neutron/+bug/1871239> are unassigned and 1871608 <https://bugs.launchpad.net/neutron/+bug/1871608> needs more investigation (at least from my side to what happens there). - Critical bugs - Rally job on stable branches is failing ( https://bugs.launchpad.net/neutron/+bug/1871596) In Progress - High priority bugs - Not Assigned: - OVN migration scripts doesn't work with SSL-only deployment ( https://bugs.launchpad.net/neutron/+bug/1871032) - ovn-octavia-provider is not using load balancing algorithm source-ip-port (https://bugs.launchpad.net/neutron/+bug/1871239) - In Progress - neutron.tests.functional.agent.ovn.metadata.test_metadata_agent.TestMetadataAgent.test_agent_registration_at_chassis_create_event fails randomly (https://bugs.launchpad.net/neutron/+bug/1871340) - OVN octavia provider driver should spawn long-living process in driver agent (https://bugs.launchpad.net/neutron/+bug/1871355) - fix Released - [VPNaaS]: DeprecationWarning: invalid escape sequence ( https://bugs.launchpad.net/neutron/+bug/1871621) - More investigation is necessary - OVN] Cannot create metadata port for segmented network ( https://bugs.launchpad.net/neutron/+bug/1871608) - Low priority bugs - [OVN] local conf devstack for a ovn-northd (DB only) node does not work (https://bugs.launchpad.net/neutron/+bug/1871730) - Whishlist - neutron ovn db clients need more logs if they fail to connect to db (https://bugs.launchpad.net/neutron/+bug/1871427) - Incomplete or solved in other projects - vm cannot be created after a large number of vms are removed from the same node (https://bugs.launchpad.net/neutron/+bug/1870723) - stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17" was solved in devstack ( https://bugs.launchpad.net/neutron/+bug/1871327) It was solved in devstack Best wishes Lajos (lajoskatona) ,-.,-. ( ( ( \ ) ) _..-.._ __)/ ,',' `. ," `. ,--. `. ," @ .' ` \ (Y ( ;''. `--.____, \ , ; ((_ ,----' ,---' _,'_,' (((_,- (((______,-' ------------------------------------------------ Thank you for visiting https://asciiart.website/ This ASCII pic can be found at https://asciiart.website/index.php?art=holiday/easter

2 4

[manila] Driver interface changes
by Carlos Silva 14 Apr '20

14 Apr '20

Greetings, zorillas! During the previous week we have merged a change in manila which improves the create share from snapshot functionality [1] to allow a multi-stage share creation. This means that a share creation request at the share manager can be acknowledged by the share driver to be pending; and the share manager will call a different driver interface to gather the status of this share, periodically until it is created. The primary benefit of this change is for drivers that cannot clone their snapshots instantaneously into new shares, and for drivers that would like to implement snapshot cloning across different storage pools or back ends. To make these changes, we needed to change the driver interface. All in-tree drivers were already modified and are up to date with the changes in the interface. The out-of-tree drivers will need to be updated as well according to the changes in the interface, then they will be able to work properly. [1] https://review.opendev.org/#/c/709697/ Regards, Carlos Eduardo da Silva.

1 0

[oslo] Ussuri stable branches created
by Ben Nemec 14 Apr '20

14 Apr '20

This has two major implications: 1) Master is no longer feature frozen 2) Any future Ussuri bug fixes will need to be backported Because of 2 and in spite of 1, please try to avoid merging any highly invasive changes to master between now and the Ussuri coordinated release. If we end up needing a last-minute bug fix we don't want to have to disentangle it from a huge refactoring effort (or whatever) in order to backport. Thanks. -Ben

1 0

[all][elections][tc] TC Voting Last Days
by Kendall Nelson 14 Apr '20

14 Apr '20

We are coming down to the last hours for voting in the TC election. Voting ends Apr 14, 2020 23:45 UTC. Search your gerrit preferred email address[0] for the following subject: Poll: OpenStack 'Victoria' TC Election (yes, the CIVS system had problems with escaped characters) That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/#victoria-tc-candidates What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[1] and email the election officials[2]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/raw/tag/0.5.0/reference/projects.y… [2] https://governance.openstack.org/election/#election-officials

1 0

[tc][all][SDK][API] Multi-region/edge OpenStack deployment
by Marie Delavergne 14 Apr '20

14 Apr '20

Hi, Following the previous discussions regarding approaches to make several instances of OpenStack collaborative[1], we finally decided to make a research report on the approach we initially proposed during the edge hackathon in Berlin (OSF summit 2018). The document is a short article (~10 pages long)[2] that gives a rather complete overview of the approach. If you are interested to see how mutliple instances of distinct OpenStack can give the illusion of a single system you might be interested to give it a look. A brief excerpt: “We propose a novel approach that delivers any collaboration between services of distinct OpenStack once and for all. Our approach eliminates development efforts related to the brokering aspect by leveraging dynamic composition and a Domain Specific Language (DSL). Using these two mechanisms, Admins/DevOps can specify, on a per-request basis, which services from which OpenStacks are required for the collaboration. This information is then interpreted to dynamical recompose services between the different OpenStacks, enabling the execution of single-, cross- or multiple-site requests without code effort.” The main idea is, considering several OpenStacks running, to use a DSL to specify which instance of the service (i.e. on which Openstack) the user wants its request to be executed. For instance, to provision a VM on a Nova in Paris using an image from a Glance in New York. You may contact the API either in NewYork or in Paris and perform the following request: "openstack server create --image debian --scope { compute: Paris, image: New York }" Along with the report comes a proof of concept available on GitLab[3]. Feel free to get back to us. Cheers [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013562.ht… [2] https://hal.inria.fr/hal-02527366/ [3] https://gitlab.inria.fr/discovery/openstackoid ---- Marie Delavergne

2 2

[cinder] datera ibm-gpfs macrosan sandstone - upcoming deadlines
by Brian Rosmaita 14 Apr '20

14 Apr '20

This is a reminder that the drivers listed in the subject have ussuri blueprints containing some open items. datera: https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration - needs: update support matrix, update docs if necessary, release note ibm-gpfs: https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported - have declared intent to restore CI and mark driver supported, but no patches yet macrosan: https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - support patch mixed in with features, so must be merged by noon UTC on Friday 17 April - patch requires revision - at this point, should probably make sure the CI is running reliably and split the patch into (a) mark the driver supported in ussuri, and (b) the new features (which will be held for victoria) sandstone: https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver - needs: update support matrix, documentation page, release note Please address these issues immediately; all patches should be merged before RC-1 (23 April). Tracking this on: https://etherpad.opendev.org/p/cinder-ussuri-driverstuff

1 0

[tripleo] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 14 Apr '20

14 Apr '20

# resending with the correct tag. sorry for the noise. Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

2 2

[nova]-Pci device pass-through error.
by zhangcf9988＠aliyun.com 14 Apr '20

14 Apr '20

Hello, contributors to the Openstack community: I've got a problem and I'd love to get some advice. When we used the openstack-pike version, we encountered the following problems: Deployment environment: The openstack-pike version of openstack was installed on CentOS7.7.1908 system using yum, where nova version was 9.1.3 Nova - compute node: The Dell R730 server was used, and three graphics CARDS of the same model Nvidia 1050 Ti were installed. At the same time, the iommu was enabled and the graphics card pass-through was configured. But we had a problem: Two PCI expansion board CARDS were installed on Dell R730, two Nvidia 1050 Ti graphics CARDS were installed on the first PCI expansion board card, and one was installed on the second PCI expansion board card. As an Nvidia 1050 Ti graphics card is composed of two chips, respectively: Video card chip (Proudct_id:1c82, Vendor_id:10de) Sound card chip (Proudct_id:0fb9, Vendor_id:10de) Create a VM, we hope that the VM can passthrough for graphics and sound card chip at the same time, but we test found that VM will get 2 graphics or sound card chip, rather than a complete physical graphics should be some graphics and sound card chip, consequences of this, we installed the three pieces of graphics card, no one can be normal use, because the first VM occupies two graphics chips, lead to the second created, VM libvirtd detected a VM occupies physical graphics graphics chips, cause the failure of the second always create a VM. At the same time, I also tested that when I removed one of the two Nvidia graphics CARDS on the first PCI expansion board card and installed a physical Nvidia graphics card on the first and second PCI expansion board CARDS, the test created a VM that could obtain a video card and a sound card chip at the same time, so that the VM successfully obtained a complete Nivida physical graphics card. We hope that we can insert pieces of the same type of graphics card, but now we tried by modifying the nova pci_devices table in the database, the first VM can be modified by the graphics card is assigned the wrong question, but in fact, the second VM still complains when created, and will also we manually modify the database information to clean up, at present there are two possible solutions, the first is to modify the source code, the second is using different types of graphics CARDS, don't know the problem, can be solved by modifying the source code. Thank you very much. The following is the configuration of nova on the control node: [DEFAULT] enabled_apis = osapi_compute,metadata my_ip = 172.16.160.206 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver transport_url = rabbit://openstack:mqpass123@baseserver available_filters=nova.scheduler.filters.all_filters available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter enabled_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:novapass123@baseserver/nova_api [cinder] os_region_name = RegionOne [database] connection = mysql+pymysql://nova:novapass123@baseserver/nova [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://controller:9292 [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [neutron] url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 service_metadata_proxy = true metadata_proxy_shared_secret = 20190909 [oslo_concurrency] lock_path=/var/lib/nova/tmp [pci] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI" } alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI" } [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [vnc] enabled = true vncserver_listen = $my_ip vncserver_proxyclient_address = $my_ip #The following is the configuration for nova-compute: /etc/nova/nova.conf: [DEFAULT] enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:mqpass123@baseserver my_ip = 172.16.160.204 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver instance_name_template = instance-%(uuid)s remove_unused_base_images=false [api] auth_strategy = keystone [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [vnc] enabled = True #vncserver_listen = 0.0.0.0 #vncserver_proxyclient_address = $my_ip vncserver_listen = 172.16.160.204 vncserver_proxyclient_address = 172.16.160.204 novncproxy_base_url = http://172.16.160.206:6080/vnc_auto.html keymap=en-us [glance] api_servers = http://controller:9292 [oslo_concurrency] lock_path = /var/lib/nova/tmp [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [libvirt] virt_type = kvm #virt_type = qemu use_usb_tablet=true [filter_scheduler] enabled_filters = RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateCoreFilter,AggregateDiskFilter,DifferentHostFilter,SameHostFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [PCI] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1c82" }, {"vendor_id": "10de", "product_id": "0fb9"}] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI"} alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI"} [neutron] metadata_proxy_shared_secret = 20190909 service_metadata_proxy = true url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 flavor: openstack flavor create --public --ram 10240 --disk 50 --vcpus 4 nvidia1050ti --id 1 \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' image: openstack image create win10base1903UEFI --file win10base1903Q35V1.qcow2 --container-format bare --disk-format qcow2 --public \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' #The following is an error reported in openstack-nova -compute: 2020-03-31 10:57:04.555 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.723 2643 ERROR nova.virt.libvirt.guest [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Error launching a defined domain with XML: <domain type='kvm'> <name>instance-7e5d283f-5ed5-4ebe-b145-d348e94addca</name> <uuid>7e5d283f-5ed5-4ebe-b145-d348e94addca</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="16.1.7-1.el7"/> <nova:name>test1</nova:name> <nova:creationTime>2020-03-31 02:57:04</nova:creationTime> <nova:flavor name="nvidia1050ti_50G"> <nova:memory>10240</nova:memory> <nova:disk>50</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>4</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="68711849a60849d7807d71968ba6b275">demo</nova:user> <nova:project uuid="fa79259f6d2a442c86d4cd5e0e6c788c">demo</nova:project> </nova:owner> <nova:root type="image" uuid="24bb256e-9cea-4dcd-96e0-e6bd81156052"/> </nova:instance> </metadata> <memory unit='KiB'>10485760</memory> <currentMemory unit='KiB'>10485760</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>4096</shares> </cputune> <sysinfo type='smbios'> <system> <entry name='manufacturer'>RDO</entry> <entry name='product'>OpenStack Compute</entry> <entry name='version'>16.1.7-1.el7</entry> <entry name='serial'>30535dfb-90e3-401e-bbf7-f2c43120fb65</entry> <entry name='uuid'>7e5d283f-5ed5-4ebe-b145-d348e94addca</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/instance-7e5d283f-5ed5-4ebe-b145-d348e94addca_VARS.fd</nvram> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='123456789ab'/> </hyperv> <kvm> <hidden state='on'/> </kvm> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='localtime'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> <timer name='hypervclock' present='yes'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </disk> <controller type='usb' index='0' model='qemu-xhci'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x15'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x16'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <interface type='bridge'> <mac address='fa:16:3e:51:25:34'/> <source bridge='brq8d505aa1-51'/> <target dev='tap1a673f99-8a'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='172.16.160.204' keymap='en-us'> <listen type='address' address='172.16.160.204'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <memballoon model='virtio'> <stats period='10'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </memballoon> </devices> </domain> : libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.724 2643 ERROR nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Failed to start libvirt guest: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.726 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.741 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deleting instance files /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del 2020-03-31 10:57:04.743 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance failed to spawn: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Traceback (most recent call last): 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2203, in _build_resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] yield resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2018, in _build_and_run_instance 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] block_device_info=block_device_info) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2903, in spawn 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure=True) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5453, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5423, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] post_xml_callback=post_xml_callback) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5341, in _create_domain 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] guest.launch(pause=pause) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 144, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self._encoded_xml, errors='ignore') 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 139, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] return self._domain.createWithFlags(flags) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] result = proxy_call(self._autowrap, f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = execute(f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(c, e, tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = meth(*args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1110, in createWithFlags 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] 2020-03-31 10:57:04.887 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Terminating instance 2020-03-31 10:57:04.896 2643 INFO nova.virt.libvirt.driver [-] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance destroyed successfully. 2020-03-31 10:57:04.898 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.939 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:05.025 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.13 seconds to destroy the instance on the hypervisor. 2020-03-31 10:57:05.869 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.62 seconds to deallocate network for instance. 2020-03-31 10:57:12.019 2643 INFO nova.compute.resource_tracker [req-5a0cf06d-ee8e-4839-a5a5-ee5269299d20 - - - - -] Final resource view: name=dellserver phys_ram=261922MB used_ram=10752MB phys_disk=399GB used_disk=50GB total_vcpus=48 used_vcpus=4 pci_stats=[PciDevicePool(count=0,numa_node=0,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=2,numa_node=0,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de')] zhangcf9988(a)aliyun.com

2 1

[project] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 14 Apr '20

14 Apr '20

Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

1 0

[tacker][neutron] Need help in setting up QOS for Neutron Service in Devstack CI Job
by Patil, Tushar 14 Apr '20

14 Apr '20

Hi OpenStackers, In tacker project, we need to setup QOS plugin in devstack CI job (tacker-functional-devstack-multinode-python3) to run our functional tests. I have checked what config options are needed to enable QOS in neutron and updated .zuul.yaml accordingly as you can see in patch [1] PS 18. Mainly, I have enabled following environment variables in .zuul.yaml:- Q_SERVICE_PLUGIN_CLASSES: router,neutron.services.metering.metering_plugin.MeteringPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,neutron.services.qos.qos_plugin.QoSPlugin, Q_ML2_PLUGIN_EXT_DRIVERS: port_security,qos L2_AGENT_EXTENSIONS: qos NEUTRON_PORT_SECURITY: False Problem: Main point is service_plugins config option is configured with qos but the [ml2].extension drivers doesn't include qos. I hav set qos" in Q_ML2_PLUGIN_EXT_DRIVERS but still it's not set in the /etc/neutron/plugins/ml2/ml2_conf.ini in Section [ml2].extension_drivers on the controller node and because of this reason the q-svc service is not starting on the controller node. I have scoured devstack.log to find out where it's overwriting extension_drivers with "port_security" instead of "port_security, qos" but I couldn't find one. On the controller node, we can see this log statement:- 2020-04-10 13:07:23.388678 | controller | + lib/neutron_plugins/ml2:populate_ml2_config:59 : iniset /etc/neutron/plugins/ml2/ml2_conf.ini ml2 extension_drivers port_security,qos It's clear from above log, qos is set properly but where exactly it's overwritten with just port_security or qos is removed is not clear to me. Any pointers where I can debug to solve this problem or how to set QOS correctly? [1]: https://review.opendev.org/#/c/717530/18 Regards, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 3

Re: [Release-job-failures] Release of openstack/puppet-aodh for ref refs/tags/16.2.0 failed
by Emilien Macchi 13 Apr '20

13 Apr '20

We have identified the issue and will propose patches today and it'll fix the release jobs. On Mon, Apr 13, 2020 at 8:56 AM <zuul(a)openstack.org> wrote: > Build failed. > > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/816a2104b2c94b199eaab1288b64f1c7 > : POST_FAILURE in 2m 57s > - announce-release https://zuul.opendev.org/t/openstack/build/None : > SKIPPED > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 3

[cinder] feature freeze and FFEs
by Brian Rosmaita 13 Apr '20

13 Apr '20

I wasn't paying close enough attention to the "real life" calendar, and did not realize that we would be so short-handed on reviewers around the Feature Freeze, with a lot of people unavailable. So, I am granting Feature Freeze Exceptions to the following. To make it into Ussuri, these should be merged by noon UTC on Friday 17 April. https://blueprints.launchpad.net/cinder/+spec/sf-aa-support - looks good, but I really want to allow time for one of our A/A HA experts to take a final look https://blueprints.launchpad.net/cinder/+spec/copy-image-in-multiple-stores - this may need a minor revision, but otherwise looks OK https://blueprints.launchpad.net/cinder/+spec/nfs-volume-encryption - some questions have come up about testing this one. We should decide by mid-week whether it still looks good for Ussuri or not. https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - this patch includes adding support for some new functionality and hence is subject to the feature freeze; needs a minor revision and release note; third-party CI appears functional. Problems need to be addressed very early next week, or this may wind up slipping to Victoria. The following blueprint contains multiple patches that have all been approved. Two haven't been able to merge; they require a rebase and conflict resolution. I expect that they will all merge early next week, but technically they require an FFE (which is granted). https://blueprints.launchpad.net/cinder/+spec/unity-ussuri-features The following blueprints are not yet marked 'Implemented', but the outstanding work is not subject to the feature freeze (mostly verification of stable third-party CI and then marking drivers as 'supported' or 'unsupported', which by Cinder policy must be done by RC-1). I just want to mention them so no one freaks out about not having an FFE. (You don't need one.) https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver https://blueprints.launchpad.net/cinder/+spec/cinder-nimble-driver https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported https://blueprints.launchpad.net/cinder/+spec/restore-unsupported-drivers If I missed anything, please apply for a FFE by the usual method, that is, an email with the subject '[cinder] FFE request' before 18:00 UTC on Tuesday 14 April.

1 1

[requirements][glance]FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glanceclient 3.1.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.1.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

2 1

[Glance] FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glancecient 3.0.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.0.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

1 0

[TripleO] Train cannot finish introspection due to ironic-agent fails
by Ruslanas Gžibovskis 13 Apr '20

13 Apr '20

Hi all, I have python-ironic-agent failing using standard template files. Reproducible with CentOS7 + repos: * base: mirror.hh.se * centos-ceph-nautilus: mirror.hh.se * centos-nfs-ganesha28: mirror.hh.se * centos-openstack-train: mirror.hh.se * centos-qemu-ev: mirror.hh.se * epel: mirrors.glesys.net * extras: mirror.hh.se * updates: mirror.hh.se getting an error while loading provisioning, attached in the image attached. Text is: [ 317.948425] system[1]: Starting Ironic Python Agent. ... python trace ... SyntaxError: Non-ASCII character '\xe2' in file /usr/lib64/python2.7/site-packages/psutil/__init__.py on line 997, but no encoding declared: see http://www.python.org/peps/pep-0263.html for details any suggestions except running it on c8? Should i consider: remove epel repo? I have it added when creating images... install python3? from which repos? install some additional package? Thank you -- Ruslanas Gžibovskis +370 6030 7030

2 1

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

13 Apr '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-6 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * This is very close to mark as complete. * We merged many of charm repo patches and few more projects. * Few ansible repo failing on centos7 and waiting for migration on centos8 * I tried to reach out to team for pending patches. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Pending Tempest plugins: ** cyborg-tempest-plugin: https://review.opendev.org/#/c/704076/ ** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ * 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 ** python-tripleoclient: https://review.opendev.org/#/c/703344 * Few more repo patches need to merge: ** masakari-specs: https://review.opendev.org/#/c/698982/ ** cyborg-specs: https://review.opendev.org/#/c/698824/ ** nova-powervm: https://review.opendev.org/#/c/700683/ ** paunch: https://review.opendev.org/#/c/703344/ * Started pushing the required updates on deployment projects. ** Completed or no updates required: *** Openstack-Chef - not required *** Packaging-Rpm - Done *** Puppet Openstack- Done *** Tripleo - except python client, all is done. ** 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) * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work which is not started yet. I will start the audit in parallel to finishing the pending things listed above. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

3 4

[doc][release][requirements] Issues with wsmeext.sphinxext
by Pierre Riteau 13 Apr '20

13 Apr '20

Hello, A heads up for other projects using wsmeext.sphinxext: it seems to be broken following the release of Sphinx 3.0.0 yesterday. Our openstack-tox-docs job in blazar started to fail with: Extension error: Could not import extension wsmeext.sphinxext (exception: cannot import name 'l_' from 'sphinx.locale' Looks like it would affect aodh and cloudkitty too. Pierre Riteau (priteau)

6 6

[FFE][requirements][castellan] Critical bug found in Castellan 3.0.0
by Douglas Mendizabal 13 Apr '20

13 Apr '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I would like to request a Feature Freeze Exception for Requirements to remove Castellan 3.0.0 and use the soon-to-be-released 3.0.1 build. The Barbican team found a critical bug in the Castellan 3.0.0 release [1] that is currently breaking our gates. The Oslo team will be making a new 3.0.1 release as soon as the bugfix patch merges. [2] Thanks, Douglas Mendizábal Barbican PTL [1] https://bugs.launchpad.net/castellan/+bug/1872480 [2] https://review.opendev.org/#/c/718775 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwcapj5oGTj2zd3XogB6WFOq/OrcFAl6UhEgACgkQgB6WFOq/ Orfl1g/+Ll6Zw2LB6pQeDBdx/YLYcfyYZWol14Ye45wELMArUSwxwsI/Ekwdmtgo VfMgP8tg+OxiD6/I2Wx2S+a4Cys8/SiXCO7hMwUSoGDdthI2lB8ICUgPqaiUvrbe nKH7IW0niVKQW9ISBw2w5TrAaCf4vg1e8KDBDQE91d8wng3Sv/DPZsVFEcU+bixE ayr7LKlNrCpeSzHIZE1YOqAYGyL7NtvruzPdC52yz1lE/iNbJSQQpLjXTcr/E7gl KzBTj04VclFRz/ESS1/VaLHfnHjEW0UmeM7xmr5H/mncJgLF8lQttifVjHZ+cvsp QziIp87IOIeWGh7PYUAKwqWeh+WKYLghGrzsLc6LlHy+QRx5kUqlv/6XbPkXfsDh RmaOoCB3PkP0pStmbMNwfU6k9VWsa4K13ejOrDNZQfyHfcrzRfVFojcW7c+jRHZr R3Um4DP3LyozYA1c4U2WrHv5B+xO+e64LylNCt+mLQ+hoVUacrglA2PgMtak7pwe 5gJJTTLtJUXlwyoe2+iM4wu8JgKXOY3MuMh8R+e60/8U1IeAB2Meew6ec51qaNQ4 j9KCL3nopjpA/aJH1qCRjLqf2AslXFQ9XVtO9DmJ3MchDrqyVIKGDQk354AEUYvE o2zC1FVNNjmpsiam9QpNak+1D0IwxWXZBONjLD5K5R8cDBJMVBM= =6WW/ -----END PGP SIGNATURE-----

3 3

RE: [baremetal-sig][ironic] Baremetal whitepaper round 2: doodle
by Arne Wiebalck 13 Apr '20

13 Apr '20

Dear all, It seems that Wed April 15 at 2pm UTC (4pm CEST) seems to be the most convenient time. I've set up a video call here: https://cern.zoom.us/j/95696673823 Everyone is still welcome to join! As a reminder, the white paper is available from here: https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsf… See you there! Arne -----Original message----- > From: Arne Wiebalck <Arne.Wiebalck(a)cern.ch> > Sent: Tuesday, April 7, 2020 10:14 AM > To: openstack-discuss(a)lists.openstack.org > Subject: [baremetal-sig][ironic] Baremetal whitepaper round 2: doodle > > Dear all, > > After the first very productive sessions on finishing the baremetal > whitepaper (thanks to everyone contributing and reviewing afterwards!), > we would like to keep the momentum and schedule a second round. > > I've set up a doodle here [0], and we will send out the call details > once we have settled on the time slot(s). > > If you'd like to participate, please make sure you reply to the doodle > before the end of this week. > > Thanks! > Arne > > [0] https://doodle.com/poll/kyd5vvgmg68vxduv > > > > >

1 0

[cinder][ops][extended-maintenance-sig][public-cloud-sig][enterprise-wg] Cinder to EOL some branches
by Brian Rosmaita 13 Apr '20

13 Apr '20

This is a courtesy notice that having received no responses to my email of 28 October [0] proposing to EOL some currently open Cinder branches, and following the policy articulated in [1], at today's Virtual PTG meeting the Cinder project team has decided to put the following stable branches into the End of Life state: driverfixes/mitaka driverfixes/newton stable/ocata stable/pike I will submit the paperwork to get this process moving one week from today (2 December 2019). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

4 8

[neutron] Team meeting on Monday 13.04.2020 cancelled
by Slawek Kaplonski 12 Apr '20

12 Apr '20

Hi, Tomorrow is Easter Monday, I have holiday and will not be available to run our team meeting. So lets cancel it this time. See You all on next meeting which will be on Tuesday 21.04.2020. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[election][tacker][ptl] Announcing my PTL candidacy for Tacker (Yasufumi Ogawa)
by Yasufumi Ogawa 10 Apr '20

10 Apr '20

Hi all, I would like to nominate myself to be Tacker PTL for Victoria cycle. Our project is still active and going to implement requirements from telcom standardization and industries. I feel ready to do that. Thanks a lot. Regards, Yasufumi Ogawa

2 2

[octavia] dropping support for stable/queens
by Adam Harwell 10 Apr '20

10 Apr '20

I'm officially proposing dropping support for the queens stable branch of Octavia. Given a quorum of cores, we will move forward with marking it EOL and all that entails. Thanks, --Adam

5 5

[all][PTL][TC] U Community Goal: Project PTL & Contrib Docs Update #6
by Kendall Nelson 10 Apr '20

10 Apr '20

Hello Everyone! While we may be past feature freeze there is still time to complete this goal given that it is documentation focused. I urge those that have not started to do so immediately. If you need help, please let me know ASAP. For those projects that have not started yet, I would start with filling in the template[2] and then go take a look at what the others have done for more inspiration[1]. If you have any questions, please let me know or refer to the goal[3]. Once you get started, please make sure to keep the story up to date[4]. I look forward to reviewing your patches!! If there is anything I can do to help, please let me know. And also, I want to give a HUGE thank you to those that have already started/completed the goal! Nice work :) -Kendall (diablo_rojo) [1] Progress: https://review.opendev.org/#/q/topic:project-ptl-and-contrib-docs+(status:o… [2] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Accepted Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [4] Task Tracking: https://storyboard.openstack.org/#!/story/2007236

1 0

[release] Release countdown for week R-4, April 13 - 17
by Sean McGinnis 10 Apr '20

10 Apr '20

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the ussuri deliverables can be proposed, well ahead of the final ussuri release date. General Information ------------------- We are still finishing up processing a few release requests, but the ussuri release requirements are now frozen. If new library releases are needed to fix release-critical bugs in ussuri, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in ussuri that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By April 23 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/ussuri branches should be created soon for all not-already-branched libraries. You should expect 3-4 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), a tox.ini constraints URL update, and a patch updating any cycle-specific job templates to the victoria version. Please review those in priority so that the branch can be functional ASAP. Note that the victoria job templates may not be quite ready yet, so the patch may initially fail. A simple recheck once they are in place should allow the patch to pass. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for ussuri changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed ussuri cycle-highlights yet, you are already late to the party. Please see http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013823.ht… for details. Upcoming Deadlines & Dates -------------------------- RC1 deadline: April 23 (R-3 week) Final RC deadline: May 7 (R-1 week) Final Ussuri release: May 13

1 0

[release][nova] FFE request for Nova Policy Defaults Refresh BP
by Ghanshyam Mann 10 Apr '20

10 Apr '20

Hello Everyone, I would like to ask the FFE for policy default refresh BP[1]. Most of the work is merged for this[2] but not 100%. Few policies not yet merged (~7) and 3 policies code is not yet up which I am working on. With that, I need more time to finish this work and require the FFE. [1] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh [2] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… -gmann

3 3

[election][tacker][ptl] Announcing my PTL candidacy for Tacker (Hyunsik Yang)
by hyunsikYang 10 Apr '20

10 Apr '20

Hello all Tacker members! I am Hyunsik Yang from the IISTRC(Internet Infra System Technology Research Center), South Korea. I wish to nominate myself for consideration as a Tacker Project PTL for the Victoria Cycle. I've previously contributed code, bug fixes and several reviews for Tacker from the Queens cycle. My goal is to improve the Tacker project by making it more standardized and precise. If you have any questions, please feel free to ask me. Thank you. Best regards, Hyunsik Yang *----------------------------------------------------------------* *Hyunsik Yang (Ph. D candidate)* *DCN laboratory / School of Electronic Engineering* *Soongsil University * *511 Sangdo-dong Dongjak-gu* *Seoul, 156-743 Korea* *TEL : (+82)-2-820-0841 * *M.P: (+82)-10-9005-7439*

2 2

[all][ideas][releases] Introducing Project Stopwatch: Another proposal to change the release cycles
by Jean-Philippe Evrard 10 Apr '20

10 Apr '20

Hello, I would like us to discuss how our release cycles are defined. We've been discussing in the past about longer or shorter cycles. This is only recorded in the mailing lists, which are hard to search. We should try to record conversations in this new "ideas" framework if we can. I think it's time to record something about the release cycles in our ideas. However, before I start the 2020 version of the eternal war "longer cycles" vs "shorter cycles", I would like us to discuss about something a little bit different, that you can find in review [1]: project Stopwatch. I have discussed with a few of you already about Stopwatch and how we could do cycles differently. This is to write the idea down. For me, it's time to change the cycles, by introducing more time to cool down. To make this happen, I need your opinions, as it quite an impactful change for the whole OpenStack. Regards, Jean-Philippe Evrard [1]: https://review.opendev.org/#/c/718929/

1 0

Etherpad and Gerrit maintenance on 2020-04-10
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Tomorrow, April 10, 2020, the OpenDev team will be performing minor updates to two services. * Gerrit restart for https://review.opendev.org/ at 16:00 UTC. This should be a momentary outage to restart the service in a container. We will maintain the same version in the same configuration; this is a preparatory step in order to perform future version upgrades more easily. Other than a short outage of about a minute, there should be no service impact or visible changes, but since the environment is changing, we wanted to announce this in case any problems are detected. * Etherpad migration and domain change at 17:00 UTC. We will migrate the data currently hosted on etherpad.openstack.org to a new server, also running in a container, on etherpad.opendev.org. We will set up redirects so that on completion of the migration, all etherpad.openstack.org URLs will redirect to the same pages on etherpad.opendev.org. https://etherpad.opendev.org/ will become the new canonical service URL. This also includes an upgrade to the latest release of Etherpad Lite (1.8.0). This involves a database migration as well. The service will be unavailable for the duration of this migration (expected to be about 30 minutes). Please report any issues in #opendev on Freenode or to the service-discuss(a)lists.opendev.org mailing list. Note that this message is being sent to service-announce and several other lists. Future announcements of this type will only be sent to service-announce, so please sign up[1] for that list if you haven't already. [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce -Jim

1 0

[release][oslo] FFE request for Oslo Policy
by Ghanshyam Mann 09 Apr '20

09 Apr '20

Hi, This is regarding the FFE request for policy for - https://review.opendev.org/#/c/717879/ This is part of introducing scope_type and new defaults in policies. During Nova implemtnation[1], we came across two things to solve before we release the new policies changes: 1. A lot of warnings as policy default are changing which end up filling the logs (226 MB n-api logs today). 2. Give operators an option to switch to the new system (scope and new defaults) at the same time without overwriting the policy file. We discussed those two things to solve via oslo_policy[2] which need FFE approval. Sorry for being late on this which should be planned early. Please let me know if it is ok to include these changes in the Ussuri release. [1] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… -gmann

4 5

[kolla] Kolla Klub first meeting tomorrow
by Mark Goddard 09 Apr '20

09 Apr '20

Hi Kollaborators, Just a reminder that we will meet tomorrow at 15:00 UTC. Join here: https://meet.google.com/hph-pynx-vsy I have created a Google doc for the meeting agenda and notes: https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_…. See you tomorrow, Mark

1 1

[neutron] Drivers meeting - 10.04.2020
by Slawek Kaplonski 09 Apr '20

09 Apr '20

Hi, I will be on PTO on Good Friday so lets cancel our drivers meeting at that day. See You all on drivers meeting next week. And have a great holidays :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[tc][election] Simple question for the TC candidates
by Jean-Philippe Evrard 09 Apr '20

09 Apr '20

Hello, I read your nominations, and as usual I will ask what do you _technically_ will do during your mandate, what do you _actively_ want to change in OpenStack? This can be a change in governance, in the projects, in the current structure... it can be really anything. I am just hoping to see practical OpenStack-wide changes here. It doesn't need to be a fully refined idea, but something that can be worked upon. Thanks for your time. Regards, Jean-Philippe Evrard

12 26

[manila][release] Ussuri release preparation
by Goutham Pacha Ravi 09 Apr '20

09 Apr '20

Hi Stackers, (Following gibi's lead here on relaying release status to the ML) We're at feature freeze, and I'm providing the current state of Ussuri release deliverables from the manila team: openstack/python-manilaclient is waiting on a couple of changes: - Release patch: https://review.opendev.org/#/c/718254/ - Pending changes: bp/create-share-from-snapshot-in-another-pool-or-backend: - https://review.opendev.org/#/c/712543/ bp/graduate-share-groups-feature - https://review.opendev.org/#/c/708282/ openstack/manila-ui has a few open bug-fixes, we'll target a release in the next week or so: - https://review.opendev.org/#/q/topic:bug/1823078 openstack/manila has the following pending changes concerning Feature Freeze - bp/create-share-from-snapshot-in-another-pool-or-backend: - https://review.opendev.org/#/c/709697/ (Manila server side changes) - https://review.opendev.org/#/c/711611/ (ZFSOnLinux implementation) - https://review.opendev.org/#/c/712642/ (NetApp driver implementation) - bp/graduate-share-groups-feature - https://review.opendev.org/#/c/706959/ Ussuri Release goals status: - Drop Python 2.7 Support - Complete - Project Specific PTL and Contributor Documentation - In-Progress Thanks, Goutham

1 0

[StoryBoard][Security] The process to report a security bug
by Lingxian Kong 09 Apr '20

09 Apr '20

As most of the projects have migrated to storyboard for bug tracking, after reading https://security.openstack.org/vmt-process.html, I have two questions: 1. I didn't find openstack/ossa or ossa project exists in storyboard. 2. I didn't find a place in storyboard to attach a patch. Am I missing something? - Best regards, Lingxian Kong Catalyst Cloud

2 3

[all] Please remove all external resources from docs
by Thomas Goirand 09 Apr '20

09 Apr '20

Hi, I've wrote about this earlier I guess, but I believe I need to do it once more. Often I see in the docs things like this: .. image:: https://governance.openstack.org/tc/badges/<FOO>.svg :target: https://governance.openstack.org/tc/reference/tags/index.html [note: this is only one simple example, there's many of other types linking to external images, I've even seen stuff linking to CDNs...] I'd like to see these go away. Indeed, distributions like mine (ie: Debian) are packaging the doc. And it's *very* annoying when one browses the doc to have such an external link, and the browser going on the internet to fetch an external resource. So, in Debian, I'm patching these away. Often, the most ugly way where I don't care about the resulting document (as long as the doc is there). This is both annoying, and a loss of my time. The solution is simple: have the resource being *LOCAL* (ie: stored in the project's doc), not stored on an external site. Thanks to anyone who will follow this advice. Cheers, Thomas Goirand (zigo)

7 9

[nova] Ussuri release preparation
by Balázs Gibizer 09 Apr '20

09 Apr '20

Hi, Today is Feature Freeze for Ussuri and the final release of novaclient for Ussuri. Release TODOs are tracked in [1]. Any feature code in nova that is approved before end of today is OK to be rechecked or rebased if needed after the freeze. Features that are close to land but haven't approved until the freeze, needs a Feature Freeze Exception on the ML or they will be postponed to the Victoria cycle. When you request such FFE please try to find cores who support your request. Bug fixes, test coverage and documentation enhancements are still OK to be proposed after the freeze. However please be careful approving risky patches. Any release blocker issue should have a bug tagged with ussuri-rc-potential in launchpad. Please also add them the the etherpad [1] Cheers, gibi [1] https://etherpad.openstack.org/p/nova-ussuri-rc-potential

1 0

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 08 Apr '20

08 Apr '20

On 4/8/20 4:53 PM, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/28b78b5235894878b4cb92822b95bbff : FAILURE in 5m 53s > - publish-tox-docs-releases https://zuul.opendev.org/t/openstack/build/None : SKIPPED This failure was due to a new operation we added to the branching process. Once working, the new code will propose patches to branched repos to update them to use the job template defined for the next release cycle, similar to how the patches are proposed to update reno. I think this was due to an error in a sed command that is used to perform that update, and will hopefully be fixed after https://review.opendev.org/718564 merges. No further action is needed here. The only thing missed was the publishing of the releases docs, but that will be corrected with the next release patch that goes through. Sean

1 0

[all][PTL][release] Call for Ussuri Cycle Highlights
by Kendall Nelson 08 Apr '20

08 Apr '20

Hello Everyone! Its time to start thinking about calling out 'cycle-highlights' in your deliverables! As PTLs, you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it makes them easy to reference because they get compiled into a pretty website like this from the last few releases: Rocky[1], Stein[2], Train[3]. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. Looking through your release notes might be a good place to start. *The deadline for cycle highlights is the end of the R-5 week [4] on April 10th.* How To Reminder: ------------------------- Simply add them to the deliverables/train/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/train/highlights.html file or the output of the build-openstack-sphinx-docs job under html/train/ highlights.html. Can't wait to see you all have accomplished this release! Thanks :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/rocky/highlights.html [2] https://releases.openstack.org/stein/highlights.html [3] https://releases.openstack.org/train/highlights.html [4] htt <https://releases.openstack.org/train/schedule.html#t-cycle-highlights> https://releases.openstack.org/ussuri/schedule.html

2 5

No UC meeting this week
by Mohamed Elsakhawy 08 Apr '20

08 Apr '20

Hi All, There will be no UC meeting tomorrow. Our next meeting is on Thursday April 16th in our regular time. Thanks Mohamed

1 0

[all] Gate status: tempest-full broken on stein
by Ghanshyam Mann 08 Apr '20

08 Apr '20

Hello Everyone, tempest-full (py2 job) started failing on stable/stein gate because devstack try to install master Tempest on system-wide and fail for min require py version by Tempest. We did not set the INSTALL_TEMPEST flag to false for stable branches since stable/pike. I am going to add this as one of thing to do while cutting devstack stable branch. More details on Bug: https://bugs.launchpad.net/tempest/+bug/1871327 Here are the fixes, I am backporting from stable/train: Please hold the recheck until they are merged. https://review.opendev.org/#/q/I60949fb735c82959fb2cfcb6aeef9e33fb0445b6 -gmann

1 2

[tc][oslo] Looking for a Victoria Oslo PTL volunteer
by Thierry Carrez 08 Apr '20

08 Apr '20

Hello everyone, Nobody stepped up yet to continue the great work of Ben Nemec as PTL of the Oslo project team. Oslo handles common code between our various projects, and is key to reduce duplication of code and waste of effort. Oslo is very critical for OpenStack, as all other projects depend on its libraries, but can be relatively low-maintenance as most libraries are feature-complete. Being the Oslo PTL gives you a great horizontal perspective on OpenStack, so they are a great opportunity for smaller organizations that depend on OpenStack to keep track of what's happening and contribute back, without having to specialize in one of the larger projects. I suspect Ben can help answer any question on the workload it represents to be the Oslo PTL. Getting a new volunteer for Oslo PTL is our preferred solution. In case the PTL position is just too intimidating and nobody volunteers, the TC is considering experimenting with a PTL-less form of governance that would involve only designating two liaisons (a release liaison(s) and a security liaison(s)). That is the minimal accountability that we require of an openstack project team (someone(s) signing off releases, and someone(s) to contact in case of embargoed vulnerabilities). I say "someone(s)" as ideally multiple people sign up to be a liaison. In that form of governance, if there is any conflict in the team, the TC can ultimately arbitrate the conflict, instead of the PTL. That would be our plan B. So please let us know if you'd be interested in the Oslo PTL position, or if you'd be OK just for filling the duties of a specific liaison. Thanks for considering it! -- Thierry Carrez (ttx)

3 3

[tripleo] older packages in promoted repos
by Wesley Hayutin 08 Apr '20

08 Apr '20

Greetings, Please hold off any major changes in TripleO for 24 - 48 hours. As discussed in the #tripleo meeting this morning, old rpms from December 2019 have found their way into promoted RDO yum repos for CentOS-8 master [1]. The CI team and RDO team working together to resolve the issue. This is causing some jobs to fail, especially 3rd party jobs at the moment like featureset001. [2,3] We are working through each component yum repo to ensure the latest content is available and will have to repromote content to the upstream. Sorry for the delay and the bugs this is causing in getting your patches validated. [1] https://review.rdoproject.org/r/#/c/26294/ [2] https://bugs.launchpad.net/tripleo/+bug/1871010 [3] https://bugs.launchpad.net/tripleo/+bug/1871181

1 1

[largescale-sig] Next meeting: Apr 8, 8utc
by Thierry Carrez 08 Apr '20

08 Apr '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, April 8 at 8 UTC[1] in #openstack-meeting on IRC. The meeting time was changed at the last meeting to be more friendly to our Asian participants, so please doublecheck how that translates for you at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200408T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - ttx to push for oslo.metric spec approval - oneswig to contribute a scaling story on bare metal cluster scaling - amorin to create a wiki page for large scale documentation - amorin to propose patch against Nova doc Talk to you all on Wednesday, -- Thierry Carrez

1 1

[ironic][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 08 Apr '20

08 Apr '20

Hello ironic team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - bifrost - ironic-prometheus-exporter - ironic-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

6 10

[stackalytics] x/stackalytics repo still used?
by Andreas Jaeger 08 Apr '20

08 Apr '20

Hi Sergey and stackalytics experts, the wiki at https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation points to using the github site for stackalytics - but I see that there are still submissions to the opendev repo at https://review.opendev.org/#/q/project:x/stackalytics so, how are those repos used? Is it time to retire the x/stackalytics repository so that nobody can submit there? Andreas -- 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

2 1

[nova][gate] status of some gate bugs
by melanie witt 08 Apr '20

08 Apr '20

Hey all, We've been having a tough time lately in the gate hitting various bugs while our patches go through CI. I just wanted to mention a few of them that I've seen often in my gerrit notifications and give a brief status on fix efforts. * http://status.openstack.org/elastic-recheck/#1813789 This one is where the nova-live-migration job fails a server evacuate test with: "Timeout waiting for [('network-vif-plugged', 'e3d3db3f-bce4-4889-b161-4b73648f79be')] for instance with vm_state error and task_state rebuild_spawning.: eventlet.timeout.Timeout: 300 seconds" in the screen-n-cpu.txt log. lyarwood has a WIP patch here: https://review.opendev.org/713674 and sean-k-mooney has a WIP patch here: https://review.opendev.org/713342 * https://launchpad.net/bugs/1867380 This one is where the nova-live-migration or nova-grenade-multinode job fail due to n-cpu restarting slowly after being reconfigured for ceph. The server will fail to build and it's because the test begins before nova-compute has fully come up and we see this error: "Instance spawn was interrupted before instance_claim, setting instance to ERROR state {{(pid=3783) _error_out_instances_whose_build_was_interrupted" in the screen-n-cpu.txt log. lyarwood has a patch approved here that we've been rechecking the heck out of that has yet to merge: https://review.opendev.org/713035 * https://launchpad.net/bugs/1844568 This one is where a job fails with: "Body: b'{"conflictingRequest": {"code": 409, "message": "Multiple possible networks found, use a Network ID to be more specific."}}'" gmann has a patch proposed to fix some of these here: https://review.opendev.org/711049 There might be more test classes that need create_default_network = True. * http://status.openstack.org/elastic-recheck/#1844929 This one is where a job fails and the following error is seen one of the logs, usually screen-n-sch.txt: "Timed out waiting for response from cell 8acfb79b-2e40-4e1c-bc3d-d404dac6db90". The TL;DR on this one is there's no immediate clue why it's happening. This bug used to hit more occasionally on "slow" nodes like nodes from the OVH or INAP providers (and OVH restricts disk iops [1]). Now, it seems like it's hitting much more often (still mostly on OVH nodes). I've been looking at it for about a week now and I've been using a DNM patch to add debug logging, look at dstat --disk-wait output, try mysqld my.cnf settings, etc: https://review.opendev.org/701478 So far, what I find is that when we get into the fail state, we get no rows back from the database server when we query for nova 'services' and 'compute_nodes' records, and we fail with the "Timed out waiting for response" error. Haven't figured out why yet, so far. The disk wait doesn't look high when this happens (or at any time during a run) so it's not seeming like it's related to disk IO. I'm continuing to look into it. Cheers, -melanie [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010505…

5 8

[all][elections][tc] TC Voting Kickoff
by Kendall Nelson 07 Apr '20

07 Apr '20

Hello All, The poll for the TC Election is now open and will remain open until Apr 14, 2020 23:45 UTC. We are selecting 5 TC members, please rank all candidates in your order of preference. You are eligible to vote if you are a Foundation individual member[1] that also has committed to one of the official project teams' deliverable repositories[2] over the Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC timeframe (Train to Ussuri) or if you are one of the extra-atcs.[3] What to do if you don't see the email and have a commit in at least one of the official deliverables[2]: * check the trash or spam folder of your gerrit Preferred Email address[4], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[2] and email the election officials[1]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Our democratic process is important to the health of OpenStack, please exercise your right to vote. Candidate statements/platforms can be found linked to Candidate names[6]. Happy voting! Thank you, -Kendall Nelson & the Election Officials [1] https://www.openstack.org/community/members/ [2] https://opendev.org/openstack/governance/raw/tag/0.5.0/reference/projects.y… [3] Look for the extra-atcs element in [2] [4] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [5] https://governance.openstack.org/election/#election-officials [6] https://governance.openstack.org/election/#victoria-tc-candidates

1 0

Inline comments from Zuul
by Monty Taylor 07 Apr '20

07 Apr '20

Hey everybody, Yesterday mnaser finished up a long-standing TODO list item we had of leveraging Zuul’s ability to leave inline comments on changes by parsing out things like linter output and dropping them on changes. This is now live. We’ve run in to a few gotchas (turns out there’s a lot of people doing a lot of different things) - all of which we’ve either fixed or have fixes in flight for. Notably there is a usage pattern of running pylint but only partially caring about the results, which turns inline comments from pylint output into complete noise. We’ve turned off the inline comments in openstack-tox-pylint: https://review.opendev.org/#/c/716599/ https://review.opendev.org/#/c/716600/ although if your project uses it and would like inline comments from it, they can be re-enabled in your project. Similarly the same flag can be used to disable inline comments if your project decides they don't want them for some reason. Work is under way to add parsing for Sphinx output and golangci-lint output. If anybody runs in to any issues - like the results are too noisy or something is breaking where it shouldn’t, please let us know and we’ll get on it as quickly as possible. Thanks! Monty

4 3

[k8s][zun] Introduce a new feature in Ussuri - CRI integration
by Hongbin Lu 07 Apr '20

07 Apr '20

Hi all, As we are approaching the end of Ussuri cycle, I would like to take a chance to introduce a new feature the Zun team implemented in this cycle - CRI integration [1]. As known by people, Zun is an OpenStack Container service. It provides API for users to create and manage application containers in an OpenStack cloud. The main concepts in Zun are "Container" and "Capsule". A container is a single container, while a capsule is a group of co-located and co-scheduled containers (basically the same as k8s pod). Probably, the "Container" concept is more widely used. People can use the /containers API endpoint to create and manage a single container. Under the hook, a container is a Docker container in a compute node. What is special is that each Docker container is given a Neutron port so the container is connected to a tenant network in Neutron. Kuryr-libnetwork is the Docker network plugin we use to perform the Neutron port binding which basically connects the container to the virtual switch managed by Neutron. As mentioned before, the concept of "Capsule" in Zun is basically the same as pod in k8s. We introduced this concept mainly for k8s integration. Roughly speaking, the Zun-k8s integration is achieved by (i) registering a special node in k8s, (ii) watching the k8s API for pods being scheduled to this node and (iii) invoking Zun's /capsules API endpoint to create a capsule for each incoming pod. The (i) and (ii) is done by a CNCF sandbox project called Virtual Kubelet [2]. The (iii) is achieved by providing an OpenStack provider [3] for Virtual Kubelet. The special node registered by Virtual Kubelet is called a virtual node because the node doesn't physically exist. Pods being scheduled to the virtual node is basically offloaded from the current k8s cluster, eventually landed on an external platform such as an OpenStack cloud. In high level, what is offered to end-users is a "serverless kubernetes pod" [4]. This term basically means the ability to run pods on demand without planing the capacity (i.e. nodes) upfront. An example of that is AWS EKS on Fargate [5]. In comparison, the traditional approach is to create an entire k8s cluster upfront in order to run the workload. Let's give a simple example. Suppose you want to run a pod, the traditional approach is to provision a k8s cluster with a worker node. Then, run the pod on the worker node. In contract, the "serverless" approach is to create a k8s cluster without any worker node and the pod is offloaded to a cloud provider that provisions the pods at runtime. This approach works well for applications who have fluctuated workloads so it is hard to provision a cluster with the right size for them. Furthermore, from cloud provider's perspective, if all tenant users offloads their pods to the cloud, the cloud provider might be able to pack the workload better (i.e. with fewer physical nodes) thus saving cost. Under the hook, a capsule is a podsandbox with one or more containers in a CRI runtime (i.e. containerd). Compared to Docker, a CRI runtime has a better support for the pod concept so we chose it to implement capsule. A caveat is that CRI requires a CNI plugin for the networking, so we need to implement a CNI plugin for Zun (called zun-cni). The role of CNI plugin is similar as kuryr-libnetwork that we are using for Docker except it implements a different networking model (CNI). I summaries it as below: +--------------+------------------------+---------------+ | Concept | Container | Capsule (Pod) | +--------------+------------------------+---------------+ | API endpoint | /containers | /capsules | | Engine | Docker | CRI runtime | | Network | kuryr-libnetwork (CNM) | zun-cni (CNI) | +--------------+------------------------+---------------+ Typically, a CRI runtime works well with Kata Container which provides hypervisor-based isolation for neighboring containers in the same node. As a result, it is secure to consolidate pods from different tenants into a single node which increases the resource utilization. For deployment, a typical stack looks like below: +----------------------------------------------+ | k8s control plane | +----------------------------------------------+ | Virtual Kubelet (OpenStack provider) | +----------------------------------------------+ | OpenStack control plane (Zun, Neutron, etc.) | +----------------------------------------------+ | OpenStack data plane | | (Zun compute agent, Neutron OVS agent, etc.) | +----------------------------------------------+ | Containerd (with CRI plugin) | +----------------------------------------------+ | Kata Container | +----------------------------------------------+ In this stack, if a user creates a deployment or pod in k8s, the k8s scheduler will schedule the pod to the virtual node registered by Virtual Kubelet. Virtual Kubelet will pick up the pod and let the configured cloud provider to handle it. The cloud provider invokes Zun API to create a capsule. Upon receiving the API request to create a capsule, Zun scheduler will schedule the capsule to a compute node. The Zun compute agent in that node will provision the capsule using a CRI runtime (containerd in this example). The Zun-CRI runtime communication is done via a gRPC protocol through a unix socket. The CRI runtime will first create the pod in Kata Container (or runc as an alternative) that realizes the pod using a lightweight VM. Furthermore, the CRI runtime will use a CNI plugin, which is the zun-cni binary, to setup the network. The zun-cni binary is a thin executable that dispatches the CNI command to a daemon service called zun-cni-daemon. The community is via HTTP within localhost. The zun-cni-daemon will look up the Neutron port information from DB and perform the port binding. In conclusion, starting from Ussuri, Zun adds support for CRI-compatible runtime. Zun uses CRI runtime to realize the concept of pod. Using this feature together with Virtual Kubelet and Kata Container, we can offer "serverless kubernetes pod" service which is comparable with AWS EKS with Fargate. [1] https://blueprints.launchpad.net/zun/+spec/add-support-cri-runtime <https://github.com/virtual-kubelet/openstack-zun> [2] https://github.com/virtual-kubelet/virtual-kubelet [3] https://github.com/virtual-kubelet/openstack-zun [4] https://aws.amazon.com/about-aws/whats-new/2019/12/run-serverless-kubernete… [5] https://aws.amazon.com/blogs/aws/amazon-eks-on-aws-fargate-now-generally-av…

3 8

[tc][election] campaign discussion: what we can improve in TC & how?
by Ghanshyam Mann 07 Apr '20

07 Apr '20

As we are in the campaigning phase of the TC election, where we start the debate on few topics. This is one of the topics where I would like to start the debate. First off, I'd like to thank all the candidates for showing interest to be part of or continuing as TC. What you think we should and must improve in TC ? This can be the involvement of TC in the process from the governance point of view or technical help for each project. Few of the question is below but feel free to add your improvement points. - Do we have too much restriction on project sides and not giving them a free hand? If yes, what we can improve and how? - Is there less interaction from TC with projects? I am sure few projects/members even do not know even what TC is for? What's your idea to solve this. -gmann

7 9

Re: [release-announce] pbr 5.4.5
by Thomas Goirand 07 Apr '20

07 Apr '20

On 4/7/20 12:16 PM, no-reply(a)openstack.org wrote: > We are overjoyed to announce the release of: > > pbr 5.4.5: Python Build Reasonableness > > [ ... ] > > Changes in pbr 5.4.4..5.4.5 > --------------------------- > > b821df5 Switch to Ussuri jobs > > > Diffstat (except docs and test files) > ------------------------------------- > > .zuul.yaml | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) I wonder, what's the point of such a micro release? I'm sure I'm missing something... Cheers, Thomas Goirand (zigo)

3 2

[all][TC][PTL][election] Nominations Close & Campaigning Begins
by Kendall Nelson 07 Apr '20

07 Apr '20

The PTL and TC Nomination periods are now over. The official candidate lists are available on the election website[0][1]. --PTL Election Details-- There are 16 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant Barbican Cloudkitty Congress I18n Infrastructure Loci Masakari Oslo Packaging_Rpm Placement Rally Swift Tacker Tricircle Zaqar There are no projects with more than one candidate so we won't need to hold any runoffs! Congratulations to our new and returning PTLs! [0] --TC Election Details-- The official candidate list is available on the election website[1]. There are will be a TC election following the campaigning period that has now begun and runs till Apr 07, 2020 23:45 UTC when the polling will begin. You are encouraged to ask questions to the candidates on the ML to help inform your decisions when polling begins. Thank you, -Kendall (diablo_rojo) & the Election Officials [0] https://governance.openstack.org/election/#victoria-ptl-candidates [1] https://governance.openstack.org/election/#victoria-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

8 10

[all][Virtual PTG] Notes from the 'Running Virtual Meetups' session
by Artom Lifshitz 07 Apr '20

07 Apr '20

Hey all, Last week, Red Hat hosted a 'Running Virtual Meetups' virtual session, with presenters from both Red Hat and others in the industry. I attended, hoping to gleam potentially interesting insights into how we can run our virtual PTG. Here are my notes: In real PTG, the physical and geographical aspects of it make it much easier to separate from our usual work. The usual calls, tickets, emails, whatever, take a back seat due to the constraints of a PTG setting. In a virtual PTG, with us sitting at our usual desks, this will become much harder. This leads into the next point - participant engagement. Having technical conversations for 8 hours a day is already hard enough when you're in the same room as the people you're conversing with. When those people are pixels on your screen, it becomes even harder. The session I attended was geared more towards presentations than PTG-style roundtable discussion, so I'm not sure that the proposed mitigations would apply to us. For instance, live polls make no sense in a PTG context. One interesting suggestion was to do physical movement between topics/sessions. The online attention span of a human is estimated to be around 10-15 minutes, so having participants stand up and walk around their desk/kitchen/hallway 4 times an hour could be something worth trying. Another way to keep folks engaged is to actually do things besides talking. In our context, this could mean hacking on some POC code together, or collaboratively writing a spec. Again, the session I attended was geared more towards presentations, so the suggestion was to do live debugging. It's actually more engaging when things break and you fix them as a group, than when a presentation goes off without a hitch. That was about it. There was also a list of potentially useful tools, that I'll present here as a link dump because I've never used any of them: https://www.mentimeter.com/ https://pollev.com/ http://roll20.net/ https://obsproject.com/ https://www.sli.do/ The danger is that too much tech brings complexity that's difficult to manage, so sticking to simple well-known tools can also be an advantage. Hope this is useful, cheers!

1 0

[Watcher]about IRC meeting on April 8
by licanwei 07 Apr '20

07 Apr '20

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

1 0

[neutron][OVN] Multiple mechanism drivers
by Sam Morrison 07 Apr '20

07 Apr '20

We are looking at using OVN and are having some issues with it in our ML2 environment. We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network) Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc. It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks. Am I missing something here? (We’re using Stein version) Thanks, Sam

5 6

[baremetal-sig][ironic] Baremetal whitepaper round 2: doodle
by Arne Wiebalck 07 Apr '20

07 Apr '20

Dear all, After the first very productive sessions on finishing the baremetal whitepaper (thanks to everyone contributing and reviewing afterwards!), we would like to keep the momentum and schedule a second round. I've set up a doodle here [0], and we will send out the call details once we have settled on the time slot(s). If you'd like to participate, please make sure you reply to the doodle before the end of this week. Thanks! Arne [0] https://doodle.com/poll/kyd5vvgmg68vxduv

1 0

[openstack-discuss] [puppet] Nominating Takashi Kajinami for core of the Puppet OpenStack modules
by Shengping Zhong 07 Apr '20

07 Apr '20

Hey Puppet Cores, I would like to nominate Takashi Kajinami as a Core reviewer for the Puppet OpenStack modules. He is an excellent contributor to our modules over the last several cycles. His stats for the last 90 days can be viewed here[0]. Please response with your +1 or any objections. If there are no objections by April 6 I will add him to the core list. As there were no objections, I have added Takashi to the core list. Keep up the good work. Thanks, Shengping. [0] https://www.stackalytics.com/report/contribution/puppet%20openstack-group/90

5 4

[tripleo] old tripleo bugs
by Wesley Hayutin 07 Apr '20

07 Apr '20

Sorry, This time w/ the right filter.. Greetings, As discussed launchpad bugs that are in new or triaged status and were opened over 365 days ago have been moved to incomplete status. The list is here [1] and 286 bugs were moved to incomplete. The subscribed users or reporters can set the bug back to triaged or new, if you need help ping me. Instead of leaving these bugs open forever, it's now up to the owner to flip the status back to something we'll track. We've been kicking hundreds of bugs down each release and that's just silly. Launchpad will expire and close the bugs in 60 days if they are not updated [2]. One note.. there were only 5 bugs in New and opened over 365 days. Thanks all! [1] http://paste.openstack.org/show/791712/ [2] https://help.launchpad.net/BugExpiry

1 0

old tripleo bugs
by Wesley Hayutin 07 Apr '20

07 Apr '20

Greetings, As discussed launchpad bugs that are in new or triaged status and were opened over 365 days ago have been moved to incomplete status. The list is here [1] and 286 bugs were moved to incomplete. The subscribed users or reporters can set the bug back to triaged or new, if you need help ping me. Instead of leaving these bugs open forever, it's now up to the owner to flip the status back to something we'll track. We've been kicking hundreds of bugs down each release and that's just silly. Launchpad will expire and close the bugs in 60 days if they are not updated [2]. One note.. there were only 5 bugs in New and opened over 365 days. Thanks all! [1] http://paste.openstack.org/show/791712/ [2] https://help.launchpad.net/BugExpiry

1 0

choosing object storage
by Tessa Plum 07 Apr '20

07 Apr '20

greetings, What object storage system to choose for integration with openstack environment? ceph or swift? Thank you.

5 5

[neutron][OVN] Issues trying to migrated to OVN using db sync util
by Sam Morrison 07 Apr '20

07 Apr '20

Hi Neutron/OVN devs/ops, We are in the process of migrating to OVN, we are having issues getting all our neutron data into OVN using neutron-ovn-db-sync-util tool Our neutron has: ~250 networks/subnets ~11,000 ports ~53,000 security groups ~200,000 security group rules The issues we have: We get a lot of timeouts with ovsdb transaction so we have made it commit transactions every 50 items. It takes ages to run, we haven’t got a full sync to happen but it has run for over 1.5 hours before we get an error. The main issue is we are getting this error [1] about dictionary changing which is preventing us from completing a full sync. I’m wondering if there are any sites out there running with this size of secgroups/ports etc. We have dedicated hardware for the ovsdb servers etc. so I don’t think it’s something we can chuck more hardware at We are running stein version and wondering if there has been any work in making this better in train or newer? Thanks in advance for any help you can provide us. Cheers, Sam [1] https://bugs.launchpad.net/networking-ovn/+bug/1871272

1 0

[qa] Proposing Martin Kopec to Tempest core
by Ghanshyam Mann 06 Apr '20

06 Apr '20

Hello Everyone, Martin Kopec (IRC: kopecmartin) has been doing great contribution in Tempest since a long time. He has been doing bugs Triage also in Ussuri cycle and has good understanding of Tempest. I would like to propose him for Tempest Core. You can vote/feedback on this email. If no objection by the end of this week, I will add him to the list. -gmann

9 9

New OpenDev Communication Channels
by Clark Boylan 06 Apr '20

06 Apr '20

Hello All, Recently, we've transitioned to using #opendev on Freenode for our synchronous IRC communications. Since then we've spun up a new service-discuss(a)lists.opendev.org mailing list [1] where we'll plan changes to services, notify of meetings, answer questions about services and usage, and otherwise communicate about OpenDev. service-announce(a)lists.opendev.org [2] will remain for important announcements. If you're interested in the developer infrastructure we run please join us on these mailing lists. We encourage every developer to at least subscribe to the service-announce[2] list. It will be very low traffic, and used only for important announcements with wide impact. We are also going to start having our weekly team meeting in #opendev-meeting. The time will continue to be 19:00 UTC Tuesdays. See you there, Clark [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss [2] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce

2 2

[all] OSF Community Meeting Presentation & Recordings
by Allison Price 06 Apr '20

06 Apr '20

Hi everyone, Thank you to those who attended any of the community meetings last week! If you missed one of the calls last week, below are links to the presentation [1], recording in English [2], and recording in Mandarin [3]. A lot of links were discussed and you can find those in the meeting section of the notes as well as the chat from the recordings. We are planning to do this format with project and community updates and OSF event updates quarterly. Stay tuned for the next meeting, and let me know if you have any questions in the meantime. In addition to the quarterly meetings, we would like to hear from the project communities on topics you would like to cover in community meetings or have covered. If you have an idea you would like to share, please drop it in this etherpad [4]. If you see a topic already shared that you would like to collaborate on, please share your name, email and IRC nick next to the topic. Cheers, Allison [1] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b… <https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b…> [4] https://etherpad.openstack.org/p/OSF_Community_Meetings <https://etherpad.openstack.org/p/OSF_Community_Meetings> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[release][oslo] FFE request for Oslo
by Ben Nemec 06 Apr '20

06 Apr '20

Like, all of it. :-) Okay, _most_ of it. Specifically the projects in https://review.opendev.org/#/c/717816/ These all had changes in them which normally don't require release, like doc and test changes. However, if we don't release them before the stable branches are cut, the stable branches won't include any of those doc and test changes. This means the docs will be out of date, and tests may break completely (it would not be the first time). We could backport, but there are kind of a lot of patches involved so it would be much easier to just do some trivial releases now and not have to mess with it later. Apologies for dropping the ball on this since it should have been proposed last week, but I hope you will take pity on me and grant an FFE to undo my mistake. :-) Thanks. -Ben

2 1

[neutron] Bug deputy report for week of March 30th
by Brian Haley 06 Apr '20

06 Apr '20

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869862 - neutron-tempest-plugin-designate-scenario failes frequently with imageservice doesn't have supported version - https://review.opendev.org/#/c/715835/ merged (devstack issue) * https://bugs.launchpad.net/neutron/+bug/1870110 - neutron-rally-task fails in rally_openstack.task.scenarios.neutron.trunk.CreateAndListTrunks - https://review.opendev.org/#/c/716562/ proposed - revert of https://review.opendev.org/#/c/477286/ * https://bugs.launchpad.net/neutron/+bug/1870302 - [VPNaaS]: test_migrations_sync failed with alembic 1.4.2 - gate failure for vpnaas - Dongcan Ye took ownership High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1869887 - L3 DVR ARP population gets incorrect MAC address in some cases - https://review.opendev.org/#/c/716302/ proposed * https://bugs.launchpad.net/neutron/+bug/1870313 - "send_ip_addr_adv_notif" can't use eventlet when called from "keepalived_state_change" - https://review.opendev.org/#/c/716944/ proposed * https://bugs.launchpad.net/neutron/+bug/1870352 - "ctypes.CDLL" C functions could release the GIL during the execution call - https://review.opendev.org/#/c/717017/ proposed * https://bugs.launchpad.net/neutron/+bug/1870569 - Unable to create network without default network_segment_range - Possible regression - https://review.opendev.org/#/c/717754/ proposed Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1870114 - Trunk subports aren't treated as dvr serviced ports - https://review.opendev.org/#/c/716642/ proposed * https://bugs.launchpad.net/neutron/+bug/1870228 - cloud-init metadata fallback broken - https://review.opendev.org/#/c/600421/ changed the bind address - asked if using the metadata "force" config option will help * https://bugs.launchpad.net/bugs/1870296 - [neutron-tempest-plugin]:fwaas Operation cannot be performed since associated firewall group is in PENDING UPDATE - https://review.opendev.org/716891 proposed * https://bugs.launchpad.net/neutron/+bug/1870400 - "ml2_vlan_allocations.vlan_id" value should be checked in the DB backend - https://review.opendev.org/#/c/717083/ proposed Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1869808 - reboot neutron-ovs-agent introduces a short interrupt of vlan traffic - asked if it could be reproduced on a later release Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869877 - Segment doesn't exist network info - https://review.opendev.org/#/c/716275/ proposed (nova) - https://review.opendev.org/#/c/715156/ proposed (neutron) * https://bugs.launchpad.net/neutron/+bug/1870319 - [RFE] Network cascade deletion API call - Slawek already added rfe-triaged tag Invalid bugs ------------ * https://bugs.launchpad.net/neutron/+bug/1869768 - devstack failed when Q_AGENT=ovn - Could not reproduce, suspect invalid local.conf * https://bugs.launchpad.net/neutron/+bug/1870002 - The operating_status value of loadbalancer is abnormal - LBaaS bug, moved to storyboard Further triage required ----------------------- * None

1 0

[ironic] Next weekly meeting canceled (April 13th)
by Iury Gregory 06 Apr '20

06 Apr '20

Hello Ironicers, During our weekly meeting today, we decided to cancel the next weekly meeting (April 13th), since it's a holiday for most of the contributors. Best regards, -- *Att[]'sIury Gregory Melo Ferreira **Software Engineer at Red Hat Czech* *MSc in Computer Science at UFCG* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[openstack-ansible] Retirement of repo_build and pip_install roles
by Dmitriy Rabotyagov 06 Apr '20

06 Apr '20

4 3

[monasca][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello monasca team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - monasca-thresh - monasca-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[manila][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello manila team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - manila-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[magnum][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello magnum team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - magnum-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0