Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
17:14:51 efried cfriesen: But that spec is already approved, so sorry, too late :P
17:15:12 jaypipes efried: yes
17:15:46 mriedem anyone know what is up with this sriov bond thing https://review.openstack.org/#/c/463526/ ?
17:15:52 mriedem sahid might but he's gone now
17:17:10 openstackgerrit Merged openstack/nova-specs master: Few correction in the server filter/sort spec https://review.openstack.org/527019
17:17:18 mriedem dansmith: on the volume-backed rebuild + new image spec, i think i want to just say, add an api to cinder to re-image the volume and once that is in place, nova will use it
17:17:30 mriedem because cinder also has things it needs to update about the image in the volume, i.e. some image metadata stuff
17:17:45 dansmith mriedem: that would certainly be the nicest way yeah
17:17:47 mriedem because i don't think we want to do the volume create / delete swap thing, it's too messy
17:17:57 mriedem quotas, types, etc
17:18:23 dansmith I don't think create/swap/delete would be the way anyway,
17:18:34 dansmith we'd just lay the image down on the volume ourselves I think,
17:18:40 dansmith but that's definitely a whole big thing
17:18:42 sean-k-mooney[m] mriedem: is this yet another attempt at this or is it carring on form the previous attempts
17:18:47 mriedem and the volume image meta would be out of date
17:18:47 cfriesen efried: if you send in two granular resource requests for resources1 and resources2, wouldn't it make sense to get back a dict of {resource1:<rp>, resource2:<rp>} or similar? They could still be the same RP.
17:18:57 mriedem sean-k-mooney[m]: the sriov bond spec? it's old
17:19:00 mriedem and looks stale/abandoned
17:20:22 sean-k-mooney[m] mriedem: oh that is the bound spec that wanted to use neutron config element to configure bonds. ya i hated that part of it
17:20:36 sean-k-mooney[m] mriedem: ya there was also https://review.openstack.org/#/c/182242/ and there are 2-3 other ones dateing back to mitaka
17:21:36 mriedem dansmith: ok done https://review.openstack.org/#/c/532407/
17:21:37 efried gibi: In case you're in the middle, just finished review of https://review.openstack.org/#/c/502306/21
17:22:13 sean-k-mooney[m] mriedem: but yes no one has touched it since december so i think https://review.openstack.org/#/c/463526/43 is abandoned. its still proposed against queens
17:23:11 dansmith mriedem: so, we'll need to detach the volume in order for cinder to be able to do that, which is basically equivalent to root-detach, which we already failed to do in the past.. just.. sayin'
17:23:12 mriedem i abandoned https://review.openstack.org/#/c/182242/ today
17:23:20 gibi efried: thanks, I'm currently working on an update. I will try to address your comments in that as well
17:23:55 mriedem dansmith: detach or disconnect from the host?
17:24:11 mriedem we need to at least keep the volume reserved for the instance
17:24:14 dansmith mriedem: can we do those separately?
17:24:16 mriedem yes
17:24:20 dansmith okay
17:24:24 dansmith then, disconnect I guess
17:24:30 mriedem it's basically shelve
17:24:34 dansmith as long as cinder doesn't have a fit with that internally
17:24:35 mriedem shelve the root volume
17:24:41 dansmith mriedem: ...which you can't do with bfv
17:24:44 mriedem cinder would only care about the attachments
17:24:45 dansmith well,
17:24:48 dansmith you can maybe,
17:25:03 dansmith but not without detaching the root, which I guess is your point
17:25:29 mriedem honestly i don't know if volume-backed shelve works
17:25:36 dansmith I guess the root detach thing was mostly hard because of the desire to attach it to something else in the mean time,
17:25:36 mriedem since snapshot for a volume-backed instance is different in the api
17:25:40 mriedem and the shelve snapshot happens in hte compute
17:25:42 dansmith which wouldn't be the same problem here
17:26:06 dansmith so I think that makes more sense then yeah
17:26:27 sean-k-mooney[m] mriedem: for volumes backed instance i would not expect you to snapshot it at all jsut keep the volume
17:26:45 dansmith just want to make sure we're not sending them off on a mission that, upon completion, leaves more hard nova problems we might punt on
17:26:47 mriedem shelve supports volume-backed instances, it just casts directly to offload
17:26:58 mriedem dansmith: feel free to comment on the spec
17:27:20 sean-k-mooney[m] mriedem: for image backed guest we have too so we can free up the space on teh compute node but for volumes there is no reason to clean it up in the backing store just to put it into an image
17:27:27 mriedem i just can't imagine this is all better done inside nova
17:28:02 dansmith mriedem: no definitely not, just thinking through it
17:28:27 dansmith mriedem: you know, given all the many quagmires that came from nova-cinder interaction in the recent past
17:29:56 sean-k-mooney[m] mriedem: dansmith shelve for a volume backed instance should be jsut, shotdown instance, detach volume and clean up host resouces for vm no? then unshelve is jsut select host to boot on, set up entworking etc and attach volume and boot form it?
17:30:10 mriedem yeah so for volume-backed shelve, there is no snapshot, on unshelve we just re-attach the volumes to the instance on the new host
17:30:26 dansmith mriedem: you're saying that works today right?
17:30:34 mriedem we don't detach the volume, it stays reserved so someone else can't take it while the instance is shelved
17:30:40 mriedem dansmith: looks like it should from the code,
17:30:44 mriedem would need to test it of course
17:30:48 dansmith it's the disconnect that is the important bit for detaching it from the current host
17:30:49 dansmith yeah
17:30:50 sean-k-mooney[m] mriedem: well i dont know if thats what happens today but i think that is what we should be doing
17:31:04 mriedem on shelve offload we delete the instance on the host so that does the disconnect
17:31:43 mriedem sean-k-mooney[m]: yes that's what happens today
17:31:58 mriedem we terminate connections on shelve offload, and then re-attach on unshelve
17:33:40 kashyap imacdonn: I'll write an e-mail to the Operators-List / Dev this week, it's better if we discuss the version stuff there.
17:34:37 imacdonn kashyap: OK
17:34:43 mriedem dansmith: left a note in https://review.openstack.org/#/c/532407/ about the order of operations so we don't forget
17:34:48 kashyap cfriesen: Hey, was AFK (and I will be again in 10 mins). About your question --
17:35:08 dansmith mriedem: cool
17:35:37 mriedem same guys are pushing for volume-backed rescue https://review.openstack.org/#/c/532410/
17:35:41 kashyap cfriesen: As it stands, we are allowing this one choice to alleviate the existing problem. The allowing flags for 'host-model' thing, we can work it out when we lift the restriction
17:35:42 openstackgerrit Merged openstack/nova-specs master: Amend the "add extra-specs to flavor" for create and update API https://review.openstack.org/554134
17:35:48 sean-k-mooney[m] mriedem: this is a different topic so lets not rat hole on it but if i shelve an insatce with an active multi attach volume will one of the other attachment become active. i guess you cant boot from a multi attach volume either right?
17:35:48 kashyap cfriesen: Does that sound reasonable to you?
17:36:06 mriedem sean-k-mooney[m]: you can boot from a multiattach volume
17:36:43 mriedem volume attachments aren't like port bindings, there isn't an active one and an inactive one
17:36:56 mriedem they do have attach modes, so r/o and r/w
17:37:07 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: NUMA-aware live migration https://review.openstack.org/552722
17:37:20 mriedem which is related to https://review.openstack.org/#/c/552078/
17:38:36 mriedem ildikov: heh look familiar? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3554
17:38:54 kashyap cfriesen: I'll respond on the review.
17:38:55 sean-k-mooney[m] mriedem: yes its the modes that i was think of. i was wonder if one of the other nodes would becomre r/w but i guess that would be an explcit call if you wantted that to happen not somethign that magically happend if you shutdown a r/w instacne or shelved it
17:39:25 mriedem correct, there is no auto-change of the mode when one attachment goes away
17:39:38 mriedem that is discussed as an option for attachment counting in https://review.openstack.org/#/c/552078/
17:40:42 sean-k-mooney[m] mriedem: lol how may volume specs do we have for this cycle :)
17:41:11 sean-k-mooney[m] i guess thats only 2 i just feels like more
17:41:35 mriedem volume-backed rebuild, rescue, and backup
17:41:42 mriedem from the same company
17:41:45 mriedem plus mine
17:41:53 mriedem that's nowhere near the number of placement specs
17:43:13 cfriesen kayshap: sorry, distracted by local stuff. yeah, I'm fine with it for the backport. I don't really care personally (mostly use specific cpu models for live migration) but wanted to bring it up just so it was explicitly considered.
17:43:35 sean-k-mooney[m] mriedem: true, am for https://review.openstack.org/#/c/552078/1/specs/rocky/approved/volume-multiattach-enhancements.rst in general do we want to add more multiboot apis to nova? and if so what is the main delta between X servers with volume Y and X servires with Y volumes each?
17:44:57 sean-k-mooney[m] mriedem: that was the other main discussion we had with cinder right. should nova provide a way to consume teh fact that several hadware backend support creating multiple volumes at once to create many servers each with volumes in one call
17:45:16 ildikov mriedem: heh, I guess that's more of a workaround than a leftover...
17:46:51 kashyap cfriesen: No problem. So quick point: 'host-model' + PCID doesn't make sense anyway:
17:47:29 kashyap cfriesen: If QEMU already supports PCID, it would be enabled by 'host-model'. And if it's not supported, adding it doesn't make it magically appear :-)
17:49:37 efried cdent: "Steal an extra space from efried and put it here." Dick.
17:50:18 edleafe efried: I wouldn't *dream* of ever breaking up your double spaces!

Earlier   Later