| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 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 | |
| 18:49:43 | dansmith | agreed that it sounds like the right thing to do, I just am unsure on the mechanics | |
| 18:49:50 | dansmith | if we can wait for mdbooth to look, I'd feel a lot better | |
| 18:50:11 | melwitt | yeah, that's fair enough | |
| 18:55:01 | mnaser | melwitt, mriedem: that spec is nice but it doesn't figure out our issue because we have 2 ceph clusters | |
| 18:55:29 | mnaser | for me the value would be if the image cache would use rbd instead of local storage | |
| 18:55:45 | mnaser | so we download the image once and then it remains cached inside the cluster | |
| 18:56:20 | mnaser | which is a problem i'm about to run into next week that i haven't fully thought out what/how i go about this :( | |
| 18:56:22 | mriedem | so maybe that's an alternative for the spec | |
| 18:56:26 | mriedem | make image cache ceph aware | |
| 18:56:53 | mriedem | mnaser: there are nova guidance counselors here to help :) | |
| 18:57:08 | mnaser | image cache and backend are decoupled.. or not? | |
| 18:58:13 | mnaser | mriedem: https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Project_Teams i'm signed up ha | |
| 18:58:30 | mnaser | so if they are decoupled, that would solve that problem for that use case in that spec | |
| 18:58:36 | mriedem | ha | |
| 18:58:39 | mnaser | it would involve an extra import/export | |
| 18:58:58 | mnaser | because you'd be exporting it from glance once slowly and importing it to ceph, storing it potentially twice if its the same cluster | |
| 18:59:33 | mnaser | in my case i'd be storing it twice but in different clusters | |