Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-30
16:16:58 stephenfin efried: I did. Did you happen to leave comments on the patch, out of curiosity?
16:17:17 stephenfin If not, could you? I probably won't get a chance to respin that until next week now
16:18:10 efried stephenfin: The code side? No, I wasn't planning to do a pass through that until... uh, later. But assuming you've got a placeholder in there for powervm, I'll go stuff the link in there.
16:20:33 efried stephenfin: done
16:21:12 stephenfin ta
16:27:29 stephenfin gibi: quick question: what move operations, if any, did we support for instances with QoS interfaces in Train?
16:37:55 efried stephenfin: per release notes, cold migrate and resize https://docs.openstack.org/releasenotes/nova/train.html
16:39:30 efried mm, runways could use a refresh https://etherpad.openstack.org/p/nova-runways-ussuri
16:39:56 efried Is anyone paying attention to those anymore?
16:40:10 efried lyarwood: I'm going to move stable device rescue into a slot, mkay?
16:43:36 lyarwood efried: yarp, was going to ask about runways in the meeting this evening.
16:43:44 lyarwood efried: I assume this means they are still a thing?
16:44:06 efried I don't know. I, for one, hadn't looked at that etherpad in *months*
16:44:13 lyarwood kk
16:44:19 efried Easy enough to update it though, in case anyone is.
16:45:44 efried dustinc: Reckon it wouldn't be wrong for you to put provider config in there
16:46:13 efried what's the status btw? Are we waiting for an update based on gibi's last round of review?
16:51:27 stephenfin efried, bauzas, dansmith, <Anyone else that cares>: We had a bug reported downstream complaining that the 'os-hypervisors' API doesn't list CPUs in the new cpu_(shared|dedicated)_set config options. That was intentional on my behalf because the API is awful and I wanted to deprecate it
16:51:42 stephenfin I think we can get most of that information from placement now so it's also unnecessary
16:52:05 bauzas yup, we can tell the people who pay us : 'go use osc-placement'
16:52:14 stephenfin Anyone know of a reason to keep it, and do I need a spec to deprecate it in a microversion or is a specless BP good enough?
16:52:16 efried stephenfin: if we can deprecate that API, let's do that.
16:52:30 efried ahcrap, I can never remember how that works. gmann?
16:52:38 bauzas last time we discussed, some ops disagreed AFAICR
16:52:54 bauzas I would first raise the problem in a ML thread
16:53:04 bauzas and ask ops what they think
16:53:07 dansmith if you want to deprecate then a microversion yeah
16:53:15 bauzas and yeah a microversion if so
16:53:52 efried A microversion to deprecate? Or a microversion to remove?
16:54:05 kashyap gibi: 3-hour long call, and then right after working? You deserve a drink
16:54:06 stephenfin Well, to remove
16:54:09 efried the former doesn't make a lot of sense, does it? Is there some kind of signal we give in a response?
16:54:17 stephenfin But it'll still be there in the older microversions
16:54:28 openstackgerrit Merged openstack/os-vif master: [OVS] VLAN tag should be set in the Port register https://review.opendev.org/703373
16:54:34 stephenfin i.e. we won't HTTP 410 of course
16:54:37 gibi kashyap: I wrap up my day quickly then drink :)
16:55:09 gibi stephenfin, bauzas: I added your patches to my queue for re-review for tomorrow
16:55:22 bauzas np, thanks
16:55:41 bauzas gibi: and I totally understand your pain of long-running meetings
16:56:58 gibi stephenfin: qos + move in train, based on https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports it is resize and cold migrate that is supported in train
16:58:18 melwitt yeah, if you want to deprecate os-hypervisors, I think that should (1) be run by some ops people like bauzas said and (2) make sure everything you can get in one swoop from os-hypervisors is also gettable from placement in one swoop. maybe two swoops would also be ok, or I guess could talk about placement cli batching. just some things to think about
16:58:23 gibi efried: about the provider config, I think the ball is at dustinc
16:58:48 bauzas agreed with melwitt, the (2) is important
16:59:01 bauzas and IIRC, that was why we never deprecated this API
16:59:09 bauzas because of the feature gap
16:59:36 bauzas but maybe I'm wrong, so I would just propose to identify all the parity between the API and the osc-placement calls and document it
16:59:39 melwitt yeah, I assumed that's why it's still around but tbh I have never dug in more
16:59:52 bauzas it would be easier to pull the trigger and convince people after that
17:00:00 stephenfin melwitt: So come up with a osc-placement replacement for the 'openstack hypervisor show' command?
17:00:23 bauzas I can't recollect in my mind but I remember we had a convo around it in some f2f like summit or ptg
17:00:32 bauzas stephenfin: document it first
17:00:44 bauzas and then ask whether ops are okay with the replacement as it is
17:01:01 bauzas (that'd be my recommendation in order not to freak out ops)
17:01:05 melwitt stephenfin: no sorry, I was just saying if it takes multiple calls to placement to gather the same data that os-hypervisors gives in one call (I don't know if it does, but if this is the case) then consider a osc-placement cli batch command to give operators that ease that they had before with os-hypervisors
17:01:16 stephenfin Ah, gotcha
17:02:12 melwitt ++ yeah this is all hypothetical until you dig in, just wanted to cover the considerations at a high level
17:09:08 openstackgerrit Merged openstack/nova master: zuul: Remove unnecessary 'USE_PYTHON3' https://review.opendev.org/695380
17:12:15 gibi dansmith: if you have time, I replied to your comments in https://review.opendev.org/#/c/702261
17:12:59 efried dustinc: are you planning to do anything further with https://review.opendev.org/#/q/topic:bp/openstacksdk-in-nova+status:open ?
17:15:28 dansmith gibi: okay I'll have to rebuild context on it
17:17:41 dansmith gibi: are you saying that we've received an instance with a modified pci request over rpc from the destination and we're doing the refresh to dump that and avoid persisting the changed-but-no-longer-relevant field on the instance?
17:19:33 gibi dansmith: exactly
17:19:38 dansmith if so, refresh seems like a big hammer for that because it will drop any other changes we have on the instance that we might want (even if that happens in the future). Looks like refresh can't take a list of fields (which I guess makes sense) so I don't really have an alternative
17:21:21 gibi dansmith: right now I don't feel we have a problem with refresh, but if it happens in the future then we need to extend the ovo interface or start saveing the old value of the pci request somewhere
17:21:38 dansmith refresh isn't an ovo thing, it's an instance thing
17:21:48 efried sean-k-mooney: You still planning to drive https://review.opendev.org/#/q/topic:bp/image-metadata-prefiltering+status:open in ussuri?
17:21:49 gibi dansmith: ohh, then I can hack on it right now
17:22:15 dansmith gibi: what about checking obj_what_changed() right before the refresh and asserting that it's either empty or just contains the pci request info and logging a warning if not?
17:23:07 dansmith gibi: in fact if you did that you could avoid the expensive refresh for everyone else if it's not SRIOV
17:23:14 gibi dansmith: I can do that. But I can also extend the refresh() call with an optiona; field list
17:23:45 dansmith gibi: I'm less excited about the latter just because of the potential effort in validating it, but it seems like that might be useful
17:24:21 dansmith gibi: I think the reason we didn't initially do that is because you may be creating a franken-instance where you've pulled some updates from the db and not others, which are co-dependent and then would save it back in an inconsistent state
17:24:22 gibi dansmith: OK. I will follow your suggestion and check obj_what_changed and log a warning if we would drop other fields than pci
17:24:37 dansmith gibi: and avoid the refresh if nothing is changed yeah?
17:24:41 gibi yepp
17:24:43 dansmith cool
17:24:50 gibi and make a note about selective refresh for later
17:24:57 gibi dansmith: thanks!
17:25:15 dansmith ack, also note my piconit :)
17:25:53 gibi ack :)
17:28:58 gibi o/
17:41:01 gmann cmurphy: can you revisit this review. i replied in the comment, https://review.opendev.org/#/c/701624/
17:41:43 gmann doing deprecation in base rule is to avoid adding the deprecation warning in each rule using base rule as their check_str
17:44:17 gmann cmurphy: you can find more discussion here on doing deprecation in base rule than specific rules - https://review.opendev.org/#/c/676682/4/nova/policies/admin_actions.py
17:49:14 efried stephenfin: is there anything further to be done for https://blueprints.launchpad.net/nova/+spec/remove-xvpvncproxy or can I mark it complete?
17:50:21 stephenfin efried: Nope, melwitt and mriedem closed it out a few weeks back. It's done.
17:50:27 efried sweet
17:51:59 cmurphy gmann: i will come back to it today, thanks for pointing me to the discussion
17:52:19 cmurphy i'm hoping lbragstad could also offer some insights ^
17:52:21 gmann cmurphy: thanks
17:52:25 gmann +1
18:26:15 efried dansmith: Are you pursuing this https://review.opendev.org/#/c/693226/ ? (nova-audit)
18:26:33 efried If so, would you please throw out a bp for it? I'm getting those ducks lined up.
18:28:10 dansmith efried: no, I had abandoned it
18:28:31 efried oh, looks like melwitt restored it. melwitt ^ ?
18:29:16 melwitt I had restored it to encourage ops review, I was told the abandonedness confused the people who would comment on it
18:30:02 efried melwitt: k. Been a couple weeks. If you wouldn't mind putting up a blueprint so it's properly trackable. Then I guess we can go-no-go it at spec freeze time.
18:30:36 melwitt efried: yeah, makes sense. I will do that
18:37:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Deprecate base rules in favor of new rules https://review.opendev.org/701624
18:38:23 gmann cmurphy: lbragstad done ^^

Earlier   Later