| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 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! | |
| 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 | 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:57:57 | mriedem | because that flow does not (yet) support multiattach volumes | |
| 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. | |
| 18:16:35 | efried | cdent, edleafe, jaypipes: How do you feel about the granular microversion changing the response payload to something like ^ to preserve the division of the requests? | |
| 18:17:22 | efried | gibi has already identified a place where that would be useful. | |
| 18:17:23 | cdent | efried: which response payload are you talking about? | |
| 18:17:39 | efried | cdent: The response from GET /a_c | |
| 18:17:52 | edleafe | efried: the purpose of the granular request is to ensure that each of those requirements is met by a single RP. What would be the advantage of splitting the out if it turns out that they are the same RP? | |
| 18:17:54 | cdent | a_r or p_s? | |
| 18:17:55 | efried | cdent: The format of an allocation_request, I think. | |
| 18:18:04 | efried | a_r, definitely not p_s | |