| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 14:54:59 | dansmith | yup | |
| 14:55:02 | dtantsur | one mistake - and the cloud is in a very strange state | |
| 14:55:29 | dansmith | but that's the risk of skip level upgrades, | |
| 14:55:37 | dansmith | you're taking the complexity of skipping into your own hands | |
| 14:55:47 | dansmith | it's a tradeoff of complexity and downtime for infrequent upgrades | |
| 14:55:56 | dtantsur | okie, but how is the command invokation going to look? | |
| 14:55:59 | dansmith | that's been a core part of my messaging on the topic at least :) | |
| 14:56:25 | dtantsur | $ nova-migrate-to-pike <host> --node <uuid>=<class> --node <uuid2>=<class2> | |
| 14:56:25 | dansmith | nova-manage db migrate-ironic-things --resource_class 'undercloud' --do-all-make-my-db-hurt | |
| 14:56:28 | dtantsur | ? | |
| 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:41 | dtantsur | dansmith: wait, tripleo uses one resource class, but that does not mean everyone does | |
| 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 | dansmith | and | |
| 15:03:13 | mriedem | this is probably going to have to use all sqla orm code, | |
| 15:03:23 | mriedem | since we don't have some query methods you'd need on the objects | |
| 15:03:34 | dansmith | maybe yeah | |
| 15:03:34 | mriedem | unless you just did ComputeNodeList.get_all and filter in python | |
| 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 | openstack | Launchpad bug 1715182 in OpenStack Compute (nova) "_rollback_live_migration does not remove allocations from destination node" [High,Triaged] | |
| 15:42:52 | mriedem | johnthetubaguy: here you go https://bugs.launchpad.net/nova/+bug/1715182 | |
| 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 | mriedem | sdague: lyarwood: stable/pike backport for a novaclient thing regressed since 9.0.0 https://review.openstack.org/#/c/495901/ | |
| 15:51:10 | dtantsur | mriedem: do you remember when we have lunch? | |
| 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 | |