| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-09 | |||
| 10:45:59 | andreas_s | yeah, nova-compute needs this config in definitively! | |
| 10:47:52 | stephenfin | andreas_s: I'd file a bug, personally. I'll take a look at it after lunch and see if we can come up with something | |
| 10:49:01 | jmccarthy | mriedem: Thanks for the update on https://review.openstack.org/#/c/566367 ! I tested this out, and patchest2 worked great for me | |
| 10:49:38 | andreas_s | stephenfin: that would be great. thanks. Can you subscribe me to this bug once opened (andreas scheuring)? thx. If you need any more input, let know... | |
| 10:50:24 | stephenfin | andreas_s: "I would file a bug, personally", e.g. I suggest _you_ file a bug :) | |
| 10:50:33 | stephenfin | I could do it, but you probably have the most context | |
| 10:50:36 | stephenfin | and logs | |
| 10:50:41 | andreas_s | ok, will do | |
| 10:50:57 | andreas_s | stephenfin: just was not sure how to interpret "I would" ;) | |
| 10:51:13 | stephenfin | That's an Irish'ism. Sorry :) | |
| 10:51:55 | andreas_s | hehe, enjoy your lunch! | |
| 10:53:58 | openstackgerrit | Merged openstack/nova master: Remove [scheduler]/host_manager config option https://review.openstack.org/565806 | |
| 11:02:53 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Deprecate support for monitoring Intel CMT `perf` events https://review.openstack.org/565242 | |
| 11:04:38 | openstackgerrit | Rajat Sharma proposed openstack/nova master: Imposing restrictions on resource providers create uuid https://review.openstack.org/567191 | |
| 11:06:18 | andreas_s | stephenfin, melwitt: opened the bug against devstack: https://bugs.launchpad.net/devstack/+bug/1770143 | |
| 11:06:18 | openstack | Launchpad bug 1770143 in devstack "Nova Console setup broken" [Undecided,New] | |
| 11:11:05 | ShilpaSD | dansmith: hi | |
| 11:29:25 | openstackgerrit | Naichuan Sun proposed openstack/nova master: XenAPI: deprecate the config for image handler class path https://review.openstack.org/497201 | |
| 12:09:29 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 12:09:30 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 12:09:31 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857 | |
| 12:10:03 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067 | |
| 12:19:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Followup for multiple member_of qparams support https://review.openstack.org/567209 | |
| 12:30:39 | openstackgerrit | Radoslav Gerganov proposed openstack/nova stable/queens: Handle PortNotFoundClient exception when getting ports https://review.openstack.org/567211 | |
| 12:41:34 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148 | |
| 13:01:15 | mdbooth | efried: Morning! https://review.openstack.org/#/c/564017/ | |
| 13:01:51 | mdbooth | That's causing me a problem, and I considering proposing a revert. However, I think it only exists due to bad naming. | |
| 13:02:15 | efried | mdbooth: stand by. | |
| 13:02:30 | efried | mdbooth: Okay, do tell. | |
| 13:02:47 | mdbooth | efried: I see you proposed it because of the loop in the ironic driver | |
| 13:03:13 | efried | mdbooth: Well, actually because of [2] (in the commit message), but [1] was a good excuse. | |
| 13:03:25 | mdbooth | efried: Sec, lemme check 2 | |
| 13:03:26 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 13:03:50 | efried | mdbooth: TL;DR, we were checking for volume-ness in a different (and apparently wrong | |
| 13:03:55 | efried | ) way in the powervm driver. | |
| 13:04:15 | mdbooth | efried: Thing is, the ironic driver doesn't need that check | |
| 13:04:16 | efried | mdbooth: mriedem pointed out that we should be using is_volume... which led us to find out that it didn't exist. | |
| 13:04:38 | efried | mdbooth: Well, is the new version of the check doing something the old one wasn't? | |
| 13:04:47 | mdbooth | Because, confusingly, block_device_info_get_mapping() should actually be called block_device_info_get_volumes() | |
| 13:04:55 | efried | mdbooth: I.e. did we break something afresh, or just leave something that (we didn't know) was broken before? | |
| 13:05:11 | mdbooth | If it was called *_get_volumes(), it would be obvious that an is_volume call was redundant subsequently | |
| 13:05:39 | jaypipes | stephenfin: yes, sorry, I understand the differences between gre, vlan, vxlan, local, etc. what I'm wondering about is why you used the term "mechanism". Is that because of the use of "mechanism driver" to describe the implementation module that Neutron uses under the hood for constructing a particular network? | |
| 13:06:10 | mdbooth | Where's _vol_drv_iter() called in your patch? | |
| 13:06:21 | stephenfin | jaypipes: I think I saw it used in documentation somewhere and couldn't think of a better term :) | |
| 13:07:41 | mdbooth | efried: Where I'm going with that is... are you sure they aren't all volumes anyway? And if they're not, why not just get the volumes in the first place? | |
| 13:08:35 | jaypipes | stephenfin: the reason I asked is because neither of those pages mentions the term "mechanism", and it seems to me (I may very well be wrong) that you are conflating two things (segmentation protocol and whether overlapping IP address ranges can occur on the network) | |
| 13:09:12 | mdbooth | efried: Ah, yes. You're doing the same thing. | |
| 13:09:18 | mdbooth | efried: So, they're all volumes. | |
| 13:09:28 | efried | mdbooth: So let's back up just for a sec. | |
| 13:09:45 | mdbooth | Have a look in driver.get_block_device_info(), which is what generates that data | |
| 13:09:49 | mdbooth | See: | |
| 13:09:55 | mdbooth | 'block_device_mapping': | |
| 13:09:56 | mdbooth | virt_block_device.convert_all_volumes(*block_device_mapping) | |
| 13:09:58 | efried | mdbooth: 1) Is there actually a problem here, or just some redundancy? and 2) was anything actually broken (or changed at all) by the patch you referenced? | |
| 13:10:19 | mdbooth | 'block_device_mapping' should really be called 'volumes' | |
| 13:10:57 | stephenfin | jaypipes: Hmm, protocol would probably have done. I definitely saw 'mechanism' used somewhere but of course I can't find where now | |
| 13:11:08 | mdbooth | Well, the change is redundant, but due to bad naming that's not at all obvious. | |
| 13:11:11 | efried | mdbooth: It is my understanding that there is quite a lot of horribleness in the bdm code that could be improved upon. | |
| 13:11:18 | jaypipes | stephenfin: no worries, it's not a huge deal really. | |
| 13:11:41 | mdbooth | The issue is that you added is_volume, which is a property, to the inherited list | |
| 13:11:46 | efried | mdbooth: The change itself is (was intended to be) a no-op. It was only supposed to get rid of the need to ask that @property through a private member of the outer bdm. | |
| 13:12:01 | stephenfin | jaypipes: I don't think I'm conflating those things. The main difference is whether it's an L2 network (uses physnets) or L3 network (uses a tunnel endpoint). tbh, the whole section on tenant networks and provider networks could be dropped | |
| 13:12:09 | mdbooth | So it breaks when something attempts to write to it | |
| 13:12:25 | efried | mdbooth: Write to what, .is_volume ? | |
| 13:12:29 | mdbooth | Yeah | |
| 13:12:34 | stephenfin | I'll probably do that as a follow-up. At this point I just want to get the spec in so I can grab a runway :) | |
| 13:12:37 | efried | mdbooth: Who was doing that, and where? | |
| 13:12:44 | efried | and why? | |
| 13:13:07 | efried | and based on what source info, if not _bdm_obj.is_volume itself? | |
| 13:13:18 | efried | mdbooth: sounds like we need a fup to remove... whatever that was. | |
| 13:13:26 | efried | mriedem: see email | |
| 13:13:34 | mdbooth | efried: Let me reload that context, but it broke my patch https://review.openstack.org/#/c/528362/ | |
| 13:13:57 | mdbooth | efried: I believe the issue is due to something iterating over properties to initialise the object | |
| 13:14:02 | mdbooth | Let me just remind myself... | |
| 13:14:10 | mriedem | nothing like an immediate pounce | |
| 13:14:23 | efried | mriedem: No hurry, just responding to your question about the granular bp | |
| 13:14:37 | efried | I suppose I didn't need to pounce for that. Sorry. | |
| 13:14:55 | ShilpaSD | stephenfin: Hi | |
| 13:14:59 | efried | mdbooth: Okay, so it kicked your patch out of the gate, didn't like melt CERNs supercollider, that's a relief anyway. | |
| 13:15:23 | mdbooth | efried: My patch is more important than somebody's magnet set. | |
| 13:15:29 | efried | clearly | |
| 13:17:59 | jaypipes | stephenfin: understood. | |
| 13:25:06 | mdbooth | efried: Ok, so I think I can unpick this from my end. | |
| 13:25:23 | mdbooth | efried: However, the point about is_volume being redundant in that context still stands | |
| 13:25:43 | efried | mdbooth: Okay. From what I've been able to tell so far, it's not clear that we should be setting things on _bdm_obj rather than on the outer object itself. | |
| 13:25:47 | mdbooth | Which, as I say, would be obvious if we called 'block_device_mappings' 'volumes' | |
| 13:26:18 | mriedem | lyarwood: can you poke this regression fix for queens? https://review.openstack.org/#/c/564461/ we're going to do a release soon for another regression fix | |
| 13:26:19 | efried | mdbooth: I'll be on the lookout for that review :) | |
| 13:26:32 | mriedem | this one https://review.openstack.org/#/q/If9e1581db9c1ae14340b787d03c815d243d5a50c | |
| 13:26:54 | mdbooth | efried: Meh, I can't be arsed renaming things I'm not actively hitting. It's painful and nobody cares. | |
| 13:27:09 | lyarwood | mriedem: yeah np, looking now | |
| 13:27:33 | efried | mdbooth: Just so. Also, that's a slippery slope, as I mentioned before. Once we start "fixing" the block device code, there'll be no stopping. | |
| 13:28:55 | jmccarthy | mriedem: Morning ! I checked this out and it worked out great https://review.openstack.org/#/c/566367 ! | |
| 13:32:42 | openstackgerrit | Jay Pipes proposed openstack/nova master: add consumer.generation/create missing consumers https://review.openstack.org/557958 | |
| 13:32:43 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: add Project, User and Consumer objects https://review.openstack.org/565403 | |
| 13:32:44 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add create() methods to Project, User and Consumer https://review.openstack.org/565404 | |
| 13:32:45 | openstackgerrit | Jay Pipes proposed openstack/nova master: move consumer ensure to API layer https://review.openstack.org/565405 | |
| 13:32:47 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 13:32:47 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 13:33:10 | mdbooth | efried: Added a comment to the PowerVM patch. Not really worth a -1, tbh, but I figure somebody's going to have to touch it anyway. | |