Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
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
17:58:45 mriedem so with attach_mode in the bdm,
17:58:53 mriedem well, nvm
17:59:10 mriedem bdms aren't indexed per server in the create request
17:59:42 mriedem but i was going to say, i could create 3 instances in a single request, with 3 bdms to the same multiattach volume, but only one has the r/w attachment, and the other two are r/o
18:00:10 sean-k-mooney[m] ya ok well its looks like a parity thing to me not a really large change in the semantics of the api you are just allowing seting the volume and attachment mode when making the multi boot request
18:00:45 mriedem any boot request, including multi
18:00:46 mriedem yes
18:00:57 mriedem but as noted ^ the bdms aren't indexed in a multicreate request,
18:01:06 mriedem so the bdm attach_mode would be the same for all of them
18:01:54 sean-k-mooney[m] mriedem: is that what teh sepc what to allow or what you can do today. today you would have to do that with 3 nova boot requests correct?
18:02:11 mriedem if you wanted them to each have different attach modes, yes
18:02:28 mriedem i'm not proposing that we change the bdm semantics in multicreate server to be indexed
18:02:29 sean-k-mooney[m] mriedem: and do you want ot allow somthing like boot 10 instance and have 4 r/w and 6 r/o or is that out of scope
18:02:36 mriedem that's out of scope
18:02:41 sean-k-mooney[m] ah they would all have the same mode
18:02:55 sean-k-mooney[m] ya mixing modes would be messy on the comandline and in the api
18:02:57 mriedem the list of bdms in the server create request are copied per instance that gets created
18:04:22 sean-k-mooney[m] so is it basically just a check in the api that says you can pass a volume on multi boot today?
18:04:40 efried edleafe: commented on https://review.openstack.org/#/c/556971/
18:04:44 mriedem sean-k-mooney[m]: can't
18:04:45 mriedem but yes
18:04:51 mriedem it's linked from the spec i believe
18:04:59 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: add a note about volume-backed rescue not being supported https://review.openstack.org/556996
18:06:32 sean-k-mooney[m] mriedem: cool ill read it properly later. it makes sense to me how you discibe it
18:08:58 edleafe efried: thanks. Will update shortly
18:11:37 mriedem stephenfin: we don't need this mypy spec do we? https://review.openstack.org/#/c/538217/ i thought you already started making those changes, much to my chagrin
18:12:21 mriedem s/chagrin/vexation/
18:12:24 mriedem thanks google
18:14:22 efried 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." Sorry, I let this scroll by...
18:14:38 efried cfriesen: Yes, something like that would make sense. But we don't have that in the plan at the moment.

Earlier   Later