| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 12:34:37 | ralonsoh | sfinucan, thank you! | |
| 12:35:07 | sfinucan | ralonsoh: Definitely. I'm sure Jay would be ecstatic to have someone working on that :) | |
| 12:37:35 | efried | sdague Thanks for watching the PowerVM changes :) | |
| 12:38:57 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729 | |
| 12:39:30 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288 | |
| 12:39:59 | sfinucan | mdbooth: done and done. Thanks for addressing that small comment | |
| 12:40:27 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: console https://review.openstack.org/409402 | |
| 12:41:01 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: SSP emphemeral disk support https://review.openstack.org/443189 | |
| 12:41:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: WIP: Specify keymap on server boot (1/2) https://review.openstack.org/458752 | |
| 12:41:27 | efried | sdague ^^ Rebased up through "SSP ephemeral disk support". | |
| 12:41:54 | leakypipes | ralonsoh: hey, I'm here :) | |
| 12:42:38 | sfinucan | oops | |
| 12:42:45 | ralonsoh | leakypipes: I was talking to Stephen about a patch I submitted https://review.openstack.org/#/c/427145/ | |
| 12:43:29 | ralonsoh | leakypipes: it's an small optimization. The point is if the memoize function could be useful to store in cache and optimize some parts of resourde providers | |
| 12:43:43 | sdague | efried: ok, cool, I'll back through them in a minute | |
| 12:43:54 | efried | sdague Awesome. | |
| 12:43:59 | ralonsoh | leakypipes: let me know if you know any interesting place to use it | |
| 12:44:32 | johnthetubaguy | sfinucan: +1 | |
| 12:45:05 | leakypipes | ralonsoh: will do. :) | |
| 12:45:22 | zioproto | dansmith: I have been in meetings the all day... later I hope to find time to clean that broken database we have seen yesterday, I will keep you updated | |
| 12:45:23 | ralonsoh | leakypipes: thanks! | |
| 12:52:39 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 12:52:40 | openstackgerrit | sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 12:52:40 | openstackgerrit | sahid proposed openstack/nova master: network: add command to configure trusted mode for VFs https://review.openstack.org/458513 | |
| 12:53:21 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures https://review.openstack.org/458807 | |
| 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 | i linked the spec in the latest rp update | |
| 13:37:08 | cdent | johnthetubaguy, mriedem : ironic wants a similar kind of thing for baremetal | |
| 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 | cdent | mriedem, johnthetubaguy https://review.openstack.org/#/c/415512/ | |
| 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: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 | |