Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-23
13:21:34 mriedem but the unshelve to a new az thing is a new feature so wouldn't be backported (and isn't merged yet anyway)
13:22:10 cdent mriedem: thanks. the deleting the az bug isn't an immediate concern
13:22:43 efried bauzas: If you're in a spec approving mood, would you mind hitting https://review.opendev.org/#/c/608696/ (nova part of image encryption) as well please?
13:23:31 mriedem cdent: ok, looks like it only went back to rocky anyway https://review.opendev.org/#/q/Ic27195e46502067c87ee9c71a811a3ca3f610b73
13:25:57 bauzas efried: opening another tab
13:26:03 efried melwitt, lyarwood, mdbooth_: Could we get a comeback on https://review.opendev.org/#/c/658903/ (RBD image up/download spec) please?
13:28:32 openstackgerrit Merged openstack/nova master: Update AZ admin doc to mention the new way to specify hosts https://review.opendev.org/666767
13:29:44 efried stephenfin: gibi is +2 on https://review.opendev.org/#/c/641670/ (unaddressed port spec) -- looks like you're the man to send it?
13:30:05 efried jangutter: sean-k-mooney1: are you happy with ^ at this point?
13:31:33 jangutter efried: no objections from me. I'm pretty sure any security concerns can be sorted during implementation.
13:31:46 stephenfin efried: Yup, I'll get to that before EOD
13:31:49 efried donkey jangutter
13:31:56 efried thanks stephenfin
13:32:15 jangutter buy a donkey you too efried
13:35:51 mriedem cdent: just fyi https://review.opendev.org/#/q/I9f73c237923fdcbf4096edc5aedd2c968d4b893e was backported which updates the instance az during live migration but that still doesn't update the request spec az, which is the key thing since that's what will be used when you run the server through the scheduler to move it later (if not forced)
13:36:06 mriedem and if the request spec az is referencing something that's gone, and the az filter is enabled, the scheduler will novalidhost the move
13:36:06 cdent thanks mriedem
13:36:20 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'nova.virt.driver.ComputeDriver.estimate_instance_overhead' https://review.opendev.org/672106
13:36:40 mriedem so, recovery is likely: (1) force live migrate the server to some new host in a new az and then (2) manuall update the request spec az for the instance in the api db
13:36:49 mriedem note the request spec is a json blob in the db as well...so that's fun
13:37:25 mriedem i've got to run to an appointment, will be back on in a bit
13:45:46 openstackgerrit Merged openstack/nova-specs master: Add spec for expose-auto-converge-post-copy https://review.opendev.org/651681
13:46:38 openstackgerrit Merged openstack/nova-specs master: Boot a VM with an unaddressed port https://review.opendev.org/641670
13:48:03 efried stephenfin: If you agree https://review.opendev.org/#/c/672077/3/README.rst needs to be changed, I can fix it real quick and we can tag-team it?
13:48:28 efried uh, actually, I'm not sure what that should be changed to tbh
13:48:33 stephenfin efried: Drop it
13:48:38 stephenfin and yes
13:48:56 dansmith stephenfin: yeah you can't do that because it'll break rpc
13:49:29 dansmith stephenfin: but no, compute node won't auto serialize that to json, you have to make it do that
13:50:08 stephenfin Oh yeah. Duh
13:50:11 stephenfin Proxy field it is
13:50:29 stephenfin Also, what's horrible about bumping a major version again?
13:50:36 stephenfin *major object version
13:50:51 stephenfin I recall we bumped the Instance object and said never again, but I don't know why never again
13:51:20 dansmith stephenfin: it's not too terrible, but it is a little complicated. instance was the most complicated object, but I don't think we said never again,
13:51:28 dansmith it's just that it needs to be worth it
13:51:59 efried (stephenfin nm, there's no replacement for the landing page yet, I +Wed)
13:52:21 dansmith stephenfin: compute node would probably be much less annoying because of how limited its use is.. i.e. we don't send compute node objects all around to every node like we do instance,
13:52:33 dansmith it's mostly just the compute and conductor that have to touch them
13:52:56 stephenfin Yeah, that's the one I'm most interested in
13:53:16 stephenfin I think I'll wait til os-hypervisors is talking to placement instead of consuming the xxx_usage fields from ComputeNode first though
13:53:22 stephenfin So we can remove those while we're at it
13:53:35 stephenfin (Assuming that ends up being possible)
13:53:44 dansmith the point being to objectify that field, right? why is that a thing now vs. before? Because you're adding stuff to that field or something?
13:53:56 dansmith stephenfin: that sounds like a good idea
13:54:24 dansmith an object change for one field type is less good, but deprecating unused fields with that change is more meaty
13:55:04 stephenfin dansmith: Mostly because it wasn't initially obvious and led to me being bitten by it
13:55:23 stephenfin I am tackling it at in a more piecemeal fashion with https://review.opendev.org/#/c/671799/3 and the two preceding patches though
13:55:48 stephenfin moving the calls to convert the string to an object (and vice versa) close to where the field is actually read/set
13:55:59 stephenfin tl;dr: hardware.py is nasty
14:05:19 dansmith stephenfin: I don't want to nitpick your reno to death, but I do think it's important to note that the change it is describing happened quite a while ago, instead of implying that as of train, something is different
14:05:37 dansmith also happy to edit it myself if you want
14:05:44 stephenfin wrt to which patch now?
14:05:50 stephenfin Sure, suits me :)
14:06:02 stephenfin Assume you mean https://review.opendev.org/#/c/672065/ ?
14:06:09 dansmith yeah
14:06:56 stephenfin Yeah, go for it. Think mriedem made a similar comment when it was part of the claims patch
14:08:09 dansmith yeah, that feedback didn't seem to make the jump, but it's hard to tell because I can't diff revs now
14:08:46 stephenfin I changed 'is now' to 'is' and changed the wording of the libvirt section
14:08:55 dansmith heh
14:09:41 stephenfin Was going to state that it's performed natively in placement since X, but I couldn't determine fully when X was. Thought it was Ocata but mriedem referenced Pikle
14:09:44 stephenfin *Pike
14:13:26 dansmith stephenfin: so, matt's comment was that none of the virt specific stuff belongs in that reno, but in admin docs
14:13:46 stephenfin Oh, I misread that /o\
14:13:57 stephenfin I thought he was saying the reno was fine but the admin docs should be additional
14:14:33 dansmith well I guess maybe
14:14:36 dansmith here's the thing though:
14:14:48 dansmith these filters would be conflicting with placement since pike
14:14:59 dansmith meaning, they should have been disabled since then, and they warn at startup if enabled
14:15:10 dansmith *that* is when this virt overhead change happened, not now
14:15:22 stephenfin Fair point
14:15:22 dansmith so putting it in a reno for train makes it sound like that behavior is now changing, but it is not
14:15:28 stephenfin Strip it out so?
14:15:32 dansmith so that's why *I* want it not in a reno :)
14:15:44 stephenfin I have the important bits noted at https://review.opendev.org/#/c/672065/2/api-ref/source/parameters.yaml and https://review.opendev.org/#/c/672065/2/doc/source/admin/configuration/schedulers.rst@1355 I think
14:15:54 stephenfin the latter being more importnat
14:15:57 stephenfin *important
14:15:57 dansmith yeah, so I'll strip it out and add some more words to this, and then go hunting for a place to maybe explain it in a generalized way or something
14:16:24 dansmith stephenfin: oh, yeah, that second bit is perfect
14:16:30 dansmith so I think we can just strip this out of the reno then
14:16:36 stephenfin Sounds good to me
14:16:45 stephenfin Happy to do that or will I?
14:16:55 dansmith I have it open already
14:17:06 stephenfin (y)
14:18:15 stephenfin In that case, I've two references to config options in that second bit that should probably do with the ':oslo.config:option:' role, but as a nice-to-have
14:19:05 dansmith can you barf up the rst for me to link to that schedulers section?
14:23:51 dansmith hmm, maybe i just use the full link? I thought there was a shortcut
14:24:38 stephenfin To the section I added?
14:25:35 stephenfin You need to add an anchor before the title and then you can use the :ref: role, assuming it's within the same doc build
14:25:56 stephenfin so add e.g. '.. _hypervisor-specific-considerations:'
14:26:13 stephenfin then reference wherever you want with ':ref:`hypervisor-specific-considerations`'
14:27:01 stephenfin or https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#hypervisor-specific-considerations if it's from a reno or something
14:27:05 dansmith ack was just piecing that together from mah grepping
14:27:09 dansmith I have to re-learn this every damn time
14:28:32 dansmith stephenfin: er, I don't see any other :ref: usage in the renos.. are renos in the same build as the other docs?
14:28:52 stephenfin You've to use a URL there
14:28:59 openstackgerrit Eric Fried proposed openstack/nova master: DNM: experiment with GreenThread passthrough https://review.opendev.org/672299
14:29:01 stephenfin because they're a different build
14:29:07 dansmith right okay, but the anchor makes it #able yeah?
14:29:11 stephenfin Yup

Earlier   Later