September 2019 - openstack-discuss

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

[Syntribos] Does anyone still use this?
by Gage Hugo 08 May '20

08 May '20

The Security SIG has recently been looking into updating several sites/documentation and one part we discussed the last couple meetings was the security tools listings[0]. One of the projects listed there, Syntribos, doesn't appear to have much activity[1] outside of zuul/python/docs maintenance and the idea of retiring the project was mentioned. However, there does seem to be an occasional bug-fix submitted, so we are sending this email out to see if anyone is still utilizing Syntribos. If so, please either respond here, reach out to us in the #openstack-security irc channel, or fill out the section in the Security SIG Agenda etherpad[2]. Thanks! [0] https://security.openstack.org/#security-tool-development [1] https://review.opendev.org/#/q/project:openstack/syntribos [2] https://etherpad.openstack.org/p/security-agenda

2 2

[openstack-ansible] dropping suse support
by Mohammed Naser 05 May '20

05 May '20

Hi everyone, I've been trying to avoid writing this email for the longest time ever. It's really painful to have to reach this state, but I think we've hit a point where we can no longer maintain support for SUSE within OpenStack Ansible. Unfortunately, with the recent layoffs, the OSA team has taken a huge hit in terms of contributors which means that there is far less contributors within the project. This means that we have less resources to go around and it forces us to focus on a more functional, reliable and well tested set of scenarios. Over the past few cycles, there has been effort to add SUSE support to OpenStack Ansible, during the time that we had maintainers, it was great and SUSE issues were being fixed promptly. In addition, due to the larger team at the time, we found ourselves having some extra time where we can help unbreak other gates. Jesse used to call this a "labour of love", which I admired at the time and hoped we continue to do as much as we can of. However, the lack of a committed maintainer for OpenSUSE has resulted in constantly failing jobs[1][2] (which were moved to non-voting, wasting CI resources as no one fixed them). In addition, it's causing several gate blocks for a few times with no one really finding the time to clean them up. We are resource constrained at this point and we need the resource to go towards making the small subset of supported features functional (i.e. CentOS/Ubuntu). We struggle with that enough, and there seems to be no deployers that are running SUSE in real life at the moment based on bugs submitted. With that, I propose that we drop SUSE support this cycle. If anyone would like to volunteer to maintain it, we can review that option, but that would require a serious commitment as we've had maintainers step off and it hurts the velocity of the project as no one can merge code anymore. ..Really wish I didn't have to write this email Mohammed [1]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct… [2]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…

6 9

[cinder] consistency group not working
by Francois Scheurer 16 Jan '20

16 Jan '20

Dear Cinder Experts We are running the rocky release. |We can create a consistency group: openstack consistency group create --volume-type b9f67298-cf68-4cb2-bed2-c806c5f83487 fsc-consgroup Bug 1: but adding volumes is not working: openstack consistency group add volume c3f49ef0-601e-4558-a75a-9b758304ce3b b48752e3-641f-4a49-a892-6cb54ab6b74d c0022411-59a4-4c7c-9474-c7ea8ccc7691 0f4c6493-dbe2-4f75-8e37-5541a267e3f2 => Invalid volume: Volume is not local to this node. (HTTP 400) (Request-ID: req-7f67934a-5835-40ef-b25c-12591fd79f85) Bug 2: deleting consistency group is also not working (silently failing): openstack consistency group delete c3f49ef0-601e-4558-a75a-9b758304ce3b |||=> AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup'| See details below. Using the --force option makes no difference and the consistency group is not deleted. Do you think this is a bug or a configuration issue? Thank you in advance. | Cheers Francois |Details: ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-api-access.log <== 10.0.129.17 - - [27/Sep/2019:12:16:24 +0200] "POST /v3/f099965b37ac41489e9cac8c9d208711/consistencygroups/3706bbab-e2df-4507-9168-08ef811e452c/delete HTTP/1.1" 202 - 109720 "-" "python-cinderclient" ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-volume.log <== 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server [req-9010336e-d569-47ad-84e2-8dd8b729939c b141574ee71f49a0b53a05ae968576c5 f099965b37ac41489e9cac8c9d208711 - default default] Exception during message handling: AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 163, in _process_incoming 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/osprofiler/profiler.py", line 159, in wrapper 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3397, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server vol_obj.save() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.force_reraise() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3362, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.driver.delete_consistencygroup(context, cg, 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server| -- EveryWare AG François Scheurer Senior Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: francois.scheurer(a)everyware.ch web: http://www.everyware.ch

2 2

[ospurge] looking for project owners / considering adoption
by Adam Harwell 04 Nov '19

04 Nov '19

I haven't seen much activity on this project in a while, and it's been moved to opendev/x since the opendev migration... Who is the current owner of this project? Is there anyone who actually is maintaining it, or would mind if others wanted to adopt the project to move it forward? Thanks, --Adam Harwell

5 10

[nova]review guide for the policy default refresh spec
by Ghanshyam Mann 30 Oct '19

30 Oct '19

Hello Everyone, As many of you might know that in Train, we are doing Nova policy changes to adopt the keystone's new defaults and scope type[1]. There are multiple changes required per policy as mentioned in spec. I am writing this review guide for the patch sequence and at the end how each policy will look like. I have prepared the first set of patches. I would like to get the feedback on those so that we can modify the other policy also on the same line. My plan is to start the other policy work after we merge the first set of policy changes. Patch sequence: Example: os-services API policy: ------------------------------------------------------------- 1. Cover/Improve the test coverage for existing policies: This will be the first patch. We do not have good test coverage of the policy, current tests are not at all useful and do not perform the real checks. Idea is to add the actual tests coverage for each policy as the first patch. new tests try to access the API with all possible context and check for positive and negative cases. - https://review.opendev.org/#/c/669181/ 2. Introduce scope_types: This will add the scope_type for policy. It will be either 'system', 'project' or 'system and project'. In the same patch, along with existing test working as it is, new tests of scope type will be added which will run with [oslo_policy] enforce_scope=True so that we can capture the real scope checks. - https://review.opendev.org/#/c/645427/ 3. Add new default roles: This will add new defaults which can be SYSTEM_ADMIN, SYSTEM_READER, PROJECT_MEMBER_OR_SYSTEM_ADMIN, PROJECT_READER_OR_SYSTEM_READER etc depends on Policy. Test coverage of new defaults, as well as deprecated defaults, are covered in same patch. This patch will add the granularity in policy if needed. Without policy granularity, we cannot add new defaults per rule. - https://review.opendev.org/#/c/648480/ (I need to add more tests for deprecated rules) 4. Pass actual Targets in policy: This is to pass the actual targets in context.can(). Main goal is to remove the defaults targets which is nothing but context'user_id,project_id only. It will be {} if no actual target data needed in check_str. - https://review.opendev.org/#/c/676688/ Patch sequence: Example: Admin Action API policy: 1. https://review.opendev.org/#/c/657698/ 2. https://review.opendev.org/#/c/657823/ 3. https://review.opendev.org/#/c/676682/ 4. https://review.opendev.org/#/c/663095/ There are other patches I have posted in between for common changes or fix or framework etc. [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/polic… -gmann

1 2

[cinder][tooz]Lock-files are remained
by Rikimaru Honjo 19 Oct '19

19 Oct '19

Hi, I'm using Queens cinder with the following setting. --------------------------------- [coordination] backend_url = file://$state_path --------------------------------- As a result, the files like the following were remained under the state path after some operations.[1] cinder-63dacb3d-bd4d-42bb-88fe-6e4180164765-delete_volume cinder-32c426af-82b4-41de-b637-7d76fed69e83-delete_snapshot In my understanding, these are lock-files created for synchronization by tooz. But, these lock-files were not deleted after finishing operations. Is this behaviour correct? [1] e.g. Delete volume, Delete snapshot -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@ntt-tx.co.jp

7 15

[metrics] [telemetry] [stein] cpu_util
by Budai Laszlo 18 Oct '19

18 Oct '19

Hello all, the release release announce of ceilometer rocky is deprecating the cpu_util and *.rate metrics "* cpu_util and *.rate meters are deprecated and will be removed in future release in favor of the Gnocchi rate calculation equivalent." so we don't have them in Stein. Can you direct me to some document that describes how to achieve these with Gnocchi rate calculation? Thank you, Laszlo

5 4

[aodh] [heat] Stein: How to create alarms based on rate metrics like CPU utilization?
by Bernd Bausch 18 Oct '19

18 Oct '19

Prior to Stein, Ceilometer issued a metric named /cpu_util/, which I could use to trigger alarms and autoscaling when CPU utilization was too high. cpu_util doesn't exist anymore. Instead, we are asked to use Gnocchi's /rate/ feature. However, when using rates, alarms on a group of resources require more parameters than just one metric: Both an aggregation and a reaggregation method are needed. For example, a group of instances that implement "myapp": gnocchi measures aggregation -m cpu --reaggregation mean --aggregation rate:mean --query server_group=myapp --resource-type instance Actually, this command uses a deprecated API (but from what I can see, Aodh still uses it). The new way is like this: gnocchi aggregates --resource-type instance '(aggregate rate:mean (metric cpu mean))' server_group=myapp If rate:mean is in the archive policy, it also works the other way around: gnocchi aggregates --resource-type instance '(aggregate mean (metric cpu rate:mean))' server_group=myapp Without reaggregation, I get quite unexpected numbers, including negative CPU rates. If you want to understand why, see this discussion with one of the Gnocchi maintainers [1]. *My problem*: Aodh allows me to set an aggregation method, but not a reaggregation method. How can I create alarms based on rates? The problem extends to Heat and autoscaling. Thanks much, Bernd. [1] https://github.com/gnocchixyz/gnocchi/issues/1044

4 3

[nova][ptg] Ussuri scope containment
by Eric Fried 16 Oct '19

16 Oct '19

Nova developers and maintainers- Every cycle we approve some number of blueprints and then complete a low percentage [1] of them. Which blueprints go unfinished seems to be completely random (notably, it appears to have nothing to do with our declared cycle priorities). This is especially frustrating for consumers of a feature, who (understandably) interpret blueprint/spec approval as a signal that they can reasonably expect the feature to land [2]. The cause for non-completion usually seems to fall into one of several broad categories: == Inadequate *developer* attention == - There's not much to be done about the subset of these where the contributor actually walks away. - The real problem is where the developer thinks they're ready for reviewers to look, but reviewers don't. Even things that seem obvious to experienced reviewers, like failing CI or "WIP" in the commit title, will cause patches to be completely ignored -- but unseasoned contributors don't necessarily understand even that, let alone more subtle issues. Consequently, patches will languish, with each side expecting the other to take the next action. This is a problem of culture: contributors don't understand nova reviewer procedures and psychology. == Inadequate *reviewer* attention == - Upstream maintainer time is limited. - We always seem to have low review activity until the last two or three weeks before feature freeze, when there's a frantic uptick and lots gets done. - But there's a cultural rift here as well. Getting maintainers to care about a blueprint is hard if they don't already have a stake in it. The "squeaky wheel" concept is not well understood by unseasoned contributors. The best way to get reviews is to lurk in IRC and beg. Aside from not being intuitive, this can also be difficult logistically (time zone pain, knowing which nicks to ping and how) as well as interpersonally (how much begging is enough? too much? when is it appropriate?). == Multi-release efforts that we knew were going to be multi-release == These may often drag on far longer than they perhaps should, but I'm not going to try to address that here. ======== There's nothing new or surprising about the above. We've tried to address these issues in various ways in the past, with varying degrees of effectiveness. I'd like to try a couple more. (A) Constrain scope, drastically. We marked 25 blueprints complete in Train [3]. Since there has been no change to the core team, let's limit Ussuri to 25 blueprints [4]. If this turns out to be too few, what's the worst thing that happens? We finish everything, early, and wish we had done more. If that happens, drinks are on me, and we can bump the number for V. (B) Require a core to commit to "caring about" a spec before we approve it. The point of this "core liaison" is to act as a mentor to mitigate the cultural issues noted above [5], and to be a first point of contact for reviews. I've proposed this to the spec template here [6]. Thoughts? efried [1] Like in the neighborhood of 60%. This is anecdotal; I'm not aware of a good way to go back and mine actual data. [2] Stuff happens, sure, and nobody expects 100%, but 60%? Come on, we have to be able to do better than that. [3] https://blueprints.launchpad.net/nova/train [4] Recognizing of course that not all blueprints are created equal, this is more an attempt at a reasonable heuristic than an actual expectation of total size/LOC/person-hours/etc. The theory being that constraining to an actual number, whatever the number may be, is better than not constraining at all. [5] If you're a core, you can be your own liaison, because presumably you don't need further cultural indoctrination or help begging for reviews. [6] https://review.opendev.org/685857

11 21

[tripleo] Deprecating paunch CLI?
by Emilien Macchi 16 Oct '19

16 Oct '19

With our long-term goal to simplify TripleO and focus on what people actually deploy and how they operate their clouds, it appears that the Paunch CLI hasn't been a critical piece in our project and I propose that we deprecate it; create an Ansible module to call Paunch as a library only. I've been playing with it a little today: https://review.opendev.org/#/c/682093/ https://review.opendev.org/#/c/682094/ Here is how you would call paunch: - name: Start containers for step {{ step }} paunch: config: "/var/lib/tripleo-config/hashed-container-startup-config-step_{{ step }}.json" config_id: "tripleo_step{{ step }}" action: apply container_cli: "{{ container_cli }}" managed_by: "tripleo-{{ tripleo_role_name }}" A few benefits: - Deployment tasks in THT would call the new module instead of a shell command - More Pythonic and clean for Ansible, to interact with the actual task during the run - Removing some code in Paunch, make it easier to maintain for us For now, the Ansible module only covers "paunch apply", we will probably cover "delete" and "cleanup" eventually. Please let me know if you have any questions or concerns, -- Emilien Macchi

9 18

[oslo] New courtesy ping list for Ussuri
by Ben Nemec 14 Oct '19

14 Oct '19

As we discussed at the beginning of the cycle, I'll be clearing the current ping list in the next few weeks. This is to prevent courtesy pinging people who are no longer active on the project. If you wish to continue receiving courtesy pings at the start of the Oslo meeting please add yourself to the new list on the agenda template [0]. Note that the new list is above the template, called "Courtesy ping list for Ussuri". If you add yourself again to the end of the existing list I'll assume you want to be left on though. :-) Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

Port creation times out for some VMs in large group
by Albert Braden 12 Oct '19

12 Oct '19

When I create 100 VMs in our prod cluster: openstack server create --flavor s1.tiny --network it-network --image cirros-0.4.0-x86_64 --min 100 --max 100 alberttest Most of them build successfully in about a minute. 5 or 10 will stay in BUILD status for 5 minutes and then fail with " BuildAbortException: Build of instance <UUID> aborted: Failed to allocate the network(s), not rescheduling." If I build smaller numbers, I see less failures, and no failures if I build one at a time. This does not happen in dev or QA; it appears that we are exhausting a resource in prod. I tried reducing various config values in dev but am not able to duplicate the issue. The neutron servers don't appear to be overloaded during the failure. What config variables should I be looking at? Here are the relevant log entries from the HV: 2019-09-26 10:10:43.001 57008 INFO os_vif [req-dea54d9a-3f3e-4d47-b901-a4f41b1947a8 d28c3871f61e4c8c8f8c7600417f7b14 e9621e3b105245ba8660f434ab21016c - default 4fb72165eee4468e8033cdc7d506ddf0] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:8b:45:07,bridge_name='brq49cbe55d-51',has_traffic_filtering=True,id=18f4e419-b19c-4b62-b6e4-152ec78e72bc,network=Network(49cbe55d-5188-4183-b5ad-e65f9b46f8f2),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap18f4e419-b1') 2019-09-26 10:15:44.029 57008 WARNING nova.virt.libvirt.driver [req-dea54d9a-3f3e-4d47-b901-a4f41b1947a8 d28c3871f61e4c8c8f8c7600417f7b14 e9621e3b105245ba8660f434ab21016c - default 4fb72165eee4468e8033cdc7d506ddf0] [instance: dc58f154-00f9-4c45-8986-94b10821cbc9] Timeout waiting for [('network-vif-plugged', u'18f4e419-b19c-4b62-b6e4-152ec78e72bc')] for instance with vm_state building and task_state spawning.: Timeout: 300 seconds More logs and data: http://paste.openstack.org/show/779524/

4 17

Release Cycle Observations
by Donny Davis 09 Oct '19

09 Oct '19

As many of you know I am fairly new to public participation in Openstack, but I am a long time lurker and operator. This is my first cycle and I wanted to capture an observation on the release cycle of Openstack. *this is only an observation for discussion* Over the last week or so I have watch people just about kill themselves to get features into Openstack for this release. Everyone in this community appears to be giving it their all. And way to go everyone for pushing so hard. Seriously! So this brings me to my observation. Can the release cycle be modified to ease this push at the end? I think what we all want is a smooth and steady stream of features and bug fixes, but a 6 month release cycle seems to do directly the opposite. Also if everyone has gate issues at the end of the cycle, is it the gate or the cycle? The gate seemed to work fine early on... Maybe if we went to a Major / Minor release sort of system we could remove some burden to *get that feature into X release* and we could steady out that flow of features / bug fixes. Maybe something like a 9 month major, one month minor release cycle. It would also probably help with micro api versioning. I am sure the more experienced developers here can highlight pros / cons, etc of all of the release types. Just a thought. Tell me yours. ~/DonnyD

10 19

[all][PTG] Strawman Schedule
by Kendall Nelson 09 Oct '19

09 Oct '19

Hello Everyone! In the attached picture or link [0] you will find the proposed schedule for the various tracks at the Shanghai PTG in November. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts especially when the event is three-ish days long and we have over 40 teams meeting. If there are critical conflicts we missed or other issues, please let us know, by October 6th at 7:00 UTC! -Kendall (diablo_rojo) [0] https://usercontent.irccloud-cdn.com/file/00mZ3Q3M/pvg_ptg_schedule.png

9 20

[dev][taskflow] Accepting any decision
by Jiří Rája 08 Oct '19

08 Oct '19

Hi, I wrote the code in the attachment and I would like to ask if it's possible to execute next task (step3) even if one decider returns True (link from step 1 to step 3) and one returns False (link from step 2 to step 3). If it is possible could someone alter the code? Or is there any other way to do it? And if the task wouldn't have to wait for all of the links, it would be great. Thank you! All the best, Rája

2 1

[oslo][nova] Revert of oslo.messaging JSON serialization change
by Ben Nemec 04 Oct '19

04 Oct '19

Hi, I've just proposed https://review.opendev.org/#/c/685724/ which reverts a change that recently went in to make the fake driver in oslo.messaging use jsonutils for message serialization instead of json.dumps. As explained in the commit message on the revert, this is problematic because the rabbit driver uses kombu's default serialization method, which is json.dumps. By changing the fake driver to use jsonutils we've made it more lenient than the most used real driver which opens us up to merging broken changes in consumers of oslo.messaging. We did have some discussion of whether we should try to override the kombu default and tell it to use jsonutils too, as a number of other drivers do. The concern with this was that the jsonutils handler for things like datetime objects is not tz-aware, which means if you send a datetime object over RPC and don't explicitly handle it you could lose important information. I'm open to being persuaded otherwise, but at the moment I'm leaning toward less magic happening at the RPC layer and requiring projects to explicitly handle types that aren't serializable by the standard library json module. If you have a different preference, please share it here. Thanks. -Ben

4 5

[nova][kolla] questions on cells
by Mark Goddard 03 Oct '19

03 Oct '19

Hi, I'm currently working (with dougsz) on adding support for nova cells v2 in Kolla Ansible. I have a few questions, and things that I'd like confirming. 1. Is there any benefit to not having a superconductor? Presumably it's a little more efficient in the single cell case? Also IIUC it only requires a single message queue so is a little simpler? 2. Do console proxies need to live in the cells? This is what devstack does in superconductor mode. I did some digging through nova code, and it looks that way. Testing with novncproxy agrees. This suggests we need to expose a unique proxy endpoint for each cell, and configure all computes to use the right one via e.g. novncproxy_base_url, correct? 3. Should I upgrade the superconductor or conductor service first? 4. Does the cell conductor need access to the API DB? 5. What DB configuration should be used in nova.conf when running online data migrations? I can see some migrations that seem to need the API DB, and others that need a cell DB. If I just give it the API DB, will it use the cell mappings to get to each cell DB, or do I need to run it once for each cell? 6. After an upgrade, when can we restart services to unpin the compute RPC version? Looking at the compute RPC API, it looks like the super conductor will remain pinned until all computes have been upgraded. For a cell conductor, it looks like I could restart it to unpin after upgrading all computes in that cell, correct? 7. Which services require policy.{yml,json}? I can see policy referenced in API, conductor and compute. I'm trying to design it such that it's possible to deploy a new cell in an existing environment, and upgrade one cell at a time. Getting the ordering right for this is fiddly, and I expect I'll be back to get some eyes on my plan. Cheers, Mark

6 16

[i18n] Request to be added as Vietnamese translation group coordinators
by Trinh Nguyen 03 Oct '19

03 Oct '19

Hi i18n team, Dai and I would like to volunteer as the coordinators of the Vietnamese translation group. If you find us qualified, please let us know. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

5 7

[all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org
by Alexandra Settle 03 Oct '19

03 Oct '19

Hi all, Quick recap: The documentation team is set to disband as an official project, and make the leap to becoming a SIG (Special Interest Group). This decision is not one we have made lightly, but with the changes of direction since Pike (project documentation belonging with the projects, etc) the need for a centralised documentation team as an official project is no longer integral to producing the software. The transition of the docs team to a SIG has already begun [1] and [2]. The openstackdocstheme, openstack-doc-tools, os-api-ref and whereto have been placed within the remit of the Oslo team and approved. The remaining individuals working on the docs team are sorting through what's left and where it is best placed. In [1], Doug has rightfully pointed out that whilst the documentation team as it stands today is no longer "integral", the docs.openstack.org web site is. An owner is required. The suggestion is for the Release Management team is the "least worst" (thanks, tonyb) place for the website manaagement to land. As Tony points out, this requires learning new tools and processes but the individuals working on the docs team currently have no intention to leave, and are around to help manage this from the SIG. Open to discussion and suggestions, but to summarise the proposal here: docs.openstack.org ownership is to transition to be the responsibility of the Release Management team officially provided there are no strong objections. Thanks, Alex IRC: asettle [1] https://review.opendev.org/#/c/657142/ [2] https://review.opendev.org/#/c/657141/

5 11

[kolla-ansible] migration
by Ignazio Cassano 02 Oct '19

02 Oct '19

Hello, Anyone have tried to migrate an existing openstack installation to kolla containers? Thanks Ignazio

5 16

issues creating a second vm with numa affinity
by Manuel Sopena Ballesteros 02 Oct '19

02 Oct '19

Dear Openstack user community, I have a compute node with 2 numa nodes and I would like to create 2 vms, each one using a different numa node through numa affinity with cpu, memory and nvme pci devices. pci passthrough whitelist [root@zeus-53 ~]# tail /etc/kolla/nova-compute/nova.conf [notifications] [filter_scheduler] enabled_filters = enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [pci] passthrough_whitelist = [ {"address":"0000:06:00.0"}, {"address":"0000:07:00.0"}, {"address":"0000:08:00.0"}, {"address":"0000:09:00.0"}, {"address":"0000:84:00.0"}, {"address":"0000:85:00.0"}, {"address":"0000:86:00.0"}, {"address":"0000:87:00.0"} ] alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"} Openstack flavor openstack flavor create --public xlarge.numa.perf.test --ram 200000 --disk 700 --vcpus 20 --property hw:cpu_policy=dedicated --property hw:emulator_threads_policy=isolate --property hw:numa_nodes='1' --property pci_passthrough:alias='nvme:4' The first vm is successfully created openstack server create --network hpc --flavor xlarge.numa.perf.test --image centos7.6-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-1 However the second vm fails openstack server create --network hpc --flavor xlarge.numa.perf --image centos7.6-kudu-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-4 Errors in nova compute node 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [req-b5a25c73-8c7d-466c-8128-71f29e7ae8aa 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] Instance failed to spawn: libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-09-27T06:45:19.118089Z qemu-kvm: kvm_init_vcpu failed: Cannot allocate memory 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] Traceback (most recent call last): 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2369, in _build_resources 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] yield resources 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2133, in _build_and_run_instance 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] block_device_info=block_device_info) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3142, in spawn 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] destroy_disks_on_failure=True) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5705, in _create_domain_and_network 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] destroy_disks_on_failure) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] self.force_reraise() 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] six.reraise(self.type_, self.value, self.tb) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5674, in _create_domain_and_network 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] post_xml_callback=post_xml_callback) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5608, in _create_domain 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] guest.launch(pause=pause) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 144, in launch 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] self._encoded_xml, errors='ignore') 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] self.force_reraise() 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] six.reraise(self.type_, self.value, self.tb) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 139, in launch 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] return self._domain.createWithFlags(flags) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] result = proxy_call(self._autowrap, f, *args, **kwargs) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] rv = execute(f, *args, **kwargs) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] six.reraise(c, e, tb) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] rv = meth(*args, **kwargs) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1110, in createWithFlags 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-09-27T06:45:19.118089Z qemu-kvm: kvm_init_vcpu failed: Cannot allocate memory 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] Numa cell/node 1 (the one assigned on kudu-4) has enough cpu, memory, pci devices and disk capacity to fit this vm. NOTE: below is the information relevant I could think of that shows resources available after creating the second vm. [root@zeus-53 ~]# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 28 29 30 31 32 33 34 35 36 37 38 39 40 41 node 0 size: 262029 MB node 0 free: 52787 MB node 1 cpus: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 42 43 44 45 46 47 48 49 50 51 52 53 54 55 node 1 size: 262144 MB node 1 free: 250624 MB node distances: node 0 1 0: 10 21 1: 21 10 NOTE: this is to show that numa node/cell 1 has enough resources available (also nova-compute logs shows that kudu-4 is assigned to cell 1) [root@zeus-53 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/md127 3.7T 9.1G 3.7T 1% / ... NOTE: vm disk files goes to root (/) partition [root@zeus-53 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 59.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 16G 0 part [SWAP] loop0 7:0 0 100G 0 loop └─docker-9:127-6979358884-pool 253:0 0 100G 0 dm ├─docker-9:127-6979358884-4301cee8d0433729cd6332ca2b6111afc85f14c48d4ce2d888a1da0ef9b5ca01 253:1 0 10G 0 dm ├─docker-9:127-6979358884-d59208adcb7cee3418f810f24e6c3a55d39281f713c8e76141fc61a8deba8a2b 253:2 0 10G 0 dm ├─docker-9:127-6979358884-106bc0838e37442eca84eb9ab17aa7a45308b7e3a38be3fb21a4fa00366fe306 253:3 0 10G 0 dm ├─docker-9:127-6979358884-7e16b5d012ab8744739b671fcdc8e47db5cc64e6c3d5a5fe423bfd68cfb07b20 253:4 0 10G 0 dm ├─docker-9:127-6979358884-f1c2545b4edbfd7b42d2a492eda8224fcf7cefc3e3a41e65d307c585acffe6a8 253:5 0 10G 0 dm ├─docker-9:127-6979358884-e7fd6c7b3f624f387bdb3746a7944a30c92d8ee5395e75c76288b281bd009d90 253:6 0 10G 0 dm ├─docker-9:127-6979358884-95a818cc7afd9867385bb9a9ea750d4cc6e162916c6ae3a157097af74578e1e4 253:7 0 10G 0 dm ├─docker-9:127-6979358884-9a7f28d396c149119556f382bf5c19f5925eed5d18b94407649244c7adabb4b3 253:8 0 10G 0 dm ├─docker-9:127-6979358884-b25941b6f115300caea977911e2d7fd3541ef187c9aa5736fe10fad638ecd0d1 253:9 0 10G 0 dm ├─docker-9:127-6979358884-122b201c6ad24896a205f8db4a64759ba8fbd5bbe245d0f98984268a01e6a0c4 253:10 0 10G 0 dm └─docker-9:127-6979358884-bc04120ba59a1b393f338a1cef64b16d920cf4e73400198e4b999bb72a42ff90 253:11 0 10G 0 dm loop1 7:1 0 2G 0 loop └─docker-9:127-6979358884-pool 253:0 0 100G 0 dm ├─docker-9:127-6979358884-4301cee8d0433729cd6332ca2b6111afc85f14c48d4ce2d888a1da0ef9b5ca01 253:1 0 10G 0 dm ├─docker-9:127-6979358884-d59208adcb7cee3418f810f24e6c3a55d39281f713c8e76141fc61a8deba8a2b 253:2 0 10G 0 dm ├─docker-9:127-6979358884-106bc0838e37442eca84eb9ab17aa7a45308b7e3a38be3fb21a4fa00366fe306 253:3 0 10G 0 dm ├─docker-9:127-6979358884-7e16b5d012ab8744739b671fcdc8e47db5cc64e6c3d5a5fe423bfd68cfb07b20 253:4 0 10G 0 dm ├─docker-9:127-6979358884-f1c2545b4edbfd7b42d2a492eda8224fcf7cefc3e3a41e65d307c585acffe6a8 253:5 0 10G 0 dm ├─docker-9:127-6979358884-e7fd6c7b3f624f387bdb3746a7944a30c92d8ee5395e75c76288b281bd009d90 253:6 0 10G 0 dm ├─docker-9:127-6979358884-95a818cc7afd9867385bb9a9ea750d4cc6e162916c6ae3a157097af74578e1e4 253:7 0 10G 0 dm ├─docker-9:127-6979358884-9a7f28d396c149119556f382bf5c19f5925eed5d18b94407649244c7adabb4b3 253:8 0 10G 0 dm ├─docker-9:127-6979358884-b25941b6f115300caea977911e2d7fd3541ef187c9aa5736fe10fad638ecd0d1 253:9 0 10G 0 dm ├─docker-9:127-6979358884-122b201c6ad24896a205f8db4a64759ba8fbd5bbe245d0f98984268a01e6a0c4 253:10 0 10G 0 dm └─docker-9:127-6979358884-bc04120ba59a1b393f338a1cef64b16d920cf4e73400198e4b999bb72a42ff90 253:11 0 10G 0 dm nvme0n1 259:8 0 1.8T 0 disk └─nvme0n1p1 259:9 0 1.8T 0 part └─md127 9:127 0 3.7T 0 raid0 / nvme1n1 259:6 0 1.8T 0 disk └─nvme1n1p1 259:7 0 1.8T 0 part └─md127 9:127 0 3.7T 0 raid0 / nvme2n1 259:2 0 1.8T 0 disk nvme3n1 259:1 0 1.8T 0 disk nvme4n1 259:0 0 1.8T 0 disk nvme5n1 259:3 0 1.8T 0 disk NOTE: this is to show that there are 4 nvme disks (nvme2n1, nvme3n1, nvme4n1, nvme5n1) available for the second vm What "emu-kvm: kvm_init_vcpu failed: Cannot allocate memory" means in this context? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

[qa][stable] tempest.api.volume.test_versions.VersionsTest.test_show_version fails on stable/pike
by Matt Riedemann 02 Oct '19

02 Oct '19

A new test was recently added to tempest [1] which uses the volume API v3 client to list and show versions and compare those against the response schema. It's failing against stable/pike changes [2] presumably because the volume v3 API does not show the (deprecated) v1 API, though I'm a bit confused because the test is doing a GET / and then for each version in the response it's doing a GET /{version}/ so I'm not sure what's up with cinder's pike API version interface where it would list a version but not be able to show it. Anyway, it sounds like this is another case where we're going to have to pin tempest to a tag in devstack on stable/pike to continue running tempest jobs against stable/pike changes, similar to what recently happened with stable/ocata [3]. [1] https://review.opendev.org/#/c/680790/ [2] https://145b0d5be77f0cbe05ff-d67a6226f6eb6d34ab4efd951744a16f.ssl.cf5.rackc… [3] https://review.opendev.org/#/c/681950/ -- Thanks, Matt

3 5

[OSA][openstack-ansible] Stepping down from core reviewer
by Jean-Philippe Evrard 02 Oct '19

02 Oct '19

Hello OSA friends, It's with great sadness that announcing I will be stepping down from OpenStack-Ansible's core role. OSA has been the place where I grew from contributor to OpenStack core for the first time, so it will always keep a special place in my mind :) It's also where I met contributors I can now consider personal friends. It's a project I've helped grow and prosper the last 4 years. I am very happy of what we have all achieved. My last goals in OSA were to simplify it further and a focus on bare metal. Those efforts are either merged or advanced enough nowadays. I consider I have achieved what I wanted to: OSA is now easier than ever to manage, contribute, and deliver. With more experienced people leaving and new people joining, I sure hope the DNA of the project will stay the same: An always welcoming and friendly community, with a no-bullshit and not-too-serious attitude. A project focusing on operator issues and use cases, mentoring contributors to be great members of the OpenStack community. Again, I want to thank you for being an amazing community, and it's been great working with all of you. I think there are still plenty of things OSA can achieve. If you want my opinion, you shouldn't hesitate to contact me. I just don't have enough time to keep up with the reviews, nor am I actively contributing enough to stay at core. All the best, Jean-Philippe Evrard (evrardjp)

5 4

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 30 Sep '19

30 Sep '19

On Mon, Sep 30, 2019 at 06:23:47PM +0000, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/9ee941bea3b8476c98fe6fc17328f1c5 : FAILURE in 15m 10s > - publish-tox-docs-static 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 I'm not entirely sure what caused the failure here, but it is not really an issue. This was a docs-only change, so there wasn't anything to be tagged. Due to the tag-releases job failing, the publish-tox-docs-static job was skipped. There are other patches going through though, so the docs will get picked up and published very soon, if they haven't been already, so nothing to worry about there. Sean

1 0

[swift] Changing the name of an existing policy (in particular Policy-0)
by Mark Kirkwood 30 Sep '19

30 Sep '19

Hi, We are looking at introducing extra policies to a Swift cluster that was built essentially policy unaware (Swift 2.3). So currently all our containers live in policy id 0 (with name of 'Policy-0'). We would like to rename this so that the likes of 'swift stat' give a more human readable name to this policy (e.g 'Default' or 'All-Regions'). Doing some experimentation it looks like this is safe - but I'm asking here to check that I have not missed anything that would nuke the cluster.... Note we are *not* wanting to meddle with the policy id number. regards Mark

2 1

[cinder] train backport potential bugfixes
by Brian Rosmaita 30 Sep '19

30 Sep '19

With RC-1 released and the stable/train branch cut, any new bugfixes to be included in the Cinder Train release must be (1) merged to master, (2) be proposed as backports to stable/train, (3) approved by the cinder stable-maint team. and (4) merged to stable/train before the final RC deadline (10 Oct). If you are working on such a bugfix, please add it to this etherpad: https://etherpad.openstack.org/p/cinder-train-backport-potential Keep in mind that the gate is always slow around this time of the cycle, so the earlier your fixes are proposed, the more likely they are to actually make it into the release. If you don't have a Cinder bugfix you're working on now, it would be helpful if you could do some exploratory testing on Cinder RC-1. You can checkout the tag from git, or use the release tarball: https://releases.openstack.org/train/index.html#train-cinder cheers, brian

2 1

[cyborg] No IRC meeting this week
by Nadathur, Sundar 30 Sep '19

30 Sep '19

No Cyborg IRC meeting this Wednesday, due to national holiday in China. Regards, Sundar

1 0

tricircle 7.0.0.0rc1 (train)
by no-reply＠openstack.org 30 Sep '19

30 Sep '19

Hello everyone, A new release candidate for tricircle for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tricircle/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/tricircle/src/branch/stable/train Release notes for tricircle can be found at: https://docs.openstack.org/releasenotes/tricircle/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/tricircle/+bugs and tag it *train-rc-potential* to bring it to the tricircle release crew's attention.

1 0

[monasca] Ussuri release planning meeting
by Witek Bedyk 30 Sep '19

30 Sep '19

Hello everybody, as yesterday discussed in the team meeting I'd like to find the best time for the planning meeting for the next release cycle. I though about two 4 hours long time slots. Please fill in your preferences in this Doodle survey: https://doodle.com/poll/ugxr89tqmkfwa5r7 Please also leave any feedback about the times in the etherpad. Please let me know if you would like to move the meeting to some other time or make it shorter (or longer). https://etherpad.openstack.org/p/monasca-planning-ussuri Best greetings Witek

1 1

openstack-heat 13.0.0.0rc1 (train)
by no-reply＠openstack.org 30 Sep '19

30 Sep '19

Hello everyone, A new release candidate for openstack-heat for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/heat/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/openstack-heat/src/branch/stable/train Release notes for openstack-heat can be found at: https://docs.openstack.org/releasenotes/heat/

1 0

[neutron] [stable] Proposing Slawek Kaplonski to Neutron Stable core
by Miguel Lavalle 29 Sep '19

29 Sep '19

Hi Stackers, In order to strengthen our stable core team, I want to nominate Slawek Kaplonski to it. Over the past years he has made countless contributions in all areas of the project, has been a member of the core team since two years ago and is the incoming PTL for the U cycle ( https://governance.openstack.org/election/results/ussuri/ptl.html) I will keep this nomination open for a week as customary. Best regards Miguel

6 7

[neutron] bug deputy report for week of 2019-09-23
by Bence Romsics 28 Sep '19

28 Sep '19

Hi All, Next week I'll be out of office, so I'm sending my report a bit early. I won't be able to attend Monday's team meet, but let me please call your attention to the unassigned bugs in this list and the one at the top I could not triage. Still needs triage: * https://bugs.launchpad.net/neutron/+bug/1845360 ARP advertisement issue with DVR Temporary traffic loss with a workaround. My DVR-fu was not enough to process this. Critical: * https://bugs.launchpad.net/neutron/+bug/1845227 new l3 agent router factory breaks neutron-fwaas functional tests Fixed: https://review.opendev.org/652812 High: * https://bugs.launchpad.net/neutron/+bug/1845300 FWaaS tempest tests are failing Unassigned * https://bugs.launchpad.net/neutron/+bug/1845145 [L3] add abilitiy for iptables_manager to ensure rule was added only once Liu is working on a fix: https://review.opendev.org/684237 * https://bugs.launchpad.net/neutron/+bug/1845161 Neutron QoS Policy lost on interfaces In progress, but likely needs another direction for a fix: https://review.opendev.org/684457 * https://bugs.launchpad.net/neutron/+bug/1845557 DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update Swami is working on it, no fix uploaded at the moment. Medium: * https://bugs.launchpad.net/neutron/+bug/1845176 Removing of QoS queue in neutron-ovs-agent fails due to existing references Unassigned * https://bugs.launchpad.net/neutron/+bug/1845364 [fullstack] Race condition when updating the router port information and updating the network MTU Rodolfo is working on it, no fix uploaded at the moment. Low: * https://bugs.launchpad.net/neutron/+bug/1845330 neutron-tempest-plugin API test for list agents failure Slawek is working on it, no fix uploaded at the moment. * https://bugs.launchpad.net/neutron/+bug/1845575 Networking Option 1: Provider networks in neutron Trivial doc-fix: https://review.opendev.org/685267 RFE: * https://bugs.launchpad.net/neutron/+bug/1845622 Decouple allow_address_pair service with security_group Incomplete: * https://bugs.launchpad.net/neutron/+bug/1845603 multiple type networks with different mtu cause vm connectivity problem * https://bugs.launchpad.net/neutron/+bug/1844915 Duplicate packets with two networks connected by router Cheers, Bence (rubasov)

1 0

[keystone] Keystone Team Update - Week of 23 September 2019
by Colleen Murphy 28 Sep '19

28 Sep '19

# Keystone Team Update - Week of 23 September 2019 ## News ### RC1 is out! Keystone 16.0.0.0rc1 is now available to download[1]. Please try it out and report any bugs you find. The stable/train branch has been created, so release-critical fixes need to be committed in master and then backported to stable/train. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00975… ## Action Items n/a ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. We won't hold office hours next week. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 25 changes this week, including the last few scope type changes needed to complete our policy migration. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 34 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 6 new bugs and closed 10. Bugs opened (6) Bug #1845539 (keystone:Low) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1845539 Bug #1845540 (keystone:Low) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1845540 Bug #1845412 (keystone:Undecided) opened by jun923.gu https://bugs.launchpad.net/keystone/+bug/1845412 Bug #1845718 (keystone:Undecided) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1845718 Bug #1842930 (keystonemiddleware:Medium) opened by Morgan Fainberg https://bugs.launchpad.net/keystonemiddleware/+bug/1842930 Bug #1845209 (oslo.policy:High) opened by Ben Nemec https://bugs.launchpad.net/oslo.policy/+bug/1845209 Bugs closed (4) Bug #1842930 (keystone:Medium) https://bugs.launchpad.net/keystone/+bug/1842930 Bug #1840647 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1840647 Bug #1844621 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1844621 Bug #1845412 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1845412 Bugs fixed (6) Bug #1844461 (keystone:High) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1844461 Bug #1805880 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805880 Bug #1818736 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818736 Bug #1829453 (keystone:Low) fixed by Vishakha Agarwal https://bugs.launchpad.net/keystone/+bug/1829453 Bug #1829454 (keystone:Low) fixed by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1829454 Bug #1843931 (oslo.policy:Medium) fixed by Ben Nemec https://bugs.launchpad.net/oslo.policy/+bug/1843931 ## Milestone Outlook https://releases.openstack.org/train/schedule.html The final Train release will happen in three weeks. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

mistral-dashboard 9.0.0.0rc1 (train)
by no-reply＠openstack.org 28 Sep '19

28 Sep '19

Hello everyone, A new release candidate for mistral-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/mistral-dashboard/src/branch/stable/train Release notes for mistral-dashboard can be found at: https://docs.openstack.org/releasenotes/mistral-dashboard/

1 0

mistral-extra 9.0.0.0rc1 (train)
by no-reply＠openstack.org 28 Sep '19

28 Sep '19

Hello everyone, A new release candidate for mistral-extra for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral-extra/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/mistral-extra/src/branch/stable/train Release notes for mistral-extra can be found at: https://docs.openstack.org/releasenotes/mistral-extra/

1 0

mistral 9.0.0.0rc1 (train)
by no-reply＠openstack.org 28 Sep '19

28 Sep '19

Hello everyone, A new release candidate for mistral for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/mistral/src/branch/stable/train Release notes for mistral can be found at: https://docs.openstack.org/releasenotes/mistral/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/mistral/+bugs and tag it *train-rc-potential* to bring it to the mistral release crew's attention.

1 0

barbican 9.0.0.0rc1 (train)
by no-reply＠openstack.org 28 Sep '19

28 Sep '19

Hello everyone, A new release candidate for barbican for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/barbican/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/barbican/src/branch/stable/train Release notes for barbican can be found at: https://docs.openstack.org/releasenotes/barbican/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/barbican/+bugs and tag it *train-rc-potential* to bring it to the barbican release crew's attention.

1 0

[release][glance] FFE glance_store 1.0.1
by Erno Kuvaja 28 Sep '19

28 Sep '19

Hi all, Glance RC1 is currently pending small refactoring on glance_store we'd like to release as 1.0.1. this is related to how multi-store is handling config option registration for reserved stores (like tasks workdir and import staging). On glance_store 1.0.0 release when the config options are processed we end up registering the option groups with oslo_config without actually registering the options into those groups. we would like to have this issue solved so we can merge the last items for Train RC1 an get that hopefully tagged early next week. Best, Erno "jokke" Kuvaja

2 1

masakari 8.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for masakari for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/masakari/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/masakari/src/branch/stable/train Release notes for masakari can be found at: https://docs.openstack.org/releasenotes/masakari/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/masakari/+bugs and tag it *train-rc-potential* to bring it to the masakari release crew's attention.

1 0

masakari-dashboard 1.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for masakari-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/masakari-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/masakari-dashboard/src/branch/stable/train Release notes for masakari-dashboard can be found at: https://docs.openstack.org/releasenotes/masakari-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/masakari/+bugs and tag it *train-rc-potential* to bring it to the masakari-dashboard release crew's attention.

1 0

masakari-monitors 8.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for masakari-monitors for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/masakari-monitors/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/masakari-monitors/src/branch/stable/train Release notes for masakari-monitors can be found at: https://docs.openstack.org/releasenotes/masakari-monitors/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/masakari-monitors/+bugs and tag it *train-rc-potential* to bring it to the masakari-monitors release crew's attention.

1 0

designate-dashboard 9.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for designate-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/designate-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/designate-dashboard/src/branch/stable/train Release notes for designate-dashboard can be found at: https://docs.openstack.org/releasenotes/designate-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/designate-dashboard/+bugs and tag it *train-rc-potential* to bring it to the designate-dashboard release crew's attention.

1 0

senlin 8.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for senlin for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/senlin/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/senlin/src/branch/stable/train Release notes for senlin can be found at: https://docs.openstack.org/releasenotes/senlin/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/senlin/+bugs and tag it *train-rc-potential* to bring it to the senlin release crew's attention.

1 0

magnum 9.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for magnum for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/magnum/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/magnum/src/branch/stable/train Release notes for magnum can be found at: https://docs.openstack.org/releasenotes/magnum/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/magnum/+bugs and tag it *train-rc-potential* to bring it to the magnum release crew's attention.

1 0

heat-dashboard 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for heat-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/heat-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/heat-dashboard/src/branch/stable/train Release notes for heat-dashboard can be found at: https://docs.openstack.org/releasenotes/heat-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/heat-dashboard/+bugs and tag it *train-rc-potential* to bring it to the heat-dashboard release crew's attention.

1 0

[release] Release countdown for week R-2, September 30 - October 4
by Sean McGinnis 27 Sep '19

27 Sep '19

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the Train deliverables. Teams should be working on any release critical bugs that would require another RC or intermediary release before the final release. Actions ---------- Early in the week, the release team will be proposing stable/train branch creation for all deliverables that have not branched yet, using the latest available Train release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/train branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/train branch before releasing out of the stable/train branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for Ussuri development, though the focus should still be on finishing up Train until the final release. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final Train release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targetted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the Train version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: October 10 (R-1 week) Final Train release: October 16 Forum+PTG at Shanghai summit: November 4

1 0

blazar 4.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for blazar for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/blazar/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/blazar/src/branch/stable/train Release notes for blazar can be found at: https://docs.openstack.org/releasenotes/blazar/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/blazar/+bugs and tag it *train-rc-potential* to bring it to the blazar release crew's attention.

1 0

[release][ptl] RC1 Deadline Approaching
by Sean McGinnis 27 Sep '19

27 Sep '19

Hey everyone, Just a reminder that we are hours away from the end of the planned RC1 deadline. There are still quite a few projects that have not done an RC yet. We really could use everyone's help to make this go smoothly. JP was able to generate a set of RC patches for all projects. They can be found here: https://review.opendev.org/#/q/status:open+project:openstack/releases+branc… If you are ready for the RC release, please indicate so by leaving a +1 on the patch so the release team knows it is safe to go ahead with processing the release request. If you are still trying to get some last minute things through the gate, it would also help us if you left a -1 on the release patch with any comments that can help us gauge how long we need to wait yet to do the release. Of course, if you are ready but there have been commits merged since the autogeneration of the patch, please update it with the right commit hash to use. The release, and the stable/train branch, will be created off of this point. One final thing to keep in mind - this is just the initial RC for train. We have a couple weeks to do an RC2 (or even RC3 if needed) so if you are waiting on a few nice to have bugfixes, it is still possible to get those in even if it looks like they will take a little longer. But also keep in mind that with the stable/train branch creation on RC1, those would also need to be backported after merging to master (ussuri) at this point. Thanks for your help as we try to get the train out. Sean

1 1

[openstack-ansible] office hours update
by Mohammed Naser 27 Sep '19

27 Sep '19

Hi everyone, Here’s an update of what happened in this week’s OpenStack Ansible Office Hours. We combined the ironic and inspector virtual environments. The ironic patch needs to be reviewed. We didn’t have much activity because a bunch of us were at AnsibleFest. Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

issues creating a second vm with numa affinity
by Manuel Sopena Ballesteros 27 Sep '19

27 Sep '19

Dear Openstack user community, I have a compute node with 2 numa nodes and I would like to create 2 vms, each one using a different numa node through numa affinity with cpu, memory and nvme pci devices. Openstack flavor openstack flavor create --public xlarge.numa.perf.test --ram 200000 --disk 700 --vcpus 20 --property hw:cpu_policy=dedicated --property hw:emulator_threads_policy=isolate --property hw:numa_nodes='1' --property pci_passthrough:alias='nvme:4' The first vm is successfully created openstack server create --network hpc --flavor xlarge.numa.perf.test --image centos7.6-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-1 However the second vm fails openstack server create --network hpc --flavor xlarge.numa.perf --image centos7.6-kudu-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-4 Errors in nova compute node 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [req-b5a25c73-8c7d-466c-8128-71f29e7ae8aa 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] Instance failed to spawn: libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-09-27T06:45:19.118089Z qemu-kvm: kvm_init_vcpu failed: Cannot allocate memory 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-09-27T06:45:19.118089Z qemu-kvm: kvm_init_vcpu failed: Cannot allocate memory 2019-09-27 16:45:19.785 7 ERROR nova.compute.manager [instance: ebe4e78c-501e-4535-ae15-948301cbf1ae] Numa cell/node 1 (the one assigned on kudu-4) has enough cpu, memory, pci devices and disk capacity to fit this vm. NOTE: below is the information relevant I could think of that shows resources available after creating the second vm. [root@zeus-53 ~]# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 28 29 30 31 32 33 34 35 36 37 38 39 40 41 node 0 size: 262029 MB node 0 free: 52787 MB node 1 cpus: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 42 43 44 45 46 47 48 49 50 51 52 53 54 55 node 1 size: 262144 MB node 1 free: 250624 MB node distances: node 0 1 0: 10 21 1: 21 10 NOTE: this is to show that numa node/cell 1 has enough resources available (also nova-compute logs shows that kudu-4 is assigned to cell 1) [root@zeus-53 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/md127 3.7T 9.1G 3.7T 1% / ... NOTE: vm disk files goes to root (/) partition [root@zeus-53 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 59.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 16G 0 part [SWAP] nvme0n1 259:8 0 1.8T 0 disk └─nvme0n1p1 259:9 0 1.8T 0 part └─md127 9:127 0 3.7T 0 raid0 / nvme1n1 259:6 0 1.8T 0 disk └─nvme1n1p1 259:7 0 1.8T 0 part └─md127 9:127 0 3.7T 0 raid0 / nvme2n1 259:2 0 1.8T 0 disk nvme3n1 259:1 0 1.8T 0 disk nvme4n1 259:0 0 1.8T 0 disk nvme5n1 259:3 0 1.8T 0 disk NOTE: this is to show that there are 4 nvme disks (nvme2n1, nvme3n1, nvme4n1, nvme5n1) available for the second vm What "emu-kvm: kvm_init_vcpu failed: Cannot allocate memory" means in this context? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

Re: [ironic] FFE: Add idrac HW type Redfish virtual media boot interface (Ruby Loo)
by prakash RAMCHANDRAN 27 Sep '19

27 Sep '19

Julia & Richard, We in airship 2.0 need vIrtual media boot up for our work in remoteboot direct using Ironic redfish interface. This is to use both for Ehemeral BareMetalHost as well for target cluter BareMetal Nodes redfish based Virtual Media booting. We in Airship community strongly endorse the exception to include this feature in Train. I am copying few of our TC & WC members who too can confirm my ask on behalf of Airship 2.0 team. ThanksPrakash Ramchandran(pramchan) Sent from Yahoo Mail on Android

4 7

[loci] Stepping down from core reviewer
by Jean-Philippe Evrard 27 Sep '19

27 Sep '19

Hello folks, I no longer have enough time to contribute meaningfully or review in a timely manner to LOCI, so I will step down of the project. It's been great working with you folks! There are so many things that can be done to simplify the project further, and reduce tech debt, rely more on infra/zuul's existing roles and features, but sadly I don't have enough time to tackle those things. If you have extra time and want to step up for changing LOCI don't hesitate to come to me to discuss those ideas :) All the best, Jean-Philippe Evrard (evrardjp)

1 0

[placement] update 19-∞
by Chris Dent 27 Sep '19

27 Sep '19

HTML: https://anticdent.org/placement-update-19-.html Let's call this placement update 19-∞, as this will be my last one. It's been my pleasure to provide this service for nearly [three years](http://lists.openstack.org/pipermail/openstack-dev/2016-November/107…. I hope it has been as useful to others as it has been for me. The goal all along was to provide some [stigmergic](https://en.wikipedia.org/wiki/Stigmergy) structures to augment how we, the placement team, collaborated. I guess it worked: yesterday we released a candidate that will likely become the Train version of placement. The first version where the only placement you can get is from its own repo/project. Thanks to everyone who has made this possible over the years. # Most Important Tetsuro will be the next placement PTL. He and Gibi are working on the project update and other Summit/PTG-related activities for Shanghai. If you have thoughts on that, please contact them. The [now worklist](https://storyboard.openstack.org/#!/worklist/754) I made a couple weeks ago has had some progress, but some tasks remain. None of them were critical for the release, except perhaps the ongoing need for better documentation of how to most effectively use the service. Since we're expecting the Ussuri release to be one where we consolidate how other services make use of placement, most of the items on that list can fit well with that. We should be on the lookout for bugs reported by people trying to the release candidate(s). # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 21 (-2) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 7 (2) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 2 (-2) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 9 (-1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (-1) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 15 (-2). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 6 (0). # osc-placement There are [several](https://review.opendev.org/#/q/project:openstack/osc-placement+sta… osc-placement changes, many of which are related to the cutting of a stable/train branch. # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> No one had the time to address the fix ups for this before Train was cut, so consumer types will be a part of Ussuri. If anyone is available to adopt this, please let me and/or tssurya know. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we made this cycle are fairly complex to use and were fairly complex to write. We need to make sure, with the coming cycle, that we help people use them well. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are two [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users Since we're in RC period I'll not bother listing pending changes. During Ussuri the placement team hopes to be available to facilitate other projects using the service. Keeping track of those is what this section has been trying to do. Besides general awareness of what's going on, I've also used [this gerrit query](https://review.opendev.org/#/q/(message:placement+OR+comment:placeme… to find things that might be related to placement. # End 🙇 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[Oslo][TaskFlow] Accepting any decider
by Jiří Rája 27 Sep '19

27 Sep '19

Hi, I wrote the code in the attachment and I would like to ask if it's possible to execute next task (step3) even if one decider returns True (link from step 1 to step 3) and one returns False (link from step 2 to step 3). If it is possible could you alter the code? Or is there any other way to do it? And if the task wouldn't have to wait for all of the links, it would be great. Thank you! Looking forward to hearing from you. All the best, Rája

1 0

sahara-extra 10.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-extra for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-extra/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-extra/src/branch/stable/train Release notes for sahara-extra can be found at: https://docs.openstack.org/releasenotes/sahara-extra/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+bugs and tag it *train-rc-potential* to bring it to the sahara-extra release crew's attention.

1 0

sahara 11.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara/src/branch/stable/train Release notes for sahara can be found at: https://docs.openstack.org/releasenotes/sahara/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+bugs and tag it *train-rc-potential* to bring it to the sahara release crew's attention.

1 0

[neutron] Is a provider of the "router" extension required also to provide the "extraroute" extension?
by Neil Jerram 27 Sep '19

27 Sep '19

Hi Neutrinos - Calico's plugin has recently started failing CI, at the point where devstack initial network creation does "openstack router create ...", with the classic error "'NoneType' object is not iterable" [1], and I think this is because openstackclient assumes [2] that the returned router dict will always have a 'routes' field. If my analysis is correct, is that a correct assumption, or should openstackclient be more forgiving here? [1] https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f8… [2] https://opendev.org/openstack/python-openstackclient/src/branch/master/open… Many thanks, Neil

2 2

sahara-image-elements 11.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-image-elements for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-image-elements/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-image-elements/src/branch/stable/train Release notes for sahara-image-elements can be found at: https://docs.openstack.org/releasenotes/sahara-image-elements/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+bugs and tag it *train-rc-potential* to bring it to the sahara-image-elements release crew's attention.

1 0

sahara-plugin-ambari 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-ambari for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-ambari/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-ambari/src/branch/stable/train Release notes for sahara-plugin-ambari can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-ambari/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1101 and tag it *train-rc-potential* to bring it to the sahara-plugin-ambari release crew's attention.

1 0

designate 9.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for designate for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/designate/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/designate/src/branch/stable/train Release notes for designate can be found at: https://docs.openstack.org/releasenotes/designate/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/designate/+bugs and tag it *train-rc-potential* to bring it to the designate release crew's attention.

1 0

sahara-dashboard 11.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-dashboard/src/branch/stable/train Release notes for sahara-dashboard can be found at: https://docs.openstack.org/releasenotes/sahara-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+bugs and tag it *train-rc-potential* to bring it to the sahara-dashboard release crew's attention.

1 0

sahara-plugin-storm 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-storm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-storm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-storm/src/branch/stable/train Release notes for sahara-plugin-storm can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-storm/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1105 and tag it *train-rc-potential* to bring it to the sahara-plugin-storm release crew's attention.

1 0

sahara-plugin-vanilla 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-vanilla for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-vanilla/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-vanilla/src/branch/stable/train Release notes for sahara-plugin-vanilla can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-vanilla/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1106 and tag it *train-rc-potential* to bring it to the sahara-plugin-vanilla release crew's attention.

1 0

sahara-plugin-mapr 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-mapr for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-mapr/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-mapr/src/branch/stable/train Release notes for sahara-plugin-mapr can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-mapr/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1103 and tag it *train-rc-potential* to bring it to the sahara-plugin-mapr release crew's attention.

1 0

Re: openstack-placement 2.0.0.0rc1 (train)
by Thomas Goirand 27 Sep '19

27 Sep '19

On 9/26/19 11:53 AM, no-reply(a)openstack.org wrote: > Hello everyone, > > A new release candidate for openstack-placement for the end of the Train > cycle is available! You can find the source code tarball at: > > https://tarballs.openstack.org/placement/ > > Unless release-critical issues are found that warrant a release > candidate respin, this candidate will be formally released as the > final Train release. You are therefore strongly encouraged > to test and validate this tarball! > > Alternatively, you can directly test the stable/train release > branch at: > > https://opendev.org/openstack/openstack-placement/src/branch/stable/train > > Release notes for openstack-placement can be found at: > > https://docs.openstack.org/releasenotes/placement/ Any reason why there's no [release-announce] tag in the subject, thus breaking everyone's filters? Cheers, Thomas Goirand (zigo)

2 2

sahara-plugin-spark 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-spark for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-spark/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-spark/src/branch/stable/train Release notes for sahara-plugin-spark can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-spark/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1104 and tag it *train-rc-potential* to bring it to the sahara-plugin-spark release crew's attention.

1 0

sahara-plugin-cdh 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for sahara-plugin-cdh for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/sahara-plugin-cdh/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/sahara-plugin-cdh/src/branch/stable/train Release notes for sahara-plugin-cdh can be found at: https://docs.openstack.org/releasenotes/sahara-plugin-cdh/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/1102 and tag it *train-rc-potential* to bring it to the sahara-plugin-cdh release crew's attention.

1 0

cinder 15.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for cinder for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/cinder/src/branch/stable/train Release notes for cinder can be found at: https://docs.openstack.org/releasenotes/cinder/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cinder/+bugs and tag it *train-rc-potential* to bring it to the cinder release crew's attention.

1 0

openstack-cyborg 3.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for openstack-cyborg for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cyborg/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/openstack-cyborg/src/branch/stable/train Release notes for openstack-cyborg can be found at: https://docs.openstack.org/releasenotes/cyborg/

1 0

keystone 16.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for keystone for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/keystone/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/keystone/src/branch/stable/train Release notes for keystone can be found at: https://docs.openstack.org/releasenotes/keystone/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/keystone/+bugs and tag it *train-rc-potential* to bring it to the keystone release crew's attention.

1 0

nova 20.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for nova for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/nova/src/branch/stable/train Release notes for nova can be found at: https://docs.openstack.org/releasenotes/nova/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+bugs and tag it *train-rc-potential* to bring it to the nova release crew's attention.

1 0

horizon 16.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for horizon for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/horizon/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/horizon/src/branch/stable/train Release notes for horizon can be found at: https://docs.openstack.org/releasenotes/horizon/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/horizon/+bugs and tag it *train-rc-potential* to bring it to the horizon release crew's attention.

1 0

tacker 2.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for tacker for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tacker/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/tacker/src/branch/stable/train Release notes for tacker can be found at: https://docs.openstack.org/releasenotes/tacker/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/tacker/+bugs and tag it *train-rc-potential* to bring it to the tacker release crew's attention.

1 0

manila EMC Unity driver Doc review
by Dong.Ding＠dell.com 27 Sep '19

27 Sep '19

Hi, As suggested we have submitted the Doc change of Unity in Manila. Keep both Doc almost same and will update both of the changes in the future. Can you help to take a look, here is the link https://review.opendev.org/#/c/681381/ Thanks, Ding Dong

1 0

[tacker][requirements] Requesting a requirement freeze exception for python-tackerclient
by Dharmendra Kushwaha 27 Sep '19

27 Sep '19

Hello everyone, On behalf of the Tacker team, I'm asking for a requirements freeze exception for python-tackerclient. The stable/train branch has been created from the 0.16.0 release of python-tackerclient. And since then, some blocking bug fixes been added. We request to have these changes included in the Train release. Thanks & Regards Dharmendra Kushwaha ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECTI or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECTI or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

2 1

[TripleO][TripleO-Ansible] Transformation Squad Meeting
by Kevin Carter 27 Sep '19

27 Sep '19

Hello all, The TripleO-Transformation squad meeting is shutting down. During the last meeting we decided the time has come for us to fold our efforts back up into TripleO proper [0]. At this time we will no longer hold a separate squad meeting. We will now provide updates during the main TripleO meeting and through mailing list posts, whenever needed. Please update your calendars accordingly. Thank you to everyone who's helped on the Transformation squad efforts thus far. We've made a lot of great progress and we're only getting started. [0] http://eavesdrop.openstack.org/meetings/tripleo/2019/tripleo.2019-09-25-14.… Kevin Carter IRC: cloudnull

1 0

Neutron - dnsmasq reloads causing dhcp failures
by fsbiz＠yahoo.com 27 Sep '19

27 Sep '19

Hi all, We have a relatively stable 140 node Openstack deployment consisting of hypervisors and bare-metal. Periodically, we have observed that the baremetals timeout during the PXE. We have been able to reproduce this relatively easily by rebooting several baremetals simultaneously.I believe I have traced the issue to the dnsmasq reloading every time an entry is added / deleted. Can anyone who has experienced similar issue provide feedback on what you did to work around this ? We are running a stable Queens release. thanks,Fred.

1 0

octavia-dashboard 4.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for octavia-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/octavia-dashboard/src/branch/stable/train Release notes for octavia-dashboard can be found at: https://docs.openstack.org/releasenotes/octavia-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/909 and tag it *train-rc-potential* to bring it to the octavia-dashboard release crew's attention.

1 0

octavia 5.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for octavia for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/octavia/src/branch/stable/train Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *train-rc-potential* to bring it to the octavia release crew's attention.

1 0

manila 9.0.0.0rc1 (train)
by no-reply＠openstack.org 27 Sep '19

27 Sep '19

Hello everyone, A new release candidate for manila for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/manila/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/manila/src/branch/stable/train Release notes for manila can be found at: https://docs.openstack.org/releasenotes/manila/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/manila/+bugs and tag it *train-rc-potential* to bring it to the manila release crew's attention.

1 0

[Infra] [Stable] [Trove] Request membership in trove-stable-maint
by Lingxian Kong 27 Sep '19

27 Sep '19

Hi, Could anyone who has the permission add me (Lingxian Kong anlin.kong(a)gmail.com) to the trove-stable-maint group in Gerrit so that I can merge patches for Trove stable/train? No one in the trove-stable-maint group is active now for Trove, I'm currently the only person who maintains Trove project(e.g. fix CI, complete community goal, add CI job to build trove guest image, etc.). - Best regards, Lingxian Kong Catalyst Cloud

2 2

Retiring stale repositories from the OpenStack org on GitHub
by Thierry Carrez 26 Sep '19

26 Sep '19

Hi everyone, The migration of our infrastructure to the Opendev domain gave us the opportunity to no longer have everything under "openstack" and stop the confusion around what is a part of OpenStack and what is just hosted on the same infrastructure. To that effect, in April we transferred non-OpenStack repositories to their own organization names on Opendev, with the non-claimed ones being kept for the time being under a "x" default organization. One consequence of that transition is that non-OpenStack repositories that were previously mirrored to GitHub under the "openstack" organization are now stale and no longer updated, which is very misleading. Those should now be retired, with a clear pointer to the original repository on Opendev. Jim and I volunteered to build tools to do handle that retirement and we are now ready to run those Thursday. This will not affect OpenStack repositories or repositories that were already retired or migrated off the OpenStack org on GitHub (think openstack-infra, opendev, airship...). That will only clean up no-longer-mirrored, stale, non-openstack repositories still present in the OpenStack GitHub organization. If you own a non-openstack repository on Opendev and would like to enable GitHub mirroring (to a GitHub org of your choice), it is possible to configure it as part of your Zuul jobs. You can follow instructions at: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.ht… Cheers, -- Jim and Thierry

1 1

Neutron - dnsmasq reloads causing dhcp failures
by fsbiz＠yahoo.com 26 Sep '19

26 Sep '19

Hi all, We have a relatively stable 140 node Openstack deployment consisting of hypervisors and bare-metal. Periodically, we have observed that the baremetals timeout during the PXE. We have been able to reproduce this relatively easily by rebooting several baremetals simultaneously.I believe I have traced the issue to the dnsmasq reloading every time an entry is added / deleted. Can anyone who has experienced similar issue provide feedback on what you did to work around this ? For what it is worth we are on a stable Queens release. thanks,Fred.

1 0

[ironic] FFE: Add idrac HW type Redfish virtual media boot interface
by Richard.Pioso＠dell.com 26 Sep '19

26 Sep '19

Hi, I request a late feature freeze exception (FFE) for https://review.opendev.org/#/c/672498/ -- "Add Redfish vmedia boot interface to idrac HW type". There is high demand from operators for this feature. They would be delighted if it were included in Train. We believe it is a low risk change, because of the following: 1) It affects only the idrac hardware type. 2) The highest priority boot interfaces supported by the idrac hardware type remain so. 'ipxe' and 'pxe' continue to have the highest priority, and the new 'idrac-redfish-virtual-media' has the lowest priority. The new order from highest to lowest priority is 'ipxe', 'pxe', and 'idrac-redfish-virtual-media'. 3) The new interface is based on and almost entirely leverages an already merged interface implementation, 'redfish-virtual-media'. [1] Please let me know if you have any concerns or questions. Thank you for your consideration. Rick [1] https://review.opendev.org/#/c/638453/

3 3

networking-ovn 7.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for networking-ovn for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-ovn/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/networking-ovn/src/branch/stable/train Release notes for networking-ovn can be found at: https://docs.openstack.org/releasenotes/networking-ovn/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-ovn/+bugs and tag it *train-rc-potential* to bring it to the networking-ovn release crew's attention.

1 0

neutron 15.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for neutron for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/neutron/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/neutron/src/branch/stable/train Release notes for neutron can be found at: https://docs.openstack.org/releasenotes/neutron/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/neutron/+bugs and tag it *train-rc-potential* to bring it to the neutron release crew's attention.

1 0

ceilometer-powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/ceilometer-powervm/src/branch/stable/train Release notes for ceilometer-powervm can be found at: https://docs.openstack.org/releasenotes/ceilometer-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer-powervm/+bugs and tag it *train-rc-potential* to bring it to the ceilometer-powervm release crew's attention.

1 0

openstack-placement 2.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for openstack-placement for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/placement/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/openstack-placement/src/branch/stable/train Release notes for openstack-placement can be found at: https://docs.openstack.org/releasenotes/placement/

1 0

networking-powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for networking-powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/networking-powervm/src/branch/stable/train Release notes for networking-powervm can be found at: https://docs.openstack.org/releasenotes/networking-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-powervm/+bugs and tag it *train-rc-potential* to bring it to the networking-powervm release crew's attention.

1 0

openstack-congress 10.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for openstack-congress for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/openstack-congress/src/branch/stable/train Release notes for openstack-congress can be found at: https://docs.openstack.org/releasenotes/congress/

1 0

nova_powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for nova_powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/nova_powervm/src/branch/stable/train Release notes for nova_powervm can be found at: https://docs.openstack.org/releasenotes/nova-powervm/

1 0

congress-dashboard 5.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for congress-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/congress-dashboard/src/branch/stable/train Release notes for congress-dashboard can be found at: https://docs.openstack.org/releasenotes/congress-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/congress/+bugs and tag it *train-rc-potential* to bring it to the congress-dashboard release crew's attention.

1 0

ceilometer 13.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for ceilometer for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/ceilometer/src/branch/stable/train Release notes for ceilometer can be found at: https://docs.openstack.org/releasenotes/ceilometer/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer/+bugs and tag it *train-rc-potential* to bring it to the ceilometer release crew's attention.

1 0

panko 7.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for panko for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/panko/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/panko/src/branch/stable/train Release notes for panko can be found at: https://docs.openstack.org/releasenotes/panko/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/panko/+bugs and tag it *train-rc-potential* to bring it to the panko release crew's attention.

1 0

[qa][nova][osapi_compute_workers]
by 崔恒香 26 Sep '19

26 Sep '19

Hello everyone! This was my configuration of osapi_compute_workers: osapi_compute_workers=24 But the number of processes on my controller was 58. root@controller10:~# ps -aux|grep nova-api nova 112811 0.8 0.1 286952 134384 ? Ss 11:51 2:13 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112828 4.4 0.1 478032 258960 ? R 11:51 12:15 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112829 2.6 0.1 470544 251428 ? S 11:51 7:26 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112830 5.0 0.1 482568 263480 ? S 11:51 13:59 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112831 4.6 0.2 484160 266240 ? R 11:51 12:59 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112832 2.3 0.1 477260 258832 ? S 11:51 6:37 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112833 4.5 0.2 483744 265512 ? S 11:51 12:31 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112834 4.9 0.2 492952 275884 ? S 11:51 13:39 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112835 2.5 0.1 468892 251244 ? S 11:51 7:10 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112836 5.0 0.1 480480 263424 ? S 11:51 13:54 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112837 4.7 0.2 493596 275996 ? S 11:51 13:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112838 3.7 0.1 474616 259336 ? S 11:51 10:27 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112839 5.4 0.2 485732 266648 ? S 11:51 15:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112840 4.7 0.1 482836 263748 ? S 11:51 13:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112841 4.6 0.2 517084 297508 ? S 11:51 12:52 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112842 3.0 0.2 491076 271984 ? S 11:51 8:34 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112843 3.8 0.2 487412 270360 ? S 11:51 10:35 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112844 3.0 0.1 469468 251676 ? S 11:51 8:29 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112845 4.5 0.2 489440 270884 ? S 11:51 12:36 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112846 4.3 0.2 493308 275760 ? S 11:51 12:11 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112847 4.5 0.2 490400 272936 ? S 11:51 12:39 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112848 4.3 0.1 482036 262968 ? S 11:51 12:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112849 5.6 0.2 486328 267240 ? S 11:51 15:32 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112850 4.3 0.2 483660 264580 ? S 11:51 12:03 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112851 4.4 0.2 482116 267096 ? S 11:51 12:17 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112875 0.0 0.1 312132 152852 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112876 0.0 0.1 311420 152116 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112877 0.0 0.1 311364 152196 ? S 11:51 0:05 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112878 0.0 0.1 312992 153940 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112879 0.0 0.1 312008 152696 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112880 0.0 0.1 312980 153668 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112881 0.0 0.1 310892 151536 ? S 11:51 0:05 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112882 0.0 0.1 311340 152012 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112883 0.0 0.1 311508 152144 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112884 0.0 0.1 310720 151568 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112885 0.0 0.1 311360 152276 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112886 0.0 0.1 311836 152772 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112887 0.0 0.1 310872 151600 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112888 0.0 0.1 313084 153880 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112889 0.0 0.1 312332 153236 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112890 0.0 0.1 310796 151696 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112891 0.0 0.1 311708 152448 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112892 0.0 0.1 311460 152328 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112893 0.0 0.1 312808 153532 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112897 0.0 0.1 311668 152528 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112898 0.0 0.1 311352 152128 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112899 0.0 0.1 312844 153696 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112901 0.0 0.1 311280 152076 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112904 0.0 0.1 311212 152104 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112907 0.0 0.1 310832 151752 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112915 0.0 0.1 311136 152040 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112918 0.0 0.1 311140 152112 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112919 0.0 0.1 311348 152324 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112920 0.0 0.1 311712 152684 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112923 0.0 0.1 310768 151508 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112927 0.0 0.1 311156 152080 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112928 0.0 0.1 312132 152824 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log

2 2

[tc] Weekly update
by Jean-Philippe Evrard 26 Sep '19

26 Sep '19

Hello my friends, Here's what need attention for the OpenStack TC this week. 1. We should ensure we have two TC members focusing on next cycle goal selection process. As far as I know, there is no one assigned to this yet. And that's _very important_. 2. Jimmy McArthur sent us the results of the OpenStack User survey on the ML [1]. We currently haven't analyzed the information yet. Any volunteer to analyse the information (in order to extract action items) is welcomed. It would be great if we could discuss this at our next official meeting. 3. Our next meeting date needs to be decided (same time as usual). Pleas e use the framadate here [2]. 4. Our next meeting agenda needs clarifications. It would be great if you could update the wiki [3], so that I can send the invite to the ML. 5. We have a vice-chair candidate, Rico. It would be awesome if you could cast a vote on this nomination, if you didn't vote on it yet[4]. 6. There are plenty of patches that are waiting for your opinion. Have a look at [5] to [10] for example :) 7. We may have multiple patches with too many dissenting votes. I will abandon them if nobody is against that (pun intended). Thank you everyone! Jean-Philippe Evrard (evrardjp) [1]: http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00950… [2]: https://framadate.org/6zASzWzX4ejkr4ae [3]: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4]: https://review.opendev.org/684262 [5]: https://review.opendev.org/681203 [6]: https://review.opendev.org/681260 [7]: https://review.opendev.org/681480 [8]: https://review.opendev.org/681924 [9]: https://review.opendev.org/680985 [10]: https://review.opendev.org/682380

2 1

[tc][uc][all] Starting goal selection for U series
by Ghanshyam Mann 26 Sep '19

26 Sep '19

Hello everyone, We are in R10 week of Train cycle and not so far from the start of U cycle. It's time to start the discussions about community-wide goals ideas for the U series. We are little late to start this thread for U series which usually happened during Summit Forum. But it is not mandatory to wait for f2f meetup to kick off the goal discussions, we can always start the same via ML or ad-hoc meetings. During Shanghai Summit Forum, we will be having the f2f discussion for U (continue the discussion from ML threads) as well as V cycle goals ideas. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. Also, you can refer to the backlogs of community-wide goals from this[2] and train cycle goals[3]. If you are interested in proposing a goal, please write down the idea on this etherpad[4] - https://etherpad.openstack.org/p/PVG-u-series-goals Accordingly, we will start the separate ML discussion over each goal idea. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/community-goals [3] https://etherpad.openstack.org/p/BER-t-series-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann

1 1

numa affinity question
by Manuel Sopena Ballesteros 26 Sep '19

26 Sep '19

Dear openstack user group, I have a server with 2 numa nodes and I am trying to setup nova numa affinity. [root@zeus-53 ~]# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 28 29 30 31 32 33 34 35 36 37 38 39 40 41 node 0 size: 262029 MB node 0 free: 2536 MB node 1 cpus: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 42 43 44 45 46 47 48 49 50 51 52 53 54 55 node 1 size: 262144 MB node 1 free: 250648 MB node distances: node 0 1 0: 10 21 1: 21 10 openstack flavor create --public xlarge.numa.perf --ram 250000 --disk 700 --vcpus 25 --property hw:cpu_policy=dedicated --property hw:emulator_threads_policy=isolate --property hw:numa_nodes='1' --property pci_passthrough:alias='nvme:4' openstack server create --network hpc --flavor xlarge.numa.perf --image centos7.6-kudu-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-1 This is the xmldump for the created vm But for some reason the second VM fails to create with the error <name>instance-00000108</name> <uuid>5d278c90-27ab-4ee4-aeea-e1bf36ac246a</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="18.2.2-1.el7"/> <nova:name>kudu-4</nova:name> <nova:creationTime>2019-09-25 07:20:32</nova:creationTime> <nova:flavor name="xlarge.numa.perf"> <nova:memory>250000</nova:memory> <nova:disk>700</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>25</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="91e83343e9834c8ba0172ff369c8acac">admin</nova:user> <nova:project uuid="b91520cff5bd45c59a8de07c38641582">admin</nova:project> </nova:owner> <nova:root type="image" uuid="ff9e09ac-86d5-4698-9883-cf3e6579caec"/> </nova:instance> </metadata> <memory unit='KiB'>256000000</memory> <currentMemory unit='KiB'>256000000</currentMemory> <vcpu placement='static'>25</vcpu> <cputune> <shares>25600</shares> <vcpupin vcpu='0' cpuset='27'/> <vcpupin vcpu='1' cpuset='55'/> <vcpupin vcpu='2' cpuset='50'/> <vcpupin vcpu='3' cpuset='22'/> <vcpupin vcpu='4' cpuset='49'/> <vcpupin vcpu='5' cpuset='21'/> <vcpupin vcpu='6' cpuset='48'/> <vcpupin vcpu='7' cpuset='20'/> <vcpupin vcpu='8' cpuset='25'/> <vcpupin vcpu='9' cpuset='53'/> <vcpupin vcpu='10' cpuset='18'/> <vcpupin vcpu='11' cpuset='46'/> <vcpupin vcpu='12' cpuset='51'/> <vcpupin vcpu='13' cpuset='23'/> <vcpupin vcpu='14' cpuset='19'/> <vcpupin vcpu='15' cpuset='47'/> <vcpupin vcpu='16' cpuset='26'/> <vcpupin vcpu='17' cpuset='54'/> <vcpupin vcpu='18' cpuset='42'/> <vcpupin vcpu='19' cpuset='14'/> <vcpupin vcpu='20' cpuset='17'/> <vcpupin vcpu='21' cpuset='45'/> <vcpupin vcpu='22' cpuset='43'/> <vcpupin vcpu='23' cpuset='15'/> <vcpupin vcpu='24' cpuset='24'/> <emulatorpin cpuset='14-15,17-27,42-43,45-51,53-55'/> </cputune> <numatune> <memory mode='strict' nodeset='1'/> <memnode cellid='0' mode='strict' nodeset='1'/> </numatune> <sysinfo type='smbios'> <system> <entry name='manufacturer'>RDO</entry> <entry name='product'>OpenStack Compute</entry> <entry name='version'>18.2.2-1.el7</entry> <entry name='serial'>00000000-0000-0000-0000-0cc47aa482cc</entry> <entry name='uuid'>5d278c90-27ab-4ee4-aeea-e1bf36ac246a</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-i440fx-rhel7.6.0'>hvm</type> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> <topology sockets='25' cores='1' threads='1'/> <numa> <cell id='0' cpus='0-24' memory='256000000' unit='KiB'/> </numa> </cpu> <clock offset='utc'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> </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/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='piix3-uhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <interface type='bridge'> <mac address='fa:16:3e:d6:1d:78'/> <source bridge='qbr16cb6622-01'/> <target dev='tap16cb6622-01'/> <model type='virtio'/> <mtu size='1500'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <log file='/var/lib/nova/instances/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/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/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/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='192.168.1.53'> <listen type='address' address='192.168.1.53'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x87' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x86' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x85' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <memballoon model='virtio'> <stats period='10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </memballoon> </devices> </domain> QUESTIONS: Are my vcpus in the same numa node? if not why? How can I tell from the xmldump that all vcpus are assigned to the same numa node? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

Re: [Release-job-failures] Release of openstack/ironic-prometheus-exporter for ref refs/tags/1.0.0 failed
by Thierry Carrez 25 Sep '19

25 Sep '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python https://zuul.opendev.org/t/openstack/build/d1ff269af65f431abd4d057be7d480b2 : POST_FAILURE in 2m 44s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED So this one failed because there is already a ironic-prometheus-exporter 1.0.0 on Pypi, uploaded on June 13: https://pypi.org/project/ironic-prometheus-exporter/1.0.0/ This is obviously very confusing: the recently-pushed 1.0.0 tag does not correspond to the published PyPI release, and our 1.0.0 tarball is not what was uploaded to PyPI. We can't rewrite history, but I propose we push a 1.1.0 release (and remove reference to 1.0.0 release in our history) to sync things up: https://review.opendev.org/684721 -- Thierry Carrez (ttx)

3 2