| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 12:54:42 | lyarwood | mdbooth: posted some comments in the change, basically I was going to follow up with another change for resize failures as we can't just disconnect the new volume at that point. | |
| 12:56:09 | sdague | efried: there is an oslo_utils method for something in patch #4 | |
| 12:58:28 | mdbooth | lyarwood: That's an excellent point. | |
| 13:00:20 | openstackgerrit | Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710 | |
| 13:12:09 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/458834 | |
| 13:13:02 | efried | andymccr For the love of all that is holy, at some point you gotta tell us to bugger off and merge your patch already. | |
| 13:16:44 | mriedem | o/ | |
| 13:18:31 | rpodolyaka | mriedem: hey! could you please take a look at https://review.openstack.org/#/c/458837/? Am I missing something or "?h=stable/newton" part was just missed in the original change? | |
| 13:19:57 | mriedem | was probably just missed, and i bet newton was master when that was added to novaclient | |
| 13:20:34 | rpodolyaka | ack, thanks! | |
| 13:23:08 | mriedem | cdent: johnthetubaguy: congrats on your TC glory | |
| 13:23:30 | mriedem | as PTL i will promise to fight your TC decisions at every turn | |
| 13:23:45 | johnthetubaguy | mriedem: I wouldn't want anything less | |
| 13:25:40 | cdent | mriedem: from the fires of conflict truth will rise | |
| 13:26:15 | mriedem | it'll be like those looney toons characters that clock in each day to fight each other | |
| 13:26:21 | mriedem | but are buddies before and after | |
| 13:26:52 | dansmith | zioproto: cool | |
| 13:27:42 | mriedem | clarkb: i don't suppose we ever backported your nova fix for the live migration job setup to stable/ocata | |
| 13:27:55 | cdent | mriedem: perfect | |
| 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 | |