| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 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 | 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:30 | openstack | Launchpad bug 1708205 in OpenStack Compute (nova) "placement allocation representation asymetric on PUT and GET" [Low,Confirmed] | |
| 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 | against the same rp | |
| 18:51:00 | jaypipes | oh, yeah, doh. | |
| 18:51:00 | dansmith | right | |
| 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 | |
| 18:55:31 | mriedem | ocata won't stomp if it's not ocata | |
| 18:55:44 | mriedem | there is nothing to stomp if we don't put down the stompables until >=pike | |
| 18:55:48 | jaypipes | dansmith: plus we've already released Pike software that always does claiming in the scheduler... | |
| 18:56:19 | dansmith | mriedem: they'll stomp on pike things | |
| 18:56:24 | jaypipes | dansmith: so it would be a pain to have to know whether the software installed does or does not do claims | |
| 18:56:47 | dansmith | mriedem: but again, it doesn't solve anything to not do a thing that gets stomped on anyway | |
| 18:56:50 | mriedem | dansmith: aren't we trying to fix the computes to not stomp on things the scheduler is doing? | |
| 18:57:13 | mriedem | like, make the compute aware of shared storage allocations | |
| 18:57:13 | dansmith | mriedem: not really | |
| 18:57:20 | dansmith | not ocata computes | |
| 18:57:26 | mriedem | right, pike computes | |
| 18:57:35 | jaypipes | mriedem: no. we're trying to fix pikes to not stomp on things that other pike computes may have been doing. | |
| 18:57:41 | dansmith | right | |
| 18:57:52 | dansmith | while still being compatible with ocata computes | |
| 18:57:58 | dansmith | and those are somewhat at odds | |
| 18:57:58 | jaypipes | ya | |
| 18:59:23 | mriedem | ok, so again, it's fixing latent bugs which we didn't care about until those latent bugs affected scheduling decisions, which they do now | |
| 18:59:48 | dansmith | they affect ocata scheduler too | |
| 19:00:09 | dansmith | claiming in the scheduler is after the existing decision gets made on the data we're stomping on | |
| 19:00:31 | dansmith | and the stomping just makes placement think there is more room than there is, | |
| 19:00:36 | dansmith | so not claiming doesn't make anything easier | |
| 19:00:44 | dansmith | it makes it less likely to be right, but that's not really useful | |
| 19:01:00 | mriedem | excluding shared storage providers, the computes are eventually consistent aren't they? | |
| 19:01:30 | mriedem | i'll stop asking questions since these are things i've gone in circles on for 2+ weeks now | |
| 19:04:47 | dansmith | I've about got all three patches working together | |
| 19:04:58 | dansmith | which is scary, because I think I was supposed to modify the compute side code to make this work and I haven't done that yet | |
| 19:05:11 | dansmith | (nor do I remember what that was anymore) | |
| 19:05:41 | mriedem | are you fixing the issue in my patch? | |
| 19:06:04 | dansmith | which issue? | |
| 19:06:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Sum allocations in the scheduler when resizing to the same host https://review.openstack.org/490085 | |
| 19:06:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Handle shared storage allocations when resize to same host https://review.openstack.org/490159 | |
| 19:06:30 | mriedem | self.assertFlavorMatcheAllocation | |
| 19:06:37 | mriedem | ^ fixed | |
| 19:07:35 | dansmith | well, I'm just going to push over top of yours | |
| 19:07:38 | dansmith | but yeah I had fixed that | |
| 19:09:57 | dansmith | ooh, nice I'm getting a 500 from placement now | |
| 19:10:40 | cdent | nice work dansmith | |
| 19:11:03 | dansmith | I'll fix this undoubling thing and then push to let you placement peeps look at the 500 | |
| 19:11:23 | cdent | yeah, I can look at that when there are some details | |
| 19:12:58 | mriedem | i'm really confused because https://review.openstack.org/490159 is passing the test i added w/o any code changes to handle it | |
| 19:15:42 | dansmith | mriedem: passing what? it failed gibi's same host tests when I put it on top | |
| 19:16:07 | mriedem | this is the shared storage + resize to same host one | |
| 19:16:18 | mriedem | https://review.openstack.org/#/c/490159/ adds a unit test for that and i expected it to fail | |
| 19:18:17 | mriedem | oh no, i know why it's passing | |
| 19:18:17 | mriedem | heh | |
| 19:18:45 | mriedem | yup | |
| 19:19:15 | mriedem | i'll just squash those changes together | |
| 19:19:27 | dansmith | mriedem: can you hold off? | |
| 19:19:29 | mriedem | cdent: ^ is why i'm looping the allocations | |
| 19:19:35 | mriedem | rather than assuming there is 1 | |
| 19:19:35 | dansmith | I have a bunch of cuts against all three of these patches | |
| 19:19:42 | mriedem | dansmith: like, deep cuts? | |
| 19:19:47 | dansmith | gashes | |
| 19:19:56 | dansmith | with rusty blades | |
| 19:20:10 | mriedem | i meant like https://www.youtube.com/watch?v=KCdKBHdPz30 | |
| 19:20:13 | mriedem | deep cuts | |
| 19:20:18 | dansmith | heh | |