Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-08
13:43:26 bauzas mriedem: yup, sean-k-mooney discovered it
13:43:51 mriedem is there a bug?
13:44:04 sean-k-mooney well technically one of the sriov live migration ptachs discovered it when it was running its gate job
13:44:17 sean-k-mooney no but i can open one quickly
13:44:24 sean-k-mooney then respin the patch
13:45:12 mriedem i'm opening one
13:45:15 mriedem just for e-r
13:45:45 sean-k-mooney ok ill stop creating one so.
13:46:08 sean-k-mooney i also looked and osc still does not have evacuate support
13:46:23 sean-k-mooney do we want to go add it?
13:46:29 openstackgerrit Matt Riedemann proposed openstack/nova master: update gate test for removal of force evacuate https://review.openstack.org/641986
13:47:20 mriedem yes osc should have evacuate support at some point
13:47:37 sean-k-mooney e.g. i will be on a plane for a few hours tomorrow should i go play with trying to add it
13:49:56 sean-k-mooney ill pull down osc anyway just to have it. does anyone know if they swapped to useing the sdk yet?
13:53:26 mriedem not for nova
13:53:30 mriedem but some things yes, like neutron i think
13:57:03 sean-k-mooney mriedem: by the way what does e-r stand for.
13:57:09 sean-k-mooney oh elastic recheck
13:57:27 mriedem yeah
14:08:46 sean-k-mooney out of interest if i was to add evacuate to osc, would people object to me calling it "recreate" e.g. openstack server recreate or somethign closer to what it actully does?
14:09:36 edleafe sean-k-mooney: generally the osc names are supposed to be saner than the names in the python-*client libraries
14:10:36 sean-k-mooney ya what i would personally prefer is 3 commands
14:10:50 sean-k-mooney openstack server recreate e.g. nova evacuate
14:11:04 sean-k-mooney openstack host evacuate e.g. nova host-evecuate
14:11:26 sean-k-mooney and opentack host evacuate --live fo nova host-evacuate-live
14:12:54 sean-k-mooney or actully it could be openstack host migrate and openstack host migrate --live
14:13:53 sean-k-mooney in anycase i have never modifed osc before so ill jsut start with porting nova evacuate and see how things go
14:14:04 bauzas sean-k-mooney: openstack host evacuate doesn't exist from an API PoV
14:14:11 bauzas it's just a client thingy
14:14:15 sean-k-mooney bauzas: yes i know
14:14:15 edleafe yeah, I'm not sure which terms would make the most sense. But yes, names that actually convey what the call does are preferred. :)
14:14:20 bauzas so, no to be an OSC CLI command
14:15:13 sean-k-mooney bauzas: is that a rule that osc cant have things that are not directly supported by the api
14:15:38 bauzas good question
14:15:57 sean-k-mooney but ok i was going to look at those after so no worries ill just focus on nova evacuate first ot figure out how things work
14:15:58 bauzas but honestly, I hate the host-evacuate method
14:17:23 sean-k-mooney ya i have personally neverr used it but i have used the horizon one in the past but mainly for testing
14:19:33 bauzas sean-k-mooney: FWIW, I'm planning to ask for some time for me in the next cycle for OSC gap closure
14:19:40 bauzas on the next week :p
14:20:14 bauzas so you could see my name somewhere in your OSC evacuate change :p
14:20:23 sean-k-mooney oh cool we brought it up at the last ptg but stephen and i never really got around to doing it
14:21:17 sean-k-mooney it woudl be nice to swap entirely to osc at some point
14:21:50 sean-k-mooney but ya there are a number of challanges with that at present
14:24:11 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.openstack.org/642030
14:34:17 sean-k-mooney speaking of spec i need to write and review a few
14:44:27 bauzas sean-k-mooney: closing OSC gap is one thing, swap to OSC is a totally different thing
14:44:43 bauzas sean-k-mooney: I'm just talking of the next TC goal which is somehow close to the former
14:45:02 bauzas at least at the last consensus point we had
14:57:05 openstackgerrit Artom Lifshitz proposed openstack/nova master: Dont' wait for VIF plugging during revert resize https://review.openstack.org/639396
14:57:18 artom Alright, I think the tests should pass on ^^ now
14:57:37 artom mriedem, can I ask you to hit that when you get a moment? You're neck-deep in the resize flow anyways ;)
14:58:32 dansmith mriedem: fried_rice: related failure to a novaclient release? http://logs.openstack.org/92/624592/11/gate/nova-live-migration/06aea60/job-output.txt.gz#_2019-03-08_12_45_00_250123
14:59:22 artom stephenfin, how much do you know about resize? Can I pick you as the lucky RH core for ^^ ?
15:00:54 mriedem dansmith: yes
15:00:59 mriedem dansmith: https://review.openstack.org/#/c/641986/
15:01:12 dansmith ah okay
15:01:31 mriedem artom: did you sort that out with dansmith?
15:02:25 dansmith mriedem: he's just removing a wait for events on resize, which is more a you think than me
15:02:46 dansmith it doesn't break the context manager for waiting for events, so I'm happy(er)
15:03:29 artom mriedem, I think so. I also checked with slaweq who's in our Neutron team, and he confirmed that the VIF remains plugged on the source host
15:03:47 dansmith artom: um, what? :)
15:04:01 artom dansmith, what what?
15:04:10 artom Is plugged the right word? Wired?
15:04:13 mriedem i feel like i just had a patch like this
15:04:17 mriedem but was maybe for confirm
15:04:30 dansmith artom: that makes no sense for what you're saying here
15:04:43 artom dansmith, entirely plausible, but explain how :)
15:04:54 dansmith oh, this is finish_revert, I see
15:05:09 dansmith I thought it was finish-finish
15:05:23 artom Swedish finish?
15:05:27 aspiers sean-k-mooney: strong +1 for renaming evacuate, my preferred term would probably be "resurrect"
15:05:30 dansmith but still, you're not asserting this was always broken right?
15:05:36 artom dansmith, always racy
15:05:44 dansmith artom: what's it racing with?
15:05:54 artom Neutron with the virt driver
15:06:19 mriedem artom: so you're reverting this essentially right? https://review.openstack.org/#/q/I9e0cffb889c94713c7f28812918103a5d97cefeb
15:06:19 aspiers sean-k-mooney: "revive" might also work
15:06:45 artom mriedem, err, yes. WTF.
15:08:31 mriedem ok -1 until we have a good explanation of why https://review.openstack.org/#/c/595069/ was wrong
15:08:42 mriedem but maybe that explains a regression you're seeing downstream?
15:08:44 dansmith artom: okay, so tickling from compute manager will cause that event to start heading towards us because there are still interfaces available for neutron agent to find.. I kinda buy that, I guess...
15:08:48 artom mriedem, fair enough
15:09:21 dansmith I also -1d for the drunk speak in the commit message
15:09:27 artom ...
15:09:36 artom Well now you're just picking on em :(
15:09:38 artom *me
15:09:42 dansmith but yeah, I'd like to hear from lyarwood I guess
15:09:52 mriedem dansmith: it was my change :)
15:09:55 mriedem lyarwood backported it
15:10:24 mriedem and https://review.openstack.org/#/c/179228/ was your change :)
15:10:27 mriedem it's great
15:10:33 artom In a meeting now, I think I'll have to play around with it afterwards
15:10:37 artom Until now I was relying on logs
15:11:02 artom Yo-yo patches...
15:11:05 stephenfin oh, that's interesting
15:15:37 dansmith oh
15:15:40 mriedem artom: dansmith: ok so i see the race in https://review.openstack.org/#/c/595069/
15:15:43 mriedem the dest triggers the event,
15:15:46 mriedem the source is waiting for it,
15:15:53 mriedem but it might come before the source is registered for the callback

Earlier   Later