| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-06 | |||
| 15:38:43 | mriedem | sdague: thanks | |
| 15:50:40 | kashyap | If anyone got a moment, https://review.openstack.org/#/c/411936/ ("libvirt: avoid generating script with empty path") | |
| 15:52:10 | openstackgerrit | Ed Leafe proposed openstack/nova: Remove the Allocation.create() method. https://review.openstack.org/416751 | |
| 15:52:11 | openstackgerrit | Ed Leafe proposed openstack/nova: Add check for invalid allocation amounts https://review.openstack.org/416752 | |
| 15:55:25 | mriedem | kashyap: looking, have an upgrade question coming | |
| 15:55:42 | kashyap | mriedem: Sure, I assume you'll write on the review | |
| 15:55:47 | mriedem | yup | |
| 15:56:39 | kashyap | mdbooth: When you have time, your eyes are also appreciated (https://review.openstack.org/#/c/411936/) | |
| 15:57:03 | mriedem | kashyap: posted | |
| 15:58:47 | mriedem | kashyap: yeah see sgordon's comment in the bug https://bugs.launchpad.net/nova/+bug/1649527/comments/1 | |
| 15:58:47 | openstack | Launchpad bug 1649527 in OpenStack Compute (nova) "nova creates an invalid ethernet/bridge interface definition in virsh xml" [Undecided,In progress] - Assigned to Neil Jerram (neil-jerram) | |
| 15:59:15 | sahid | jamielennox|away: | |
| 15:59:26 | sahid | oops, sorry for that | |
| 15:59:34 | kashyap | mriedem: Yes, the upgrade question is a good one. | |
| 15:59:49 | kashyap | Will have to bring it up with upstream libvir list | |
| 16:00:26 | kashyap | mriedem: Thanks for the quick look. I'll post there once I learn more from the upstream folks. | |
| 16:00:48 | mriedem | kashyap: i guess the question would be how to recreate an upgrade issue where we hit that, i.e. create a vm via nova with libvirt 1.3.1, then upgrade libvirt to 2.0.0, and then try to do something with the vm (restart? stop/start?) | |
| 16:01:03 | mriedem | kashyap: if nova just blows the domain away and recreates it, then we probably don't care once we have the fix | |
| 16:01:10 | mriedem | it's just the xml parse part that i worry about | |
| 16:01:17 | sgordon | mriedem, it also has to be the specific networking solutions that use that specific vif path | |
| 16:01:39 | sgordon | mriedem, i think neil had identified that was midonet, vrouter, and one or two others | |
| 16:02:18 | mriedem | ok, either way the fix looks good, just thinking we should handle '' or None in the parse_dom | |
| 16:02:35 | mriedem | hard to say what else we can do w/o an upgrade recreate | |
| 16:02:57 | openstackgerrit | Balazs Gibizer proposed openstack/nova: handle uninited fields in notification payload https://review.openstack.org/415857 | |
| 16:04:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova: Transform missing delete notifications https://review.openstack.org/410297 | |
| 16:06:17 | kashyap | mriedem: Yeah, the upgrade scenario you outlined, with specific VIF path sounds correct. I haven't tested it myself, just noticed on the upstream thread. | |
| 16:06:27 | kashyap | Will see if I can test it early next week w/ an upgrade setup | |
| 16:06:50 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient: Fix "Message object do not support addition". https://review.openstack.org/414529 | |
| 16:34:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova: handle uninited fields in notification payload https://review.openstack.org/415857 | |
| 16:36:29 | mriedem | BobBall: can we get a run of tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces in the xenserver ci on patch https://review.openstack.org/#/c/365505/ ? | |
| 16:36:50 | mriedem | BobBall: nevermind https://review.openstack.org/#/c/416797/ | |
| 16:37:28 | BobBall | :) | |
| 16:37:44 | mriedem | that's a pretty slick way to test that stuff out | |
| 16:38:41 | BobBall | I guess other CIs have a fixed exclusion list in their jenkins job configuration? | |
| 16:38:53 | mriedem | not sure how others do it | |
| 16:39:56 | BobBall | Ah well. Did you also see that, now that the os-xenapi devstack plugin improvement is merged, the first os-xenapi change is passing the CI (that one has been a convoluted mess to get all the parts in the right order for every change to pass the CI in order...) | |
| 16:40:15 | mriedem | BobBall: nope, just saw it was still failing last night | |
| 16:40:30 | BobBall | Yeah - the change was merged this morning, so it's green now. | |
| 16:40:37 | mriedem | cool | |
| 16:40:48 | mriedem | will check that out later today | |
| 16:41:11 | mriedem | are you good with the hotplug patch? i'm just going over the changes from my previous review. | |
| 16:41:14 | BobBall | johnthetubaguy: ^^ Your input on https://review.openstack.org/#/c/406059/ would also be appreciated | |
| 16:41:53 | BobBall | Think so - let me double check. | |
| 16:44:05 | melwitt | mriedem: do you think we could backport this to newton to make running simple_cell_setup easier? https://review.openstack.org/#/c/409970/ | |
| 16:45:15 | mriedem | well, | |
| 16:45:27 | mriedem | melwitt: is the TODO in there ok for newton? | |
| 16:45:35 | mriedem | # TODO(melwitt): Remove this when the oslo.messaging function | |
| 16:45:35 | mriedem | # for assembling a transport url from ConfigOpts is available | |
| 16:46:06 | mriedem | i don't know which change that is referring to in oslo.messaging | |
| 16:48:51 | melwitt | mriedem: ah, right. that TODO is invalid but there were specific changes in oslo.messaging to make it use [DEFAULT]/transport_url, so need to see if those are part of newton | |
| 16:49:18 | mriedem | not only part of newton, but probably part of the minimum required version of oslo.messaging in newton | |
| 16:49:32 | mriedem | to ensure that it works with the minimum package dependencies | |
| 16:49:41 | melwitt | right | |
| 16:52:58 | openstackgerrit | Julian proposed openstack/nova: Transform keypair.create notification https://review.openstack.org/408689 | |
| 17:03:07 | mriedem | BobBall: oh so close https://review.openstack.org/#/c/365505/ | |
| 17:06:24 | openstackgerrit | Stephen Finucane proposed openstack/nova: Ignore IOError when creating 'console.log' https://review.openstack.org/392643 | |
| 17:07:23 | sfinucan | sahid, vladikr: Any chance ye could have a look at ^ when you have a chance? | |
| 17:07:47 | vladikr | sfinucan, sure | |
| 17:08:15 | BobBall | mriedem: I think we're OK - aren't all API calls here synchronized on the VM object? | |
| 17:08:23 | BobBall | Let me find that... | |
| 17:08:26 | mriedem | BobBall: nope | |
| 17:08:35 | BobBall | I thought they were in the XenAPI driver | |
| 17:08:51 | mriedem | oh, well that might be news to me | |
| 17:09:06 | BobBall | Nope, it's not | |
| 17:09:16 | BobBall | I was sure they were at one point :D | |
| 17:09:55 | BobBall | Easy enough to add a utils.synchronized to the plug method though? | |
| 17:10:19 | mriedem | yeah | |
| 17:10:28 | mriedem | although | |
| 17:10:34 | mriedem | attach interface is an rpc call | |
| 17:10:48 | mriedem | but i guess if you lock on the instance then that should be ok | |
| 17:11:03 | BobBall | yeah - I meant on the instance. | |
| 17:11:07 | mriedem | hopefully 2 plugs for the same instance at the same time could complete in under 60 seconds | |
| 17:11:13 | leakypipes | dansmith: mind taking a look at https://review.openstack.org/#/c/413068/3/oslo_versionedobjects/base.py? I have a suspicion that doing that is not intended... | |
| 17:11:27 | BobBall | The synchronization I was thinking of is already there for VBD plug / unplug | |
| 17:11:35 | BobBall | oh yes, for sure. | |
| 17:12:24 | BobBall | Could probably just synchronize the creation (not hotplug) - once we have the record in the XenServer DB it will not announce that as an allowed device | |
| 17:12:43 | dansmith | leakypipes: yep, you're right | |
| 17:13:03 | leakypipes | phew. | |
| 17:15:54 | openstackgerrit | Matt Riedemann proposed openstack/nova: Fix TypeError in _update_from_compute_node race https://review.openstack.org/416822 | |
| 17:20:54 | dansmith | mriedem: what do I do for this? use |
|
| 17:22:42 | dansmith | or %(int)s I guess | |
| 17:24:21 | dansmith | hmm, nope | |
| 17:24:40 | leakypipes | dansmith: couldn't you just do: \d+ | |
| 17:24:59 | dansmith | leakypipes: yes, but just trying to figure out how to use the integrated one he suggested | |
| 17:24:59 | leakypipes | BTW, is superdan in hiding? ;) | |
| 17:25:10 | dansmith | oh jeez is it friday? | |
| 17:25:14 | leakypipes | sure is! | |
| 17:25:16 | leakypipes | :) | |
| 17:25:19 | leakypipes | there he is! | |
| 17:25:29 | leakypipes | to save the day. | |
| 17:25:38 | sean-k-mooney | leakypipes: hi jay would you have time to review sfinucan mtu patch to os-vif https://review.openstack.org/#/c/408779 | |
| 17:25:40 | bauzas | superdan: leakypipes: mriedem: folks, I have an important question for you | |
| 17:25:48 | bauzas | oh man, my manners | |
| 17:25:55 | leakypipes | sean-k-mooney: yup, will do. thx for the heads up. | |
| 17:26:37 | leakypipes | superdan: yeah, looks like %(int)s is correct there. | |
| 17:26:45 | bauwser | superdan: leakypipes: mriedem: so, since I wanted to write the scheduler-side of the placement call for getting the list of RPs, I thought about the fact we wrote the methods within the client.report module | |
| 17:26:53 | superdan | leakypipes: doesn't work | |
| 17:27:22 | bauwser | superdan: leakypipes: mriedem: that's why I began to cut that from the module and rather create a new module with a PlacementClient | |
| 17:27:38 | leakypipes | sdague: perhaps you might know the answer to superdan's dilemma? | |
| 17:27:50 | bauwser | superdan: leakypipes: mriedem: but given it will need some tests modifications, that change will be huge to review | |