Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-05
14:56:41 dtantsur dansmith: wait, tripleo uses one resource class, but that does not mean everyone does
14:56:41 jaypipes dansmith: would you be able to attend this session in Denver? https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
14:56:44 dansmith or if you have different ones, then:
14:56:52 dansmith nova-manage db migrate-ironic-things --resource_class 'undercloud' --host foo1
14:57:05 dansmith dtantsur: sure, that means you have to do your hosts one at a time with a rc then
14:57:25 dtantsur dansmith: host == ironic node, not nova-compute process, right?
14:57:29 dansmith jaypipes: um yes? been working on this with lyarwood :)
14:57:31 dtantsur (sorry, I always confuse the terms)
14:57:39 dansmith dtantsur: ah, well, that's a fair point
14:57:54 dansmith dtantsur: I was meaning compute, but yeah --node is probably the better option
14:58:44 rabel mriedem: i answered to your questions on https://review.openstack.org/#/c/494169/ . could you have a look at it again?
14:59:48 vdrok dtantsur: yeah everything except friday works for me
14:59:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Mark LXC as missing for swap volume support https://review.openstack.org/482216
15:01:19 dansmith dtantsur: mriedem: anyway, let me cook something up along these lines and ya'll can rip on it
15:01:29 dtantsur yes please :)
15:01:36 mriedem we do have this compute_nodes.mapped column now
15:01:43 mriedem wonder if we could use that for dumb paging
15:02:09 dansmith mriedem: not really a good idea, I don't think
15:02:25 dansmith mriedem: we'd have to bump that for all the non-ironic computes too if we did
15:02:40 mriedem true
15:03:13 mriedem this is probably going to have to use all sqla orm code,
15:03:13 dansmith and
15:03:23 mriedem since we don't have some query methods you'd need on the objects
15:03:34 mriedem unless you just did ComputeNodeList.get_all and filter in python
15:03:34 dansmith maybe yeah
15:03:51 dansmith just some non-remotable object queries to make it clean is fine I think
15:03:55 dansmith no rpc impact there
15:04:40 mriedem taking a uuid would be nice, but you don't get the uuid out of the rest api until you're at pike
15:04:47 mriedem so that's out of the question probably
15:05:24 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323
15:05:25 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
15:05:26 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
15:11:22 melwitt abhi89: the cell with uuid of all zeros is "cell0" which contains only instances that failed to be scheduled. it's not associated with any compute host. see doc https://docs.openstack.org/nova/latest/user/cellsv2_layout.html
15:29:35 efried avolkov yt?
15:34:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Add some inline code docs tracing the cold migrate flow https://review.openstack.org/496861
15:37:20 avolkov efried: hi
15:37:39 efried avolkov Was just about to respond to your ML post about HA/anti-affinity of SR-IOV VFs...
15:38:59 efried avolkov I think we can do a bit better even within the bounds of the existing placement API (assuming we get nested RPs).
15:39:14 efried ...by chunking the PFs into HA groups.
15:39:54 efried So I don't think you need the ports labeled P1, P2, P3, P4. I think you can label them G1 and G2, spread across your switches.
15:40:27 avolkov efried: some meta group based on those properties? sounds good
15:40:41 efried This gets a little weird in flavor land, though, cause you'd need a separate flavor for each group I think.
15:41:16 efried So you would have one flavor that says "give me two VFs: one from Switch 1 + Group 1; one from Switch 2 + Group 1"
15:41:27 efried Then another that says "give me two VFs: one from Switch 1 + Group 2; one from Switch 2 + Group 2"
15:41:55 efried ...and somehow alternate which one you use to do spawns, so you get saturation of the different ports.
15:42:09 efried Using P1/P2/P3/P4 you have that same problem, only twice as bad :)
15:42:40 avolkov efried: yeah :), it's another question I wanted to ask
15:42:52 mriedem johnthetubaguy: here you go https://bugs.launchpad.net/nova/+bug/1715182
15:42:52 openstack Launchpad bug 1715182 in OpenStack Compute (nova) "_rollback_live_migration does not remove allocations from destination node" [High,Triaged]
15:42:56 edmondsw efried what does the group signify that knowing the switch doesn't tell you?
15:43:16 edmondsw i.e., isn't the switch tag essentially a group tag?
15:43:20 efried no
15:43:50 edmondsw oh, I guess you could have the switches wired differently
15:44:38 efried (sorry, got an interrupt, gimme a few mins...)
15:47:59 efried okay, so avolkov that's a point: how many VFs do you want?
15:48:04 edmondsw I guess what I'm getting at is that you shouldn't need to know switch or port... just groups
15:48:11 efried avolkov If you want four, then yeah, you only need one flavor.
15:48:14 openstackgerrit Merged openstack/os-vif master: Add plugin names as constants. https://review.openstack.org/500111
15:49:24 efried "give me four VFs: Switch1 x Group1; Switch1 x Group2; Switch2 x Group1; Switch2 x Group2"
15:49:30 mriedem dtantsur: i've started a rough agenda at the bottom of this etherpad https://etherpad.openstack.org/p/nova-ptg-queens
15:49:38 mriedem penciled in ironic for 3pm on wed
15:50:03 edmondsw efried why wouldn't that be (give me 2 from group 1 and 2 from group 2)?
15:50:08 dtantsur cool, lemme check our schedule
15:50:25 efried edmondsw Because then you might get both from the same switch in group 1
15:51:02 edmondsw efried not if they defined the groups properly...
15:51:10 dtantsur mriedem: do you remember when we have lunch?
15:51:10 mriedem sdague: lyarwood: stable/pike backport for a novaclient thing regressed since 9.0.0 https://review.openstack.org/#/c/495901/
15:51:15 dtantsur is it right after or...?
15:51:20 mriedem dtantsur: i was told 12-1
15:51:24 dtantsur thnx
15:51:37 efried edmondsw How can you define two groups to ensure you get four separate ports across two separate switches?
15:51:43 mriedem 3pm wednesday would be *after* lunch :)
15:52:52 edmondsw group 1 = one port to sw1 and one to sw2, group 2 = one port to sw1 and one to sw2, then ask for 2 ports in each group
15:53:49 efried edmondsw But placement doesn't know enough to not give you both VFs from group 1 on the same switch.
15:54:18 edmondsw efried there aren't 2 ports in group 1 with the same switch
15:54:35 efried Yes, there are multiple VFs on each pport.
15:54:44 edmondsw oh, VFs...
15:55:06 edmondsw I gotcha now
15:55:07 efried And yes, you could conceivably do this same thing with four groups - but enumerating switches might make more sense to the user; and you also want the model to extend to >2 switches, >2 ports per switch.
15:55:29 dtantsur mriedem: okay, sounds good
15:56:16 efried although... avolkov that might actually make more sense. If you always know you want four VFs, you could just tag your PFs in groups so they'll always be spread out.
15:56:20 edmondsw efried how about group 1 = 2 ports to sw1 and group 2 = 2 ports to sw2?
15:56:55 efried edmondsw Then again you'll ask for two VFs from group 1 and they might wind up coming from the same pport
15:57:17 edmondsw yep, k... better for PFs but doesn't help with VFs
15:57:30 efried eh?
15:57:41 edmondsw nm... it doesn't work, so it doesn't work :)
15:58:16 edmondsw I'm not following why you wouldn't tag them with the port, then
15:58:29 efried avolkov In your email example, it's no different than having labeled P1,P2,P3,P4 - but extending to more than four pports (or reducing the problem set to fewer than 4 desired VFs) it makes more sense to think of groups - where the total number of groups is the number of VFs you're going to want from a single allocation request.
15:58:34 efried edmondsw ^^
16:00:12 avolkov efried: groups are okay if you have the same requirements for each boot request
16:01:17 avolkov efried: with original properties you can ask distinct ports for one boot request and distict switches for another
16:01:17 efried avolkov Yeah, I get it. If they're different, then it makes more sense for each PF to have its own label, and you do your HA/anti-affinity by constructing your flavors appropriately.
16:02:22 efried Problem with that, though, is if you don't have exactly the same number and configuration of SR-IOV cards on all your hosts.
16:02:39 edmondsw will it be possible to request ports on separate identical cards (HA if a card fails)?
16:03:05 efried So it probably makes more sense to *call* them groups anyway, even if they usually/always map to PFs :)
16:03:15 sean-k-mooney efried: i would prefer if we did not model this in flavor or image properties though
16:03:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add functional recreate test for live migration pre-check fails https://review.openstack.org/500907
16:03:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Cleanup allocations on invalid dest node during live migration https://review.openstack.org/500908
16:03:28 efried sean-k-mooney Which "this"?
16:03:36 sean-k-mooney efried: really we should try to model the bond requiremetn as an atribute of the neutron port

Earlier   Later