| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 16:04:23 | bauzas | let's just assume that this field will only contain the 'requested_networks', and if someone wants to use this field for anything other than rebuild from cell0, then we could rathole on it later | |
| 16:04:57 | johnthetubaguy | bauzas: I just added this note: https://review.openstack.org/#/c/554218/4/specs/rocky/approved/enable-rebuild-for-instances-in-cell0.rst@112 | |
| 16:04:59 | gibi | bauzas: OK, I rest my case. We can add big fat comment on the field and handle the issue latear | |
| 16:04:59 | bauzas | gibi: people could even create a new field called 'actual_networks' in opposition to 'requested_networks' :) | |
| 16:05:13 | gibi | bauzas: :) | |
| 16:05:38 | bauzas | gibi: but again, take the 'requested_destination' field | |
| 16:05:54 | johnthetubaguy | gibi: I am +1 a big fat comment to warn about it, can't think of a better way to help that right now | |
| 16:06:08 | bauzas | or the 'availability_zone' field rather | |
| 16:06:28 | bauzas | req_spec.availability_zone doesn't get you the *actual* AZ | |
| 16:06:40 | bauzas | it gets you the AZ the user asked | |
| 16:06:53 | johnthetubaguy | that matches to port_ids pefectly actually | |
| 16:07:07 | johnthetubaguy | you request "give me a network" you get port uuid 9028734087238947 | |
| 16:07:26 | gibi | OK, I think I see the difference | |
| 16:09:13 | gibi | so my endeavour to add the bandwidth resource request from the port to the RequestSpec is yet another bump on the road, as the user asked for a port in the boot request and not for bandwidth | |
| 16:10:20 | gibi | but eventually he will get bandwidth | |
| 16:11:17 | gibi | maybe the bandwidth request (and actually all implicit resource request) should live in a totally separate object outside of the RequestSpec | |
| 16:16:22 | mriedem | melwitt: given https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata i think we're ok, nothing else is ready | |
| 16:17:17 | melwitt | mriedem: ack, just making double sure there was nothing yet-to-be-proposed bugs coming down the pipe. since this release has been up longer than intended | |
| 16:17:19 | melwitt | thanks | |
| 16:17:31 | mriedem | melwitt: i think your hash in the release patch is wrong though | |
| 16:17:38 | johnthetubaguy | gibi: bandwidth we get from the port details? | |
| 16:17:57 | mriedem | johnthetubaguy: https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.html | |
| 16:17:59 | gibi | johnthetubaguy: yes, there will be a new resource_request field in the port | |
| 16:18:00 | mriedem | enjoy! | |
| 16:18:29 | gibi | johnthetubaguy: https://review.openstack.org/#/c/567268/13/nova/tests/fixtures.py@1153 this is how it will look like | |
| 16:18:33 | johnthetubaguy | gibi: yeah, its so why we want to create the ports before calling placement, sigh. | |
| 16:18:52 | melwitt | mriedem: really? did you think I should use the merge hash? | |
| 16:19:25 | gibi | johnthetubaguy: yes, the is another reason to eventually move the port creation to the conductor | |
| 16:19:41 | mriedem | melwitt: i have always used the head commit on the branch | |
| 16:19:42 | gibi | johnthetubaguy: s/the/this/ | |
| 16:19:43 | mriedem | merge or not | |
| 16:19:58 | mriedem | which is always what we'd use for tagging | |
| 16:20:24 | melwitt | mriedem: okay, I keep getting confused about that. I'll change it | |
| 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 | |