Posted	Nick	Remark
#openstack-nova - 2018-03-27
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
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.

Earlier   Later