Earlier  
Posted Nick Remark
#openstack-nova - 2019-11-26
19:40:57 dansmith which is both not correct, and also laughably terrible in the implementation currently proposed
19:41:00 mriedem i don't remember the details, i just know it came up in the ML
19:41:22 sean-k-mooney it also came up in the denver and maybe dubling ptg
19:41:28 sean-k-mooney its been a while
19:41:55 sean-k-mooney i think long term we all agreed teh conductor was better.
19:42:00 mriedem ok, let me rephrase: the last time i remember there being thoughtful and documented takes on that was in the ML
19:42:11 mriedem rather than some undocumented stuff from dubling
19:42:20 sean-k-mooney i think at some point there was a request to avoid the rpc chagne but i dont really rememebr
19:42:33 mriedem "i don't really remember" is why i refer back to the ML
19:42:53 sean-k-mooney ya fair
19:42:57 dansmith I don't remember a thread on the ML, but there was discussion and documentation on the spec, which seemed to be the most fresh to me
19:43:54 dansmith https://review.opendev.org/#/c/603955/11/specs/train/approved/nova-cyborg-interaction.rst@250
19:44:01 dansmith this ^
19:44:23 mriedem wacka wacka http://lists.openstack.org/pipermail/openstack-discuss/2019-June/thread.html#6979
19:44:33 dansmith the discussion basically says either can do it, but it's hard to do it from conductor and then catch the event from compute
19:44:34 dansmith that is not a problem
19:46:01 dansmith mriedem: looks like that ended with you still opting for as much in conductor as possible
19:46:16 dansmith but no real summarizing agreement that it should be in compute
19:46:49 mriedem in http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007013.html i'm saying please create arqs in conductor and bind in compute, like john was trying to do with ports at one time
19:47:09 mriedem bind generates the event if that's what is important
19:47:25 sean-k-mooney isnt that what we agreed to do
19:47:33 dansmith right, but bind is the thing that takes a long time,
19:47:41 dansmith so doing that in conductor is what gets us the most gain
19:47:55 dansmith the original email states the reason for moving is because of the eventing being hard, which is is not
19:48:03 mriedem having not really any skin in this game, it doesn't really matter to me anyone re this cyborg series
19:48:13 mriedem i agree the original email is mostly excuses
19:48:25 mriedem minimal change to get a thing to sort of work as a poc
19:48:42 mriedem to which i said essentially, yeah that's why we have a lot of turdy spaghetti code we've wanted to refactor for years
19:48:51 mriedem and why artom calls nova fugly
19:49:19 dansmith yeah, understand.. the reason for moving to compute based on the spec and that original email seemed to be excuses around eventing, which are not valid,
19:49:42 dansmith so I'd prefer we revert back to the original plan which had good reasoning, which is to overlap the programming with all the other things we can do in parallel,
19:49:47 dansmith which means bind at conductor
19:50:09 sean-k-mooney they baically need to do the equvalent of double check locking in the driver. check if its bound start waiting for event, check if its bound again incase you mised it and if so cancel waiting if not wait
19:50:17 mriedem does that include building a new interface into conductor so when the api receives the external event it can route it to conductor rather than compute?
19:50:40 dansmith sean-k-mooney: did you see the explanation I linked above about how to do the check and event without the race?
19:50:47 dansmith sean-k-mooney: they do not need to check twice
19:50:56 dansmith mriedem: no it does not
19:51:16 dansmith read this: https://review.opendev.org/#/c/631244/46/nova/compute/manager.py@2627
19:51:18 sean-k-mooney no but i trust you when you say there is a way to do that
19:51:24 sean-k-mooney but neighter woudl be hard to do
19:51:36 dansmith neighter?
19:51:53 sean-k-mooney neither
19:51:58 dansmith oh
19:52:07 sean-k-mooney ya that was more off then normal
19:52:12 dansmith the double check doesn't actually help, AFAICT, it would have to be N checks i.e. polling
19:52:47 sean-k-mooney well once you have register to wait for the event if you check the status and its not complete you can just wait
19:53:04 dansmith sean-k-mooney: right, that's one check and that's what I mention in the above comment
19:53:19 dansmith it's just that you need a new thing to be able to exit the wait after you have started if you know it is not necessary which is not easy today
19:53:41 dansmith you said "equivalent of double check" so, I see what you mean now
19:53:46 sean-k-mooney ah ok i was suggesting checking that api once ot skip that incase its already done but that is not needed
19:53:51 dansmith yes
19:53:58 dansmith skip is the thing we can't do without the patch I proposed
19:54:34 sean-k-mooney gotch ya
19:56:06 mriedem so tl;dr create and bind the arq in conductor, cast to compute to build, compute grabs the event lock and checks to see if it should wait based on the cyborg api - if so, wait, if not, cancel the wait since the event taint comin
19:56:23 dansmith basically yeah
19:57:40 mriedem i suppose it's out of the question waiting for the cyborg series to be rebased and integrated with said wait-or-cancel function
19:58:05 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/696175
19:59:06 dansmith mriedem: I've already proposed the patch, efried has already asked you to +W, and yes, the cyborg set will need to use it to get my +2 :)
20:00:55 dansmith mriedem: or did you mean waiting to merge the new skip thing until the cyborg set is using it?
20:02:12 mriedem i was hoping to see the latter before having to dig into the new thing, to show something using it successfully outside of unit tests - but i realize that might be awhile
20:02:46 dansmith mriedem: oh that's fine, I don't care that much, but I think it's probably good to get that just landed ahead of time so the set doesn't get too much bigger..
20:03:00 dansmith I'd also propose we land the test base refactor, once it gets unfscked
20:03:18 mriedem i'm not sure why that test base refactor is even needed
20:03:32 mriedem it's just noise imo
20:03:39 dansmith me either, I haven't gotten that far yet, but someone else had a similar one up too Ithought
20:03:48 dansmith was it mdbooth you said?
20:03:53 mriedem "i like 85% of this base class but don't need the other %15 right now, so rip it all apart!"
20:03:56 mriedem yes
20:04:00 mriedem and i have the same feelings about his
20:04:03 dansmith *shrug* whatever
20:04:31 dansmith I couldn't get past the other issues with the refactor to care about reasoning I guess :P
20:07:44 mriedem there i've -1ed both of them
20:44:40 openstackgerrit Alexandre arents proposed openstack/nova master: Flatten qcow2 images when unshelving an instance https://review.opendev.org/696084
21:12:36 openstackgerrit Merged openstack/nova master: nova-net: Remove 'nova-dhcpbridge' binary https://review.opendev.org/686815
21:14:55 openstackgerrit sean mooney proposed openstack/nova master: block rebuild when numa topology changed https://review.opendev.org/687957
21:14:55 openstackgerrit sean mooney proposed openstack/nova master: Disable NUMATopologyFilter on rebuild https://review.opendev.org/689861
21:18:27 openstackgerrit sean mooney proposed openstack/nova master: block rebuild when numa topology changed https://review.opendev.org/687957
21:18:27 openstackgerrit sean mooney proposed openstack/nova master: Disable NUMATopologyFilter on rebuild https://review.opendev.org/689861
21:19:20 sean-k-mooney artom: bauzas hopefully ye are happy with ^
21:49:35 openstackgerrit sean mooney proposed openstack/nova master: support pci numa affinity policies in flavor and image https://review.opendev.org/674072
22:04:29 artom sean-k-mooney, yarp, I'll look tomorrow
22:05:32 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Amend cross-cell-resize spec https://review.opendev.org/696197
22:24:27 mriedem dansmith: efried: btw, to whom it may concern, i'm out tomorrow and back monday
22:24:40 efried ack
22:24:40 mriedem assuming i survive snowmaggaedon
22:24:43 dansmith ack, I'm headed out early tomorrow
22:24:48 efried it's 72 here
22:24:53 efried eat your heart out
22:24:57 mriedem i will not
22:25:06 dansmith yeah, I'll keep what I got but thanks
22:25:36 melwitt it's 52F here
22:25:42 mriedem laura isn't traveling with me (she's on call) but she suggested we get me an AWD vehicle today just b/c her weather travel anxiety by proxy is on high alert
22:26:22 melwitt I love AWD
22:27:33 mriedem hers is, so she can make it across town to work
22:27:44 mriedem me, i just know to not jerk and drive (tm)
22:28:05 dansmith mriedem: better 'splain that one for people about to dial 9-1-H-R
22:28:28 mriedem http://nymag.com/intelligencer/2014/12/south-dakota-yanks-dont-jerk-drive-campaign.html
22:28:41 melwitt lol
22:29:04 melwitt aren't they the same ones doing, "Meth. I'm on it"?
22:29:08 mriedem yes

Earlier   Later