- openstack-discuss - lists.openstack.org

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

[scientific-sig] IRC meeting today 1100 UTC: Baremetal SIG, GPFS+Manila, Open Infra Summit
by Stig Telfer 30 Jan '19

30 Jan '19

Hi All - We have a Scientific SIG IRC meeting at 1100 UTC (about 40 minutes time) in channel #openstack-meeting. Everyone is welcome. The agenda is online here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_30th_2019 Today we’d like to discuss the formation of the new baremetal SIG, do a little planning on participation at the Denver Summit, and share experiences on GPFS with Manila. Cheers, Stig

1 0

[oslo] Proposing Zane Bitter as general Oslo core
by Ben Nemec 30 Jan '19

30 Jan '19

Hi all, Zane is already core on oslo.service, but he's been doing good stuff in adjacent projects as well. We could keep playing whack-a-mole with giving him +2 on more repos, but I trust his judgment so I'm proposing we just add him to the oslo-core group. If there are no objections in the next week I'll proceed with the addition. Thanks. -Ben

7 8

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

30 Jan '19

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

2 1

Re: [Release-job-failures] Release of openstack/ovsdbapp failed
by Doug Hellmann 29 Jan '19

29 Jan '19

zuul(a)openstack.org writes: > Build failed. > > - release-openstack-python http://logs.openstack.org/76/767f3ea3efcedb4c8df1dae1a6b40d0b0a230d3d/relea… : POST_FAILURE in 3m 17s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures This release failed due to a known issue for which Sean has already proposed a fix. https://review.openstack.org/633829 -- Doug

1 0

[tripleo][ptl]What is the future of availability monitoring in TripleO?
by David M Noriega 29 Jan '19

29 Jan '19

I've noticed that the availability monitoring integration in TripleO using Sensu is marked for deprecation post Rocky, but I do not see any blueprints detailing a replacement plan like there is for fluentd to rsyslog for the logging integration. Where can I find information on what the roadmap is? Is this a feature that will be dropped and left to operators to implement?

3 2

[all] Is the Denver Summit save?
by Frank Kloeker 29 Jan '19

29 Jan '19

Good morning, just a question, out of curiosity: Is the Denver Summit save? I mean, we received a lot of breaking news in the morning, that Huawei is charged in court and is doing a lot of bad things (i.e. stolen a robotics arm). I don't want to bring in any political discussions. But surely as you know, Huawei is one of the top contributor to our Open Source project. They work hard and do not need to steal things. Is there any chance that one of our friends will be caught next? At the summit between political fronts? I feel a little uncomfortable with it. We are an open community and should clarify this inconsistency. kind regards Frank

6 8

[kayobe] Proposing Pierre Riteau for core
by Mark Goddard 29 Jan '19

29 Jan '19

Hi, I'd like to propose Pierre Riteau (priteau) for core. He has contributed a number of good patches and provided some thoughtful and useful reviews. Cores, please respond +1 or -1. Mark

3 3