| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 17:37:23 | dansmith | which could be a problem in real life, | |
| 17:37:40 | dansmith | if configured so that one instance can't take more than 25% of a host, but a resize would technically take 50% in a single allocation | |
| 17:37:49 | dansmith | which would be solved by my migration uuid thing | |
| 17:40:26 | bauzas | dansmith: mriedem: just saw the above discussion about whether the scheduler should know the virt logic and the move ops, tbc MHO is * NOOOOOOO * | |
| 17:40:38 | bauzas | because we have conductors for that | |
| 17:40:54 | bauzas | not for virt stuff, but at least knowing whether it's a move or a boot | |
| 17:41:13 | bauzas | scheduler should just give you a destination, whether it's for a move or a boot, that's it | |
| 17:42:09 | bauzas | if we need more reasons why we need to do that, I don't want to hit your wounts, but that's why we first tried to claim by the conductors... | |
| 17:42:22 | bauzas | anyway | |
| 17:47:14 | dansmith | oye, the fake driver is only reporting one vcpu for some reason | |
| 17:50:45 | dansmith | ohh | |
| 17:56:16 | mriedem | dansmith: yeah hadn't gotten to the resize functional tests yet | |
| 18:00:35 | mriedem | dansmith: i can start rebasing my change on top of gibi's test, unless i need to hold off for something | |
| 18:02:08 | dansmith | mriedem: already done | |
| 18:02:31 | dansmith | I didn't realize we used SmallFakeDriver everywhere, which only has one vcpu | |
| 18:02:35 | dansmith | so I got past that, | |
| 18:02:47 | dansmith | but we will likely have obscure issues with that elsewhere | |
| 18:03:05 | dansmith | like people won't be able to resize to the same host if they have to dip into overcommit for vcpu, which will make no sense to them | |
| 18:04:10 | mriedem | dansmith: ok done locally or...? | |
| 18:04:14 | mriedem | because i don't see those rebased | |
| 18:04:15 | dansmith | yes | |
| 18:04:17 | mriedem | ok | |
| 18:04:45 | mriedem | i think i'll start building on https://review.openstack.org/#/c/490085/ with handling shared storage in resize to same host, see how terrible that looks | |
| 18:04:57 | mriedem | won't push anything though | |
| 18:07:15 | openstackgerrit | Ed Leafe proposed openstack/nova master: Handle addition of new nodes/instances in ironic flavor migration https://review.openstack.org/487954 | |
| 18:27:35 | dansmith | mriedem: so I'm making your patch work on top of gibi's tests (or rather adjusting gibi's test for what you fix) | |
| 18:27:51 | dansmith | and then jay's can go on top of that, with a fix for the compute node part | |
| 18:31:19 | mriedem | alright | |
| 18:31:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Test resize to same host with placement api https://review.openstack.org/489973 | |
| 18:31:22 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Sum allocations in the scheduler when resizing to the same host https://review.openstack.org/490085 | |
| 18:31:26 | dansmith | mriedem: ^ | |
| 18:32:07 | mgagne | We used to rely on a custom image props in our out-of-tree virt driver in Nova kilo. With the oslo.versionedobjects migration, I found (testing against Mitaka) that ImageMetaProps has a list of hardcoded supported properties and I can no longer inject or read our custom property. What's the best way for us to use our custom prop in Nova? | |
| 18:37:19 | mriedem | mgagne: upstream your image meta prop | |
| 18:37:35 | jaypipes | dansmith, mriedem, cdent: hi folks. just back from jury duty. | |
| 18:37:46 | mgagne | okay =( | |
| 18:38:00 | cdent | jaypipes: did you manage to get excluded? | |
| 18:38:32 | jaypipes | cdent: no. just sat there for 7 hours in the jury pool and the judge released everyone who hadn't been selected to a jury | |
| 18:38:50 | cdent | fun! | |
| 18:39:17 | mriedem | jaypipes: did you at least make some friends? | |
| 18:39:44 | jaypipes | dansmith, mriedem, cdent: someone please fill me in on the latest? I was in the process of fixing up the remaining little test failures on the 1707071 bug patch. do I need to pull fresh? did anyone push any more changes on those patches? | |
| 18:40:01 | dansmith | jaypipes: I'm working on it right now | |
| 18:40:18 | jaypipes | dansmith: ok thanks Dan. I'll wait on a pull then. | |
| 18:40:32 | jaypipes | dansmith: anything I should be aware of or be working on? | |
| 18:41:01 | mriedem | gibi has a patch for resize to same host | |
| 18:41:06 | jaypipes | k | |
| 18:41:06 | mriedem | w/o shared storage | |
| 18:41:16 | mriedem | i've got a wip for accounting for resize to same host w/o shared storage in the scheduler | |
| 18:41:23 | mriedem | dan just rebased those to be lined up | |
| 18:41:31 | mriedem | he's working on rebase your change on top of mine | |
| 18:41:44 | mriedem | i'm working on handling shared storage with resize to same host | |
| 18:42:31 | jaypipes | ok, will wait for further instructions. | |
| 18:42:47 | dansmith | I guess jay's patch didn't even pass the gibi tests from yesterday? | |
| 18:42:59 | dansmith | I should have fixed that first I guess, because now it fails everything | |
| 18:43:01 | jaypipes | dansmith: yes, they were. | |
| 18:43:07 | dansmith | https://review.openstack.org/#/c/488510/12 | |
| 18:43:15 | dansmith | not according to that, afaict | |
| 18:43:30 | dansmith | oh, nm, | |
| 18:43:34 | jaypipes | dansmith: gibi's tests work. | |
| 18:43:35 | dansmith | that's the ironic/ocata whatever | |
| 18:43:43 | jaypipes | dansmith: there was an ocata ironic failure I was looking into | |
| 18:43:45 | dansmith | hmm, well, not sure why they don't here then | |
| 18:47:30 | openstack | Launchpad bug 1708205 in OpenStack Compute (nova) "placement allocation representation asymetric on PUT and GET" [Low,Confirmed] | |
| 18:47:30 | cdent | jaypipes: I made a bug for that thing you just commented on, so we have it for future reference: https://bugs.launchpad.net/nova/+bug/1708205 | |
| 18:47:42 | mriedem | problem in https://review.openstack.org/#/c/490085/2/nova/tests/functional/test_servers.py | |
| 18:47:45 | jaypipes | cdent: cool. | |
| 18:48:31 | dansmith | jaypipes: there's another problem, btw | |
| 18:48:57 | dansmith | jaypipes: let's say you have a compute node with 4 vcpus total, overcommit ratio of 16 like default | |
| 18:49:05 | dansmith | jaypipes: and you have an instance there with three vcpus | |
| 18:49:12 | dansmith | and want to do a same-host resize | |
| 18:49:32 | dansmith | you'll fail to get a doubled allocation because the single-instance allocation on that host will be >max_unit | |
| 18:49:58 | jaypipes | dansmith: ooh, yeah, certainly didn't think of that. nice catch... | |
| 18:50:24 | dansmith | also solved by my migration claim idea, fwiw | |
| 18:50:45 | jaypipes | dansmith: however, there would still be two separate allocation records, though, right? which would individually be <max_unit, yes? | |
| 18:50:54 | dansmith | no | |
| 18:50:55 | mriedem | no same host | |
| 18:50:56 | dansmith | single instance | |
| 18:50:57 | mriedem | same rp | |
| 18:51:00 | dansmith | right | |
| 18:51:00 | jaypipes | oh, yeah, doh. | |
| 18:51:00 | dansmith | against the same rp | |
| 18:51:05 | jaypipes | yup, sorry. | |
| 18:51:37 | jaypipes | dansmith: yes, your migration UUID idea would indeed solve that. ++ | |
| 18:51:38 | cdent | what’s the chances of leap know to a migration claim? is that completely off the table? | |
| 18:51:55 | jaypipes | cdent: leap know? | |
| 18:51:58 | dansmith | leap know what now? | |
| 18:52:18 | cdent | sorry, homophones | |
| 18:52:28 | jaypipes | who you calling a homophone? | |
| 18:52:45 | cdent | leap now to use migration claims, instead of trying to work around all these constraints | |
| 18:52:59 | dansmith | it's a lot of change | |
| 18:53:06 | dansmith | to scheduling and the db schema, etc | |
| 18:53:07 | jaypipes | cdent: yeah, what dansmith said. | |
| 18:53:20 | dansmith | not that we're not making lots of change to fix these issues, but.. it's scary(er) | |
| 18:53:23 | jaypipes | plus there's the issue of still needing to handle ocata migrations... | |
| 18:53:31 | jaypipes | ocata to pike migrations, that is. | |
| 18:53:49 | cdent | yeah, dansmith, I’m not entirely sure which is really scarier | |
| 18:54:29 | jaypipes | dansmith, mriedem: do we still need a patch testing that when ocata computes are in the mix, that pike computes continue to behave badly? if so, I can begin work on that. | |
| 18:54:44 | mriedem | i'll ask for the 7th time, couldn't we handle the ocata->pike issue by not claiming in the scheduler until everything in the compute is working the way we want and restrict the claim in the scheduler until the computes are all >=pike? | |
| 18:54:59 | mriedem | feel free to just say no again :) | |
| 18:55:07 | dansmith | mriedem: and again, it doesn't change anything if we don't claim first | |
| 18:55:15 | dansmith | ocata will still stomp on everything | |