January 2019 - openstack-discuss - lists.openstack.org

[nova] [placement] [packaging] placement extraction check in meeting
by Chris Dent 06 Feb '19

06 Feb '19

As discussed in the recent pupdate [1] there will be a meeting this Wednesday at 1700 UTC to discuss the current state of the placement extraction and get some idea on the critical items that need to be addressed to feel comfy. If you're interested in this topic, meet near that time in the #openstack-placement IRC channel and someone will produce links for a hangout, etherpad, whatever is required. Thanks. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

6 13

[openstack-dev] [stackalytics] Stackalytics Facelift
by Boris Renski 06 Feb '19

06 Feb '19

Folks, Happy New Year! We wanted to start the year by giving a facelift to stackalytics.com (based on stackalytics openstack project). Brief summary of updates: - We have new look and feel at stackalytics.com - We did away with DriverLog <http://stackalytics.com/report/driverlog> and Member Directory <http://stackalytics.com/report/members>, which were not very actively used or maintained. Those are still available via direct links, but not in the men on the top - BIGGEST CHANGE: You can now track some of the CNCF and Unaffiliated project commits via a separate subsection accessible at the top nav. Before this was all bunched up in Project Type -> Complimentary Happy to hear comments or feedback or answer questions. -Boris

6 10

[tc][all] Project deletion community goal for Train cycle
by Adrian Turjak 06 Feb '19

06 Feb '19

Hello OpenStackers! As discussed at the Berlin Summit, one of the proposed community goals was project deletion and resource clean-up. Essentially the problem here is that for almost any company that is running OpenStack we run into the issue of how to delete a project and all the resources associated with that project. What we need is an OpenStack wide solution that every project supports which allows operators of OpenStack to delete everything related to a given project. Before we can choose this as a goal, we need to define what the actual proposed solution is, and what each service is either implementing or contributing to. I've started an Etherpad here: https://etherpad.openstack.org/p/community-goal-project-deletion Please add to it if I've missed anything about the problem description, or to flesh out the proposed solutions, but try to mostly keep any discussion here on the mailing list, so that the Etherpad can hopefully be more of a summary of where the discussions have led. This is mostly a starting point, and I expect there to be a lot of opinions and probably some push back from doing anything too big. That said, this is a major issue in OpenStack, and something we really do need because OpenStack is too big and too complicated for this not to exist in a smart cross-project manner. Let's solve this the best we can! Cheers, Adrian Turjak

7 15

[neutron] OVS OpenFlow L3 DVR / dvr_bridge agent_mode
by Duarte Cardoso, Igor 06 Feb '19

06 Feb '19

Hi Neutron, I've been internally collaborating on the ``dvr_bridge`` L3 agent mode [1][2][3] work (David Shaughnessy, Xubo Zhang), which allows the L3 agent to make use of Open vSwitch / OpenFlow to implement ``distributed`` IPv4 Routers thus bypassing kernel namespaces and iptables and opening the door for higher performance by keeping packets in OVS for longer. I want to share a few questions in order to gather feedback from you. I understand parts of these questions may have been answered in the past before my involvement, but I believe it's still important to revisit and clarify them. This can impact how long it's going to take to complete the work and whether it can make it to stein-3. 1. Should OVS support also be added to the legacy router? And if so, would it make more sense to have a new variable (not ``agent_mode``) to specify what backend to use (OVS or kernel) instead of creating more combinations? 2. What is expected in terms of CI for this? Regarding testing, what should this first patch include apart from the unit tests? (since the l3_agent.ini needs to be configured differently). 3. What problems can be anticipated by having the same agent managing both kernel and OVS powered routers (depending on whether they were created as ``distributed``)? We are experimenting with different ways of decoupling RouterInfo (mainly as part of the L3 agent refactor patch) and haven't been able to find the right balance yet. On one end we have an agent that is still coupled with kernel-based RouterInfo, and on the other end we have an agent that either only accepts OVS-based RouterInfos or only kernel-based RouterInfos depending on the ``agent_mode``. We'd also appreciate reviews on the 2 patches [4][5]. The L3 refactor one should be able to pass Zuul after a recheck. [1] Spec: https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr [2] RFE: https://bugs.launchpad.net/neutron/+bug/1705536 [3] Gerrit topic: https://review.openstack.org/#/q/topic:dvr_bridge+(status:open+OR+status:me… [4] L3 agent refactor patch: https://review.openstack.org/#/c/528336/29 [5] dvr_bridge patch: https://review.openstack.org/#/c/472289/17 Thank you! Best regards, Igor D.C.

5 6

[openstack-dev] [Neutron] Propose Liu Yulong for Neutron core
by Miguel Lavalle 06 Feb '19

06 Feb '19

Hi Stackers, I want to nominate Liu Yulong (irc: liuyulong) as a member of the Neutron core team. Liu started contributing to Neutron back in Mitaka, fixing bugs in HA routers. Since then, he has specialized in L3 networking, developing a deep knowledge of DVR. More recently, he single handedly implemented QoS for floating IPs with this series of patches: https://review.openstack.org/#/q/topic:bp/floating-ip-rate-limit+(status:op…. He has also been very busy helping to improve the implementation of port forwardings and adding QoS to them. He also works for a large operator in China, which allows him to bring an important operational perspective from that part of the world to our project. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: https://www.stackalytics.com/?module=neutron-group. I will keep this nomination open for a week as customary. Best regards Miguel

7 7

[publiccloud] New Contributor Joining
by Sindisiwe Chuma 06 Feb '19

06 Feb '19

Hi All, I am Sindi, a new member. I am interested in participating in the Pubic Cloud Operators Working Group. Are there current projects or initiatives running and documentation available to familiarize myself with the work done and currently being done? Could you please refer me to resources containing information. Kind Regards, Sindi +27 72 572 7757

2 1

[ironic] [thirdparty-ci] BaremetalBasicOps test
by Michael Turek 05 Feb '19

05 Feb '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/

3 3

[infra][zuul]Run only my 3rd party CI on my environment
by Rikimaru Honjo 04 Feb '19

04 Feb '19

Hello, I have a question about Zuulv3. I'm preparing third party CI for openstack/masakari PJ. I'd like to run my CI by my Zuulv3 instance on my environment. In my understand, I should add my pipeline to the project of the following .zuul.yaml for my purpose. https://github.com/openstack/masakari/blob/master/.zuul.yaml But, as a result, my Zuulv3 instance also run existed pipelines(check & gate). I want to run only my pipeline on my environment. (And, existed piplines will be run on openstack-infra environment.) How can I make my Zuulv3 instance ignore other pipeline? Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@po.ntt-tx.co.jp

2 2

[nova] Per-instance serial number implementation question
by Matt Riedemann 01 Feb '19

01 Feb '19

The proposal from the spec for this feature was to add an image property (hw_unique_serial), flavor extra spec (hw:unique_serial) and new "unique" choice to the [libvirt]/sysinfo_serial config option. The image property and extra spec would be booleans but really only True values make sense and False would be more or less ignored. There were no plans to enforce strict checking of a boolean value, e.g. if the image property was True but the flavor extra spec was False, we would not raise an exception for incompatible values, we would just use OR logic and take the image property True value. The boolean usage proposed is a bit confusing, as can be seen from comments in the spec [1] and the proposed code change [2]. After thinking about this a bit, I'm now thinking maybe we should just use a single-value enum for the image property and flavor extra spec: image: hw_guest_serial=unique flavor: hw:guest_serial=unique If either are set, then we use a unique serial number for the guest. If neither are set, then the serial number is based on the host configuration as it is today. I think that's more clear usage, do others agree? Alex does. I can't think of any cases where users would want hw_unique_serial=False, so this removes that ability and confusion over whether or not to enforce mismatching booleans. [1] https://review.openstack.org/#/c/612531/2/specs/stein/approved/per-instance… [2] https://review.openstack.org/#/c/619953/7/nova/virt/libvirt/driver.py@4894 -- Thanks, Matt

9 19

[dev] How to develop changes in a series
by Eric Fried 01 Feb '19

01 Feb '19

This started off as a response to some questions Sundar asked, but I thought it might be interesting/useful for new[er] OpenStack developers at large, so broadcasting. I'm sure there's a document somewhere that covers this, but here's a quick run-down on how to develop multiple changes in a series. (Or at least, how I do it.) Start on a freshly-pull'd master branch: efried@efried-ThinkPad-W520:~/Neo/nova$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. efried@efried-ThinkPad-W520:~/Neo/nova$ git pull --all <snip> When you're working on a blueprint, you want to name your local branch after the blueprint. So in this case, bp/nova-cyborg-interaction. efried@efried-ThinkPad-W520:~/Neo/nova$ git checkout -b bp/nova-cyborg-interaction Switched to a new branch 'bp/nova-cyborg-interaction' efried@efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -1 --decorate 5bf6f63 (HEAD, origin/master, origin/HEAD, gerrit/master, master, bp/nova-cyborg-interaction) Merge "Deprecate the nova-xvpvncproxy service" When you `git commit` (without `--amend`), you're creating a new commit on top of whatever commit you started at. If you started with a clean, freshly pull'd master branch, that'll be whatever the most recently merged commit in the master branch was. In this example, that's commit 5bf6f63. So let's say I make an edit for my first patch and commit it: efried@efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient>=1.0' >> requirements.txt efried@efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient==1.1' >> lower-constraints.txt efried@efried-ThinkPad-W520:~/Neo/nova$ git commit -a -m "Add cyborg client to requirements" [bp/nova-cyborg-interaction 1b2c453] Add cyborg client to requirements 2 files changed, 2 insertions(+) efried@efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -2 --decorate 1b2c453 (HEAD, bp/nova-cyborg-interaction) Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" I just made commit 1b2c453 on top of 5bf6f63. You'll notice my branch name (bp/nova-cyborg-interaction) came along with me. Now I'm going to make another change, but just part of it, a work-in-progress commit: efried@efried-ThinkPad-W520:~/Neo/nova$ mkdir nova/pci/cyborg efried@efried-ThinkPad-W520:~/Neo/nova$ touch nova/pci/cyborg/__init__.py efried@efried-ThinkPad-W520:~/Neo/nova$ git add nova/pci/cyborg/__init__.py efried@efried-ThinkPad-W520:~/Neo/nova$ git commit -m "WIP: Cyborg PCI handling" [bp/nova-cyborg-interaction ebb3505] WIP: Cyborg PCI handling 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 nova/pci/cyborg/__init__.py efried@efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" Now commit ebb3505 is on top of 1b2c453, which is still on top of 5bf6f63 (the master). Note that my branch name came with me again. At this point, I push my series up to gerrit. Note that it makes me confirm that I really want to push two commits at once. efried@efried-ThinkPad-W520:~/Neo/nova$ git review You are about to submit multiple commits. This is expected if you are submitting a commit that is dependent on one or more in-review commits, or if you are submitting multiple self-contained but dependent changes. Otherwise you should consider squashing your changes into one commit before submitting (for indivisible changes) or submitting from separate branches (for independent changes). The outstanding commits are: ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements Do you really want to submit the above commits? Type 'yes' to confirm, other to cancel: yes remote: remote: Processing changes: new: 2, refs: 2 (\) remote: Processing changes: new: 2, refs: 2 (\) remote: Processing changes: new: 2, refs: 2 (\) remote: Processing changes: new: 2, refs: 2, done remote: remote: New Changes: remote: https://review.openstack.org/623026 Add cyborg client to requirements remote: https://review.openstack.org/623027 WIP: Cyborg PCI handling remote: To ssh://efried@review.openstack.org:29418/openstack/nova.git * [new branch] HEAD -> refs/publish/master/bp/nova-cyborg-interaction Now if you go to either of those links - e.g. https://review.openstack.org/#/c/623026/ - you'll see that the patches are stacked up in series on the top right. But oops, I made a mistake in my first commit. My lower constraint can't be higher than my minimum in requirements.txt. If I still had my branch locally, I could skip this next step, but as a matter of rigor to avoid some common pratfalls, I will pull the whole series afresh from gerrit by asking git review to grab the *top* change: efried@efried-ThinkPad-W520:~/Neo/nova$ git review -d 623027 Downloading refs/changes/27/623027/1 from gerrit Switched to branch "review/eric_fried/bp/nova-cyborg-interaction" Now I'm sitting on the top change (which you'll notice happens to be exactly the same as before I pushed it - again, meaning I could technically have just worked from where I was, but see above): efried@efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate ebb3505 (HEAD, review/eric_fried/bp/nova-cyborg-interaction, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" But I want to edit 1b2c453, while leaving ebb3505 properly stacked on top of it. Here I use a tool called `git restack` (run `pip install git-restack` to install it). efried@efried-ThinkPad-W520:~/Neo/nova$ git restack This pops me into an editor showing me all the commits between wherever I am and the main branch (now they're in top-first order): pick 1b2c453 Add cyborg client to requirements pick ebb3505 WIP: Cyborg PCI handling <snip> I want to fix the first one, so I change to: edit 1b2c453 Add cyborg client to requirements pick ebb3505 WIP: Cyborg PCI handling <snip> Save and quit the editor, and I see: Stopped at 1b2c453453242a3fa57f2d4fdc80c837b02b804f... Add cyborg client to requirements You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue I fix lower-constraints: efried@efried-ThinkPad-W520:~/Neo/nova$ sed -i 's/cyborgclient==1.1/cyborgclient==1.0/' lower-constraints.txt ...and *amend* the current commit efried@efried-ThinkPad-W520:~/Neo/nova$ git commit -a --amend --no-edit [detached HEAD 6b3455f] Add cyborg client to requirements Date: Wed Dec 5 09:43:15 2018 -0600 2 files changed, 2 insertions(+) ...and tell `git restack` to proceed efried@efried-ThinkPad-W520:~/Neo/nova$ git rebase --continue Successfully rebased and updated refs/heads/review/eric_fried/bp/nova-cyborg-interaction. If I had a taller series, and I had changed 'pick' to 'edit' for more than one commit, I would now be sitting on the next one I needed to edit. As it is, that was the only thing I needed to do, so I'm done and sitting on the top of my series again. 124b612 (HEAD, review/eric_fried/bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 6b3455f Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" Notice that the commit hashes have changed for *both* commits (but not the master). The top one changed because it got rebased onto the new version of the middle one. Now if I push the series back up to gerrit, I get the same confirmation prompt, and both changes get a new patch set. If you look at the top patch in gerrit, you'll see that PS2 shows up as just a rebase. ==================== That ought to be enough for now. There's a couple of gotchas when restacking and the automatic rebase results in merge conflicts, but we can save that for another time. To answer your specific question: > * If you have a patch sequence A followed by B, where patch B depends on patch A, > how do you communicate that in the submission? If they're in the same commit series, like the example above, It Just Happens. Zuul and the CIs know to pull the whole series when they run; gerrit won't merge N+1 until N is merged; etc. If they're *not* in the same commit series, or if they're not in the same repository, you can use Depends-On in the commit message, to the same effect. (But I'm not sure if/how Depends-On works for feature branches.) HTH, efried .

7 8

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

01 Feb '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 01 Feb '19

01 Feb '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 31 Jan '19

31 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 31 Jan '19

31 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 31 Jan '19

31 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 31 Jan '19

31 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 31 Jan '19

31 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 30 Jan '19

30 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 30 Jan '19

30 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