Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-05
15:26:40 finucannot mriedem: Done, I think
15:26:56 fried_rice melwitt: Looks like there's only nine.
15:26:59 fried_rice stand by
15:28:04 fried_rice mriedem, melwitt: wanna merge this one real quick first so we don't have to rebase/renumber? https://review.openstack.org/#/c/649190/
15:29:00 finucannot mriedem: Related. Could you give your take on this when possible? https://review.openstack.org/#/c/649974/ (ignore the failing pep8 test - I'll fix that shortly)
15:29:53 mriedem finucannot: i'm pretty sure there is already a patch related to that
15:30:10 mriedem which fried_rice is aware of
15:30:20 mriedem the xenapi + openssl warning one
15:30:51 fried_rice finucannot, mriedem: this one https://review.openstack.org/#/c/635533/ ?
15:31:06 mriedem yeah
15:32:21 mriedem maybe those aren't related i guess
15:32:24 melwitt fried_rice: looking
15:34:08 finucannot fried_rice, mriedem: Yeah, that looks like the same thing and is probably a better solution (though the tests are still rubbish, IMO)
15:34:40 finucannot well, similar thing. Solution for that should cover my issue
15:35:32 jaypipes cdent: your expertise needed on https://review.openstack.org/#/c/650172/3/nova/context.py please if you have a mo.
15:35:49 jaypipes thankie
15:35:55 openstackgerrit Stephen Finucane proposed openstack/python-novaclient stable/stein: Revert "Fix crashing console-log" https://review.openstack.org/650363
15:36:04 openstackgerrit Stephen Finucane proposed openstack/python-novaclient stable/rocky: Revert "Fix crashing console-log" https://review.openstack.org/650364
15:36:20 sean-k-mooney finucannot: mriedem this patch right https://review.openstack.org/#/c/635533/
15:38:47 finucannot sean-k-mooney: yup
15:42:15 sean-k-mooney so it was not clear to me if https://bugs.launchpad.net/nova/+bug/1771506 is a release blocking bug for cannoical or not. i twould seam that xen would be broken due to this assueming that ubuntu/debian now shiped openssl 1.1.1
15:42:16 openstack Launchpad bug 1771506 in OpenStack Compute (nova) "Unit test failure with OpenSSL 1.1.1" [Low,In progress] - Assigned to Corey Bryant (corey.bryant)
15:43:16 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
15:45:34 sean-k-mooney its a bit late but i think we should proably land https://review.openstack.org/#/c/635533/ or something similar soon and then figure out how to use the python libs for train
15:46:59 sean-k-mooney the final RC went out last night so this would not be in the GA release anyway right but i think it can be applied ot stable/* once we are happy with it
15:48:54 finucannot jaypipes: Thoughts on https://review.openstack.org/555081 this cycle?
15:49:15 melwitt cdent: thanks for the comment on the review. I had also asked (in the same stack of replies) if there's a way to detect whether we're running under wsgi or not? sean-k-mooney had suggested as a follow on patch, if we could choose between the executor type (eventlet vs not) based on wsgi/not it would be nice
15:49:27 finucannot jaypipes: I recall you were pretty fatigued with it last cycle. I'd be happy to pick it up if you're not keen to try again with it
15:50:29 jaypipes finucannot: go for it.
15:50:43 finucannot (y)
15:50:46 jaypipes finucannot: I'm pretty fatigued with most things OpenStack at this point.
15:50:47 cdent melwitt: hmmm. good question. I would think the wsgi `environ` will probably be able to tell you something, or sys.argv[0]?
15:50:55 sean-k-mooney melwitt: you can ask eventlet if things have been mokeypatch but we shoudl be able to provide a clearner way
15:51:08 jaypipes finucannot: and cdent's sighs and comments on that spec are spot on, fwiw.
15:51:21 finucannot agreed
15:51:43 jaypipes hardware-defined software strikes yet again.
15:51:44 melwitt cdent: ok, I will search in that direction. thanks
15:52:32 cdent melwitt: in environ there may be a way to get the name of the server, and the eventlet-driven server may have a unique name thus maybe a branch on that. goign the other way is harder since there are so many choices
15:52:44 sean-k-mooney melwitt: well what i was thinking is we proably can create the executor up front once and hide the decision form that function
15:53:28 sean-k-mooney melwitt: so in the case where we monkeypatch we can use teh greenlet on and where we dont we can use soemthing else
15:54:00 melwitt sean-k-mooney: doesn't the upfront thing have to choose too? I don't really understand what you mean
15:54:18 cdent there are two different entry points
15:54:27 melwitt oh, ok
15:54:58 sean-k-mooney yes that ^ and its cleaner to detect once then in all places that could need this in the future
15:55:00 cdent I can't remember the exact details, but the wsgi app has some unique code in advance of being-ready-to-serve
15:55:05 melwitt I see
15:55:12 sean-k-mooney assuming there are other asyc things we might want to do in the api like this
16:00:56 mriedem dansmith: you know how we restrict the request spec to the cell the instance is in before calling the scheduler during cold/live migrate and unshelve?
16:01:11 mriedem i do'nt see us doing that for evacuate, but seems we should... yeah?
16:01:37 mriedem you can't evacuate across cells
16:02:43 dansmith probably
16:03:17 dansmith I thought it was done in a place that was likely to catch any instance that already exists in the db
16:03:45 mriedem we explicitly lookup and set the cell on the Destination object in unshelve, cold and live migrate methods before calling the scheduler,
16:03:59 mriedem so it's not generic-ified anywhere as far as i know
16:04:24 dansmith hmm, okay it's been a long time since I looked, but okay
16:04:35 dansmith but yeah, if we're not we should for evac
16:04:59 mriedem cern must not do a lot of evacs or they are somehow otherwise restricting the server to a given cell with aggregates or something
16:05:01 openstackgerrit melanie witt proposed openstack/nova master: Use futurist.GreenThreadPoolExecutor in scatter_gather_cells https://review.openstack.org/650172
16:05:09 dansmith they have tenant aggregates,
16:05:13 dansmith which probably fixes it for them,
16:05:20 dansmith s/,$//
16:06:12 mriedem yar, could probably easily do something with a 2-cell func test that has 1 compute in each and evacuate the server, see what blows pu
16:06:13 mriedem *up
16:08:50 openstackgerrit Eric Fried proposed openstack/nova master: Hacking N363: Don't use spec[_set]='string' https://review.openstack.org/650370
16:09:15 fried_rice mriedem, melwitt: ^ (will fail until violations are repaired)
16:11:01 melwitt fried_rice: should I roll the fixes into your patch or stack a patch under yours?
16:14:04 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec https://review.openstack.org/645814
16:14:06 mriedem dansmith: sanity check on my logic here would be nice https://bugs.launchpad.net/nova/+bug/1823369
16:14:07 openstack Launchpad bug 1823369 in OpenStack Compute (nova) "_nova_check_type scheduler hint could be accidentally persisted during a rebuild with image change" [Medium,New]
16:15:11 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:15:48 sean-k-mooney ignore ^ i forgot to run pep8
16:18:37 fried_rice melwitt: Either way. If you stack under, you get to +2 :P
16:18:45 melwitt heh, yup
16:19:56 mriedem https://bugs.launchpad.net/nova/+bug/1823370 for the evac thing
16:19:57 openstack Launchpad bug 1823370 in OpenStack Compute (nova) stein "Evacuations are not restricted to the source cell during scheduling" [Undecided,New]
16:21:44 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:29:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Use RequestSpec.requested_destination when rebuilding with new image https://review.openstack.org/650376
16:31:38 sean-k-mooney jaypipes: finucannot sriov patches are updated let me know if i need to do anything else with them :)
16:34:44 sean-k-mooney hum looks like the ibm and other are not happy with the depend on actully since its already merged ill quickly fix that
16:36:51 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
16:44:04 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:49:01 openstackgerrit Corey Bryant proposed openstack/nova master: xenapi/agent: Change openssl error handling https://review.openstack.org/635533
17:14:41 dansmith mriedem: ouch, I guess that one is on me
17:41:15 openstackgerrit Merged openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
17:50:57 sean-k-mooney jaypipes: i can look at moving those methods to the RT by the way. i agree it would be nicer to have them there and not spread the locking/resouce tracking code
17:51:49 sean-k-mooney im going to grab soemthing to eat and ill either do it a little later or monday assumin adrianc doesnt get around to it before i do
17:53:46 mriedem dansmith: i have to recreate it first, but i also approved the change i'm sure
17:54:13 mriedem if laura ever asks, just put RequestSpec on my tombstone
17:54:23 dansmith mriedem: roger that
17:58:08 openstackgerrit Matt Riedemann proposed openstack/nova master: Add testing guide for down cells https://review.openstack.org/650167
18:15:38 KH-Jared heh, I see now I'm going to need a good bit of patience for reviews. Didn't realize the average wait time and how close to stein release it was. I think I can wait now
18:18:31 artom KH-Jared, yeah, reviewer bandwidth, especially core, is a long-standing problem in Nova. We all know about, and there's no real solution. You just have to find the right balance between "politely asking" and "outright pestering"
18:18:46 artom Doing reviews yourself is also an excellent way to get your own patch reviewed
18:19:25 KH-Jared that's fair too
18:22:22 melwitt you can also link the patch in here
18:22:51 KH-Jared that'd be the obvious way, I guess, https://review.openstack.org/#/c/649405/
18:24:49 melwitt cool, thanks
18:24:58 KH-Jared ty for looking at it
18:25:09 KH-Jared (if you are, just realized the assumption there)
18:27:33 melwitt haha, yes, I'm looking at it

Earlier   Later