| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 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. | |
| 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 | |
| 18:18:37 | cdent | efried: I'm not visualizing what you're really suggesting, could you paste something somewhere, or link me to some context? | |
| 18:18:56 | cdent | (I'm stuck on "how is this different from what we already do") | |
| 18:19:54 | efried | cdent: edleafe: The example I gave above was: resources1=VF:1,BW:200&resources2=VF:1,BW:300 may result in an allocation_request like RP_X: { VF: 2, BW: 500 }. Without consulting the original request (which, as in gibi's neutron case, may not be available), the caller can't tell that one VF should get BW:200 and the other should get 300. | |
| 18:20:47 | efried | cdent, edleafe: So the suggestion is that the response should instead look like: { resources1: { RP_X: { VF: 1, BW: 200} }, resources2: { RP_X: { VF: 1, BW: 300 } } } | |
| 18:21:02 | cdent | efried: and in this case we're on the same pf, and it is the pf that is being the resource provider, yes? | |
| 18:21:09 | efried | cdent: yes | |
| 18:21:23 | efried | RP_X is a PF provider of VF and BW resources. | |
| 18:21:36 | cdent | efried: does the caller still know the request it made? | |
| 18:21:49 | cdent | or still have whatever info it used to make the call? | |
| 18:22:02 | efried | cdent: That depends on the scenario. But in general ima say no. | |
| 18:22:30 | sean-k-mooney[m] | mriedem: regarding https://review.openstack.org/#/c/532410/4/specs/rocky/approved/volume-backed-server-rescue.rst i think they just want to do a normal image based nova rescue but for boot from volume instance. so the image size bits of the spec are just saying the rescue image is not empty | |
| 18:22:31 | gibi | cdent: neutron provide resource request pieces via the neutron port API, nova combines them to one big a_c request | |
| 18:23:15 | cdent | In general ima say that changing the allocation format again would make me sad, especially to represent granular stuff which seems icky somehow (will have to think a bit longer on why). Which is not "god no, I hate that" but rather "hmm, I'm not immediately in love with this" | |
| 18:23:26 | efried | cdent: I think the compute manager is the thing that builds the request, and the report client sends it down and gets the response, but the thing that needs to correlate the allocations to real resources is the virt driver (or in gibi's case, neutron (maybe a neutron agent)), and we're not giving that information to those guys. | |
| 18:24:04 | cdent | I'm uncomfortable with placement being use as state manager for the interaction between nova and neutron | |
| 18:24:16 | efried | eh, state manager? I don't see that. | |
| 18:24:43 | efried | All we're doing is providing the caller of GET /a_c with more detailed information about how the allocation_request was fulfilled. | |
| 18:24:54 | sean-k-mooney[m] | cdent: well its not state management. we just need to know how to correlate placement RP inventory to phyical resouce on the host | |
| 18:25:03 | efried | I.e. I took *this* request group to make *this* chunk of allocations. | |
| 18:25:53 | cdent | sounds like communicating state by proxy to me but maybe I'm peculiar | |
| 18:25:56 | efried | cdent: In the case of the virt driver, he can *probably* glean that information by looking back at the flavor... but now we also have resources/traits in the image, and gibi will also have them in the port, and future us may have... So asking virt to reconstruct all of that, which we currently do in nova, seems like a really bad idea. | |
| 18:26:49 | efried | cdent: It's not state. I see it as the difference between, "You asked for X and Y. Here's XY," and "You asked for X and Y. Here's X, Y." | |
| 18:27:34 | cdent | who is making the request for allocations in the example you gave? | |
| 18:27:40 | cdent | sorry candidates | |
| 18:27:53 | efried | the scheduler report client is the thing making the placement API call. | |
| 18:28:14 | cdent | right so nova is asking placement to construct data in a particular way so it can communicate something to nova | |