- openstack-discuss - lists.openstack.org

[release] Release countdown for week R-9, February 4-8
by Sean McGinnis 31 Jan '19

31 Jan '19

Welcome back to the countdown emails. Some important deadlines are starting to come up quick, so please take a look at what might affect you. Development Focus ----------------- Teams should be focused on implementing planned work for the cycle. It is also a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- We have a few deadlines coming up as we get closer to the end of the cycle: * Non-client libraries (generally, any library that is not python-${PROJECT}client) must have a final release by February 28. Only critical bugfixes will be allowed past this point. Please make sure any important feature works has required library changes by this time. * Client libraries must have a final release by March 7. Quick reminder for teams with cycle-with-intermediary deliverables that are not libraries - we had mentioned earlier in the cycle that you may want to consider moving to the new cycle-with-rc model if you are not actually doing intermediary releases: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… Next week we will be looking at what cycle-with-intermediary deliverables have not done a release yet in Stein. We can still give a little time if teams want to quick get one in before Stein-3, but we will look at switching over those deliverables to cycle-with-rc if that appears to be a more appropriate release model for the way they are being released. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Stein-3 milestone: March 7 -- Sean McGinnis (smcginnis)

1 0

[3rd party CI] [ironic] BaremetalBasicOps test
by Michael Turek 31 Jan '19

31 Jan '19

Hello all, Our ironic job has been broken and it seems to be due to a lack of IPs. We allocate two IPs to our job, one for the dhcp server, and one for the target node. This had been working for as long as the job has existed but recently (since about early December 2018), we've been broken. The job is able to clean the node during devstack, successfully deploy to the node during the tempest run, and is successfully validated via ssh. The node then moves to clean failed with a network error [1], and the job subsequently fails. Sometime between the validation and attempting to clean, the neutron port associated with the ironic port is deleted and a new port comes into existence. Where I'm having trouble is finding out what this port is. Based on it's MAC address It's a virtual port, and its MAC is not the same as the ironic port. We could add an IP to the job to fix it, but I'd rather not do that needlessly. Any insight or advice would be appreciated here! Thanks, Mike Turek <mjturek> [1] http://paste.openstack.org/show/743191/

1 0

[Openstack-sigs] [publiccloud-wg] Late reminder weekly meeting Public Cloud WG
by Tobias Rydberg 31 Jan '19

31 Jan '19

Hi everyone, Time for a new meeting for PCWG - today (31st) 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Sorry for the late reminder! Talk to you later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

Issue with launching instance with OVS-DPDK
by David Lake 31 Jan '19

31 Jan '19

Hello I've built an Openstack all-in-one using OVS-DPDK via Devstack. I can launch instances which use the "m1.small" flavour (which I have modified to include the hw:mem_size large as per the DPDK instructions) but as soon as I try to launch anything more than m1.small, I get this error: Jan 28 12:56:52 localhost nova-conductor: #033[01;31mERROR nova.scheduler.utils [#033[01;36mNone req-917cd3b9-8ce6-41af-8d44-045002512c91 #033[00;36madmin admin#033[01;31m] #033[01;35m[instance: 25cfee28-08e9-419c-afdb-4d0fe515fb2a] #033[01;31mError from last host: localhost (node localhost): [u'Traceback (most recent call last):\n', u' File "/opt/stack/nova/nova/compute/manager.py", line 1935, in _do_build_and_run_instance\n filter_properties, request_spec)\n', u' File "/opt/stack/nova/nova/compute/manager.py", line 2215, in _build_and_run_instance\n instance_uuid=instance.uuid, reason=six.text_type(e))\n', u'RescheduledException: Build of instance 25cfee28-08e9-419c-afdb-4d0fe515fb2a was re-scheduled: internal error: qemu unexpectedly closed the monitor: 2019-01-28T12:56:48.127594Z qemu-kvm: -chardev socket,id=charnet0,path=/var/run/openvswitch/vhu46b3c508-f8,server: info: QEMU waiting for connection on: disconnected:unix:/var/run/openvswitch/vhu46b3c508-f8,server\n2019-01-28T12:56:49.251071Z qemu-kvm: -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/4-instance-00000005,share=yes,size=4294967296,host-nodes=0,policy=bind: os_mem_prealloc: Insufficient free host memory pages available to allocate guest RAM\n']#033[00m#033[00m My Hypervisor is reporting 510.7GB of RAM and 61 vCPUs. Build is the latest git clone of Devstack. Thanks David

3 9

[infra] fedora-29 node failures
by Paul Belanger 30 Jan '19

30 Jan '19

Morning, Jobs depending on fedora-latest (fedora-29 in this case) look to be in a broken state currently. Since this past weekend, we seems to be hitting an issue with network manager and dbus. From what I can see, we are only currently launching fedora-29 nodes in limestone (resulting it long wait times), and when they come online, seem to fail quikcly with DNS related issues. If you are interested in these jobs, please join #openstack-infra and aid in debugging them. Thanks, Paul

2 1

[openstack-ansible] adding James Denton to os_neutron core
by Mohammed Naser 30 Jan '19

30 Jan '19

Hi team, I'm happy to announce the addition of James Denton to the os_neutron Ansible role core team. James is one of the very knowledgeable OpenStack Networking experts (having authored books about it as well!) and we're happy to have him working on our team. James has contributed a lot of work to add and maintain SDNs support in OpenStack Ansible, with many useful reviews across the os_neutron role (his most recent work, iterating on adding VPP support), he's also always available to help new users of our project in IRC. Thanks & welcome James! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

3 2

Open Infrastructure Summit Shanghai - Dates and Location
by Erin Disney 30 Jan '19

30 Jan '19

Hi everyone- We are excited to announce that after Denver, the Open Infrastructure Summit will be traveling to Shanghai, China the week of November 4, 2019. The Summit will be held at the Shanghai Expo Centre. Registration and sponsorship opportunities will be available soon. We’ll follow up on the mailing list, and you can check out the website for updates[1] and reach out to summit(a)openstack.org <mailto:summit@openstack.org> with any questions. Cheers, Erin [1] https://www.openstack.org/summit/shanghai-2019 <https://www.openstack.org/summit/shanghai-2019> Erin Disney OpenStack Marketing erin(a)openstack.org <mailto:erin@openstack.org>

1 0

RE: [openstack] [Nova] Instance automatically got shutdown
by Md. Farhad Hasan Khan 30 Jan '19

30 Jan '19

Hi, Sorry for mistake. I corrected the subject line. Thanks Rony -----Original Message----- From: Slawomir Kaplonski [mailto:skaplons@redhat.com] Sent: Wednesday, January 30, 2019 2:55 PM To: rony.khan(a)brilliant.com.bd Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [openstack] [Neutron] Instance automatically got shutdown Hi, Why You tagged „Neutron” in topic? IMO it’s some issue related to Nova rather than Neutron. > Wiadomość napisana przez Md. Farhad Hasan Khan <rony.khan(a)brilliant.com.bd> w dniu 30.01.2019, o godz. 05:07: > > Hi, > we are getting Openstack instance automatically shut down. Instance not shut down from horizon/cli & from inside instance. This is happening randomly in our environment. Please help us to solve this. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > cat /etc/nova/nova.conf > > [DEFAULT] > sync_power_state_interval=-1 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Here is log: > > [root@compute2 ~]# cat /var/log/nova/nova-compute.log |grep 4e143f50-49d4-40c9-b80e-c99dfe45d9d4 > 2019-01-30 08:06:18.750 417615 INFO nova.compute.manager [-] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] VM Stopped (Lifecycle Event) > 2019-01-30 08:06:18.855 417615 INFO nova.compute.manager [req-c2b7b111-e124-4aac-8971-59c3f840bacc - - - - -] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. > 2019-01-30 08:06:19.027 417615 WARNING nova.compute.manager [req-c2b7b111-e124-4aac-8971-59c3f840bacc - - - - -] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 > 2019-01-30 08:06:19.376 417615 INFO nova.compute.manager [req-c2b7b111-e124-4aac-8971-59c3f840bacc - - - - -] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] Instance is already powered off in the hypervisor when stop is called. > 2019-01-30 08:06:19.441 417615 INFO nova.virt.libvirt.driver [req-c2b7b111-e124-4aac-8971-59c3f840bacc - - - - -] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] Instance already shutdown. > 2019-01-30 08:06:19.445 417615 INFO nova.virt.libvirt.driver [-] [instance: 4e143f50-49d4-40c9-b80e-c99dfe45d9d4] Instance destroyed successfully. > > > Thanks & B’Rgds, > Rony — Slawek Kaplonski Senior software engineer Red Hat

3 2

[infra][tc] Container images in openstack/ on Docker Hub
by corvus＠inaugust.com 30 Jan '19

30 Jan '19

Hi, As part of the recent infrastructure work described in http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002026.… we now have the ability to fairly easily support uploading of container images to the "openstack/" namespace on Docker Hub. The Infrastructure team does have an account on Docker Hub with ownership rights to this space. It is now fairly simple for us to allow any OpenStack project to upload to openstack/$short_name. As a (perhaps unlikely, but simple) example, Nova could upload images to "openstack/nova", including suffixed images, such as "openstack/nova-scheduler". The system that would enable this is described in this proposed change: https://review.openstack.org/632818 I believe it's within the TC's purview to decide whether this should happen, and if so, what policies should govern it (i.e., what projects are entitled to upload to openstack/). It's possible that the status quo where deployment projects upload to their own namespaces (e.g., loci/) while openstack/ remains empty is desirable. However, since we recently gained the technical ability to handle this, I thought it worth bringing up. Personally, I don't presently advocate one way or the other. -Jim

9 18

[oslo] oslo.utils EventletEvent changes
by Ben Nemec 30 Jan '19

30 Jan '19

Hey, We have a bit of an issue in the EventletEvent class in oslo.utils. We had to blacklist the versions that had the race fix because it turned out that it reintroduced the double-set bug. So the current version is subtly broken, and we released the oslo.service change that started to use it (which is how we found the double-set bug). There are actually two patches proposed right now related to this.[1][2] The first simply fixes the bug, the second optimizes it so we aren't doing unnecessary event replacement. What I would like to do is merge the first patch, release the library with just that, then merge the second patch and release again. That way if we're wrong about the optimization patch being correct (I don't think we are, but this is concurrency, so...) we have the safer fix available in a release. The reason I'm emailing instead of just doing this is that I'm going to be unavailable after today until the 11th, and it would be nice to get at least the first release done before then. I can maybe get that done today, but in case I don't I wanted to get this on record. Thanks. -Ben 1: https://review.openstack.org/#/c/632758 2: https://review.openstack.org/#/c/633053

1 0