Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
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 mriedem since snapshot for a volume-backed instance is different in the api
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: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 kashyap cfriesen: Does that sound reasonable to you?
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: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!
17:50:48 efried edleafe: That's right. They're MINE.
17:52:39 edleafe efried: Hey, I don't want to be the only one who people think grew up on typewriters instead of computers
17:53:08 efried These young whippersnappers don't understand us edleafe
17:54:04 mriedem sean-k-mooney[m]: i don't know what you're saying
17:54:57 mriedem sean-k-mooney[m]: this isn't nova creating multiple servers and multiple multiattach volumes, nova doesn't create multiattach volumes,
17:54:58 sean-k-mooney[m] mriedem: your spec is suggesting allow boot 10 instance with this multiattach volume
17:55:09 mriedem it's boot from volume with an existing multiattach volume that can be attached to more than one server
17:56:35 mriedem sean-k-mooney[m]: if an admin doesn't want to allow multiattach bfv, they can control that via policy volume:multiattach_bootable_volume
17:56:38 sean-k-mooney[m] mriedem: in the cindier cross project meeting they where also a request for can i create 10 instance each with 1 voume each
17:56:56 mriedem sean-k-mooney[m]: that was multicreate
17:57:30 mriedem as far as i know, you can create 10 volume-backed instances in a single server create request today
17:57:36 mriedem as long as nova is creating the volumes
17:57:41 mriedem if it's a pre-existing volume, we don't allow that
17:57:57 mriedem because that flow does not (yet) support multiattach volumes
17:57:57 sean-k-mooney[m] mriedem: for your spec you would create the multi attach volume in cinder first the ask nova to boot 10 instance each using that multi attach volume
17:58:04 mriedem yes
17:58:09 sean-k-mooney[m] mriedem: yes the other usecase was multi create

Earlier   Later