| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 16:20:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 16:26:45 | openstackgerrit | Merged openstack/nova master: Fix the file name of development-environment.rst https://review.openstack.org/573096 | |
| 16:33:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678 | |
| 16:33:51 | openstackgerrit | Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958 | |
| 16:33:52 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405 | |
| 16:33:53 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 16:33:54 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 16:35:21 | mriedem | so, does anyone know if lyarwood has been hit by a mini bus because today is spec freeze day and i've got a +2 on https://review.openstack.org/#/c/552078/ and a -1 from lee but i don't think i need to make any changes | |
| 16:35:33 | dansmith | mriedem: he's sick | |
| 16:35:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 16:35:56 | mriedem | ok | |
| 16:36:20 | mriedem | so, any other core care to take a look at that? we agreed on it in dublin and it came up again in vancouver | |
| 16:37:28 | dansmith | I mean, yeah we could approve with expected addendum if needed, or just trivially excuse it for a few days for clairifcation | |
| 16:37:32 | dansmith | whichever | |
| 16:38:27 | mriedem | tbc, i suspect there are some bugs in how cinder manages read only volumes/attachments, | |
| 16:38:36 | mriedem | but those are dependencies, not really blockers on the general idea | |
| 16:40:46 | openstackgerrit | Merged openstack/nova-specs master: Add additional information for z/VM spec. https://review.openstack.org/562154 | |
| 16:40:47 | openstackgerrit | Merged openstack/nova-specs master: Amend allow abort live migrations in queued status spec https://review.openstack.org/560872 | |
| 16:45:00 | dansmith | mriedem: aight, well, I don't really have any complaints about it, having skimmed | |
| 16:45:20 | dansmith | mriedem: I guess you just prefer to have it merged and resolve any issues lee may have later yeah? | |
| 16:45:25 | dansmith | I guess I don't really care either way | |
| 16:46:06 | openstackgerrit | Doug Hellmann proposed openstack/python-novaclient master: fix tox python3 overrides https://review.openstack.org/573347 | |
| 16:57:07 | mriedem | dansmith: yeah | |
| 16:57:21 | mriedem | but i looked into lee's comments and don't consider them blocking, unless i'm missing something | |
| 16:57:31 | dansmith | yeah | |
| 17:03:15 | mriedem | low hanging fruit opportunity https://bugs.launchpad.net/nova/+bug/1775665 | |
| 17:03:16 | openstack | Launchpad bug 1775665 in OpenStack Compute (nova) "api-ref: rebuild server does not mention pre-conditions" [Low,Confirmed] | |
| 17:16:15 | openstackgerrit | Merged openstack/nova-specs master: Spec for volume multiattach enhancements https://review.openstack.org/552078 | |
| 17:37:23 | mriedem | melwitt: i'm going to go through some very obvious things targeted against rocky and defer them out https://blueprints.launchpad.net/nova/rocky | |
| 17:37:29 | mriedem | stuff that doesn't have an owner, etc | |
| 17:38:01 | melwitt | mriedem: okay, sounds good. thanks for doing that | |
| 17:47:00 | karimull | Looking for a review on https://review.openstack.org/#/c/565620/ from a core member | |
| 17:48:29 | mriedem | jroll: ^? | |
| 17:50:10 | jroll | mriedem: looks fine | |
| 17:50:29 | jroll | pretty straightforward :) | |
| 17:57:33 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805 | |
| 17:58:50 | mriedem | dansmith: +2 on this pretty simple spec about using rbd for getting images from local storage even when you're not running the rbd image backend https://review.openstack.org/#/c/572805/ | |
| 17:59:06 | mriedem | related to that thread in the ML about the image handler download extension point deprecation | |
| 17:59:23 | mriedem | i have a feeling CERN has also said they wanted something like this for windows images | |
| 18:05:19 | dansmith | hmm | |
| 18:05:23 | dansmith | I didn't realize we still had that | |
| 18:05:25 | dansmith | it's hidden in __init__ | |
| 18:05:58 | melwitt | mriedem: thanks for following that btw, I had meant to ask mnaser to chime in about it too because I thought maybe it was something he also needs | |
| 18:08:14 | mriedem | i felt compelled since i deprecated it and sent out the call for input in the ML | |
| 18:08:22 | melwitt | :) | |
| 18:08:22 | mriedem | and actually caught a bite | |
| 18:10:44 | dansmith | we don't have to undeprecate the modules thing for this, | |
| 18:11:05 | dansmith | we can just convert it to a be_smart=True sort of flag I think | |
| 18:11:50 | dansmith | approving this makes me worried that someone that understands the image cache is going to show up and cry foul, | |
| 18:12:09 | dansmith | and it's not very helpful to look at a havana implementation | |
| 18:13:04 | dansmith | I also feel like there are things in that spec you would call out as needing more detail if it wasn't spec deadline day and you weren't flustered by getting a bite on the mailing list | |
| 18:14:27 | dansmith | obviously the idea seems sane | |
| 18:17:26 | mriedem | there are things i thought about like, how would one disable this if they wanted, but i expect that's just (1) if you're using rbd and you want it for both ephemeral and persistent disks, you use images_type=rbd, and (2) if you want ceph for volumes and qcow2 for local, then you don't configure the libvirt ceph stuff for local | |
| 18:17:34 | mriedem | so that doesn't seem like a problem | |
| 18:17:57 | mriedem | otherwise as i said in the review, devil is in the details when the patch shows up, but otherwise yeah spec deadline and such | |
| 18:18:13 | dansmith | I just don't have all that image cache plumbing in my head to know if it's legit to do it like this or not | |
| 18:18:20 | mriedem | i could very obviously be missing stuff and sort of kind of feel bad about this, so if there are issues you see then please don't hold back | |
| 18:18:26 | dansmith | just would feel better if someone else that kinda understands that had even looked at it I guess | |
| 18:18:31 | mriedem | mdbooth | |
| 18:18:33 | mriedem | to the rescue | |
| 18:19:38 | mriedem | also, my house is unfortunately now overrun with children since the school system decided it won't hold school year round, and i must evacuate to a coffee shop, so bbiab | |
| 18:20:21 | dansmith | melwitt: do you know more about this process and/or feel like due diligence has been done on this elsewhere? | |
| 18:21:09 | dansmith | once it is approved, it's candidate for a runway and subsequent auto-approval next cycle. the spec has been up for <24 hours and the ML post didn't get much discussion at all | |
| 18:21:21 | melwitt | dansmith: no, I don't have that much knowledge about what the extension point is providing | |
| 18:21:37 | dansmith | as long as the opt stays deprecated and not removed we're not screwing this guy over (yet) | |
| 18:22:03 | melwitt | that is, I don't want us to lose the functionality but I don't know what the right way to provide it is | |
| 18:22:04 | dansmith | and/or we could just give it a spec exception until next week in hopes that we could get a quick read from anyone who knows anything about this to trivially thumb it up or something | |
| 18:22:19 | dansmith | the spec is about adding a feature, | |
| 18:22:24 | dansmith | it's not about the extension point itself | |
| 18:22:40 | dansmith | the guy is offering to upstream his thing so that we could remove the extension point basically | |
| 18:22:48 | dansmith | but I dunno if his thing is a total hack or not | |
| 18:22:53 | melwitt | but it's about adding a feature that provides the same functionality that the deprecated extension point is currently taking care of? | |
| 18:22:57 | dansmith | no | |
| 18:23:06 | dansmith | it uses the extension point to add the feature out of tree currently | |
| 18:23:27 | dansmith | it's coming up because if the extension point goes away, he can't sideload his extra thing | |
| 18:23:48 | dansmith | the confusion may be that he asserted that bringing it into tree means we keep the extension point, but that's not really a thing | |
| 18:25:27 | melwitt | hm, okay. yeah, I would be okay with a freeze exception to review this since it showed up only yesterday and if it's an important operator issue | |
| 18:26:06 | dansmith | I'm not sure it is an important operator issue, because the thread on the ML was a week ago and nobody has really jumped on it | |
| 18:26:12 | melwitt | I just haven't connected the dots between it and the ML post, I had assumed it was proposed in reaction to the deprecation of the extension point and as a way to keep the fast download behavior | |
| 18:26:24 | dansmith | we don't have the fast download behavior now | |
| 18:26:30 | dansmith | this guy hacks it in with an out of tree extension, | |
| 18:26:34 | dansmith | which uses this extension point | |
| 18:26:43 | dansmith | he wants to upstream it so he can keep the functionality after we remove the extension point | |
| 18:26:47 | melwitt | oh, I see | |
| 18:26:53 | dansmith | which is awesome and stuff, | |
| 18:27:22 | dansmith | I just don't know if what he's describing that he's doing is a gross hack or legit, because Idon't know the image cache maze of caves very wekk | |
| 18:27:23 | dansmith | *well | |
| 18:27:33 | melwitt | yeah, gotcha | |
| 18:29:33 | melwitt | yeah, I dunno. that's a tough one, bad timing. mdbooth might be able to look at it tomorrow | |
| 18:29:51 | dansmith | the spec also kinda describes this as just bringing his extension into tree, which will still use the extension point, which is not what I think we should do | |
| 18:30:01 | dansmith | which is also why I think this needs another go-round at least :) | |
| 18:30:03 | dansmith | yeah | |
| 18:37:24 | melwitt | the concept makes a lot of sense, similar to the ceph fast clone stuff we have, I just don't yet understand why the extension point is needed to grab the image if we didn't need it for fast clone | |
| 18:39:49 | melwitt | I think the feature is definitely legit but the implementation details are the potential snag, but I think everyone said that already | |
| 18:44:37 | mriedem | dansmith: melwitt: i'm happy to sit on that until mdbooth can look it over, i'll drop the +2 | |
| 18:46:08 | mriedem | sounds like, if image isn't in cache, and images_type!=rbd but CONF.libvirt.rbd_user is configured, then look for the image in ceph, else download | |
| 18:46:38 | mriedem | which is presumably how this works today with the extension download handler | |
| 18:47:06 | melwitt | yeah, agreed sounds like it would be something like that | |
| 18:48:59 | melwitt | the only catch might be that you have to get it from the glance ceph pool. I don't think that's the case for the fast clone snapshot | |
| 18:49:41 | melwitt | but I guess it must be ... thinking about the glance direct urls | |