| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 13:28:26 | mriedem | clarkb: here we go https://review.openstack.org/#/c/458843/ | |
| 13:28:27 | cdent | https://www.youtube.com/watch?v=kerUbfOQTW0 | |
| 13:29:16 | mriedem | one of you can be the weird hairy english sheep dog, | |
| 13:29:24 | mriedem | and i can be the american coyote | |
| 13:29:31 | mriedem | who gets his ass handed to him daily | |
| 13:31:40 | mriedem | johnthetubaguy: dansmith: leakypipes: has anyone proposed the concept of dedicated hosts in nova before? i have to assume it's come up, but i don't remember | |
| 13:31:54 | johnthetubaguy | yeah, HP folks did | |
| 13:32:08 | mriedem | do you remember a spec for it? | |
| 13:32:43 | johnthetubaguy | it was all aggregate wrangling if I remember, it might be pre-specs? | |
| 13:32:47 | mriedem | https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates | |
| 13:32:52 | mriedem | ^ was cern | |
| 13:32:57 | mriedem | https://blueprints.launchpad.net/nova/+spec/whole-host-allocation | |
| 13:32:59 | mriedem | ^ was HP | |
| 13:33:17 | johnthetubaguy | ah, the second one is what I thought you meant | |
| 13:33:32 | mriedem | https://blueprints.launchpad.net/nova/+spec/multi-tenant-exclusion-filter | |
| 13:33:34 | johnthetubaguy | yeah, I think it was phil talking about that | |
| 13:33:49 | mriedem | https://blueprints.launchpad.net/nova/+spec/hide-exclusive-availability-zone | |
| 13:33:50 | mriedem | ha | |
| 13:33:53 | mriedem | the list goes on | |
| 13:34:14 | johnthetubaguy | we did something like the cern and last one downstream | |
| 13:34:15 | mriedem | https://blueprints.launchpad.net/nova/+spec/support-dedicate-hosts-when-boot | |
| 13:34:25 | johnthetubaguy | yeah, thats the whole-host-allocation one | |
| 13:34:33 | johnthetubaguy | there are two separate issues mixed in there | |
| 13:34:49 | mriedem | i figured this could be done with dedicated aggregates/AZs and filters | |
| 13:35:07 | johnthetubaguy | "I want only my VMs on each hypervisor", "assign some hosts to a sub-set of tenants" | |
| 13:35:21 | johnthetubaguy | depends how dynamic you want it | |
| 13:35:45 | cdent | andymccr, efried: that code is going to be the shiniest thing ever | |
| 13:35:51 | johnthetubaguy | the HP plan (memory is fuzzy) was that you pick the host by the first instance that lands there "owns" that box | |
| 13:36:56 | mriedem | johnthetubaguy: interesting, but what if the box isn't big enough for all of the instances the tenant wants to take over on that box? delete and find a new one? or create server groups to do this? | |
| 13:37:08 | cdent | johnthetubaguy, mriedem : ironic wants a similar kind of thing for baremetal | |
| 13:37:08 | cdent | i linked the spec in the latest rp update | |
| 13:37:22 | johnthetubaguy | mriedem: it was simpler than that | |
| 13:37:45 | johnthetubaguy | cdent: but when you get an ironic host, you get all the resources regardless, or do you mean reserving some for a particular tenant? | |
| 13:38:03 | mriedem | cdent: not seeing it | |
| 13:38:15 | johnthetubaguy | mriedem: well, by simpler, I mean, you cheat, if it doesn't fit on the host, you then get another host to pay for | |
| 13:38:23 | mriedem | johnthetubaguy: oh i see | |
| 13:38:36 | cdent | mriedem: I'll find the real link | |
| 13:38:41 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: WIP: Specify keymap on server boot (1/2) https://review.openstack.org/458752 | |
| 13:39:12 | johnthetubaguy | mriedem: there was talk of per project flavors being allowed, so the divide the hosts they pay for up however they want... got super messy really fast | |
| 13:39:17 | mriedem | so apparently phil's proposal was accepted at one point | |
| 13:39:52 | mriedem | HP public cloud wanted it, rax public cloud had it, and huawei public cloud has something too downstream, which is why i'm asking about it | |
| 13:39:52 | cdent | mriedem, johnthetubaguy https://review.openstack.org/#/c/415512/ | |
| 13:40:14 | cdent | figleaf and I had some fairly meandering comments and then leakypipes came along and set everyone straight | |
| 13:40:27 | leakypipes | saw ah? | |
| 13:40:33 | leakypipes | say wha? | |
| 13:40:45 | johnthetubaguy | cdent: ah... right | |
| 13:41:06 | johnthetubaguy | cdent: thats similar to the host assignment case | |
| 13:41:41 | johnthetubaguy | mriedem: I am missing the business context on some of this, it sounds like better quotas would fix the ironic case | |
| 13:42:39 | mriedem | i think it could be solved with tenant isolation filters and image meta, | |
| 13:42:53 | mriedem | i.e. your tenant has access to these images which are configured to only work on certain host aggregates | |
| 13:43:06 | mriedem | thereby you can only boot servers in those hosts | |
| 13:43:20 | mriedem | phil says similar in https://review.openstack.org/#/c/38156/ | |
| 13:43:25 | mriedem | it puts a burden on the operator | |
| 13:44:39 | johnthetubaguy | mriedem: the problem is to automate that, you need to filer all create server requests, to make sure you just in time provision the extra hosts they might need, but maybe thats not really how it works, people probably have to buy the hosts via some other system. | |
| 13:51:47 | stvnoyes | mriedem: johnthetubaguy: re: https://review.openstack.org/#/c/438750 - did you guys come to an agreement on whether something needs to done about the concern on begin_detaching? I looked thru the flows and i *think* it's ok for both the new flow and old flow. | |
| 13:52:27 | johnthetubaguy | stvnoyes: I thought the previous consensus was its not allowed in the new flow, as it doesn't work for multi-attach, etc | |
| 13:53:00 | mriedem | johnthetubaguy: ildikov was supposed to talk to jgriffith about that | |
| 13:53:10 | johnthetubaguy | ah, right, that was the action | |
| 13:53:25 | mriedem | but we did seem to get two answers on whether or not it would work in the new API model during the meeting yesterday | |
| 13:54:04 | stvnoyes | would that mean that detaching would no longer ever be a valid status? | |
| 13:54:15 | mriedem | i'd think it could be at least for a single attachment | |
| 13:54:18 | mriedem | i.e. not multiattach | |
| 13:54:29 | stvnoyes | ok got it | |
| 13:54:32 | johnthetubaguy | mriedem: maybe that... not sure | |
| 13:54:37 | mriedem | maybe the concern is that with multiattach you could go from in-use > detaching > in-use again | |
| 13:54:41 | johnthetubaguy | but we need a solution that works for multi-attach | |
| 13:54:43 | mriedem | if yo'ure going from 2 to 1 attachments | |
| 13:54:59 | mriedem | if you have one attachment, you go in-use > detaching > available | |
| 13:55:00 | johnthetubaguy | well the detaching status would have to be per attachment, I believe | |
| 13:55:09 | mriedem | i'm looking up their data model | |
| 13:55:24 | johnthetubaguy | well, its on the volume today, which I guess is the problem | |
| 13:55:33 | johnthetubaguy | but well worth a check | |
| 13:55:34 | ildikov | johnthetubaguy: I think begin_detaching is on another layer than the attachment calls TBH, therefore keeping it for that state change should be fine | |
| 13:55:38 | mriedem | having said this, when ildikov did multiattach before, begin_detaching worked, but it did in-use > detaching > in-use | |
| 13:55:56 | ildikov | johnthetubaguy: couldn't catch jgriffith yesterday, but I will try next week, he's out today | |
| 13:55:58 | openstackgerrit | sahid proposed openstack/nova master: numa: fix an uninitialized local variable https://review.openstack.org/458848 | |
| 13:56:44 | ildikov | mriedem: yep, we can say we don't want two detach happen at the same time, by which that state machine makes sense | |
| 13:56:47 | johnthetubaguy | mriedem: that works if we only allow people to detach one attachment at once, thats not terrible | |
| 13:57:00 | mriedem | does hemna know? | |
| 13:58:09 | stvnoyes | the new VolumeAttachmentNotFound exception in that change will be needed in other work. I may just put add that exception as a new review to remove the dependency so I can move forward | |
| 13:58:25 | mriedem | there is an attach_status on the volume_attachment table in cinder | |
| 13:58:37 | mriedem | stvnoyes: hold up for now | |
| 13:58:43 | johnthetubaguy | oh... | |
| 13:58:54 | stvnoyes | mriedem: ok | |
| 13:59:01 | mriedem | johnthetubaguy: given this is an open question and begin_detaching is in the api, and what this patch is doing is in the compute side, i don't think we need to hold it up | |
| 13:59:20 | mriedem | johnthetubaguy: this patch is at the bottom of the call chain and has to assume the api has done whatever it needed to do, right? | |
| 13:59:41 | johnthetubaguy | mriedem: yeah, I am not against leaving this as an open question, we do need to keep moving here | |
| 14:00:21 | mriedem | we also get the attach status back when showing details about a volume attachment | |
| 14:00:41 | ildikov | mriedem: I agree, I don't think we decided how to deprecate exactly what, begin_detaching can still fit as it does today | |
| 14:00:50 | johnthetubaguy | but we don't pass the attachment_id in begin_detaching? | |
| 14:00:56 | johnthetubaguy | its just the volume_id? | |
| 14:01:00 | mriedem | i think regardless of what happens, cinder api deals with the multiattach case if begin_detaching is called | |
| 14:01:01 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288 | |
| 14:01:05 | stvnoyes | just the volume is passed in | |
| 14:01:07 | mriedem | johnthetubaguy: volume id | |
| 14:01:30 | johnthetubaguy | mriedem: you are right though, this is the API, its not our problem | |
| 14:02:12 | johnthetubaguy | mriedem: so didn't see your comment in the patch till now | |
| 14:02:32 | ildikov | volume_id should be fine for begin_detaching IMHO | |
| 14:02:54 | ildikov | at least from overall behavior perspective | |
| 14:03:48 | johnthetubaguy | well, it does disallow multiple detatch of the same volume, because we can't no which one it is | |