| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 13:43:34 | cdent | bauzas: max unit shouldn't have anything directly to do with allocation ratio, can you explain what you mean a different way? | |
| 13:43:42 | bauzas | I mean https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L615 | |
| 13:44:10 | bauzas | cdent: okay, so the problem is when operators don't use legacy filters in Newton | |
| 13:44:21 | bauzas | ie. the CoreFilter or the DiskFilter | |
| 13:44:32 | bauzas | then in case you don't have enough resources, it's fine | |
| 13:44:42 | bauzas | the scheduler would still give you destinations | |
| 13:45:07 | bauzas | now that we have the placement call, it's asking for both VCPU, mem and disk | |
| 13:45:17 | bauzas | as we agreed on not optionally ask for them | |
| 13:45:22 | bauzas | but | |
| 13:45:45 | bauzas | given the solution was to say 'just amend the ratio and put for example 9999.0', it would still work for Newton | |
| 13:45:57 | bauzas | because for example CoreFilter doesn't verify the max unit | |
| 13:46:14 | bauzas | but when upgrading to Ocata, then the placement API wouldn't return that destination | |
| 13:46:25 | bauzas | because we now verify also by max unit | |
| 13:46:31 | bauzas | se ? | |
| 13:46:49 | bauzas | lemme upload two changes and hopefully you'll understand | |
| 13:47:03 | cdent | I'm still not seeing how max unit is involved in wha you are describing. it is the max for an individual request | |
| 13:51:18 | bauzas | cdent: sec, uploading my branch | |
| 13:53:38 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961 | |
| 13:53:39 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Fix server group functional test by using all filters https://review.openstack.org/425185 | |
| 13:54:12 | bauzas | cdent: see the bottom patch https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L615 | |
| 13:54:13 | bauzas | oops | |
| 13:54:20 | bauzas | cdent: https://review.openstack.org/425185 | |
| 13:55:54 | cdent | bauzas: I'm looking but I still don't get where max_unit is involved? | |
| 13:56:05 | bauzas | cdent: not for that change | |
| 13:56:15 | bauzas | cdent: it will have the functional test +1 | |
| 13:56:18 | kashyap | mdbooth: You might find this interesting, upstream QEMU just merged this command-line switch called '--only-migratable' -- what it does is, if you add any devices to your VM that are _not_ migratable, it'll fail upfront | |
| 13:56:33 | bauzas | cdent: now, the latter change using the scheduler would not agree now | |
| 13:56:39 | mdbooth | kashyap: Nice | |
| 13:56:41 | andreykurilin | bauzas: sorry for disturbing. OpenstackClient, senlinclient teams are blocked by https://review.openstack.org/#/c/418190/ . They want to bump openstacksdk version in g-r, but it will break our gates without that patch | |
| 13:56:41 | bauzas | for those tests | |
| 13:56:43 | kashyap | mdbooth: As an example, trying to add a USB audio device results in: | |
| 13:56:44 | kashyap | ./x86_64-softmmu/qemu-system-x86_64 --only-migratable -nographic -device usb-audio | |
| 13:56:47 | kashyap | qemu-system-x86_64: -device usb-audio: Device usb-audio is not migratable, but --only-migratable was specified | |
| 13:57:13 | bauzas | andreykurilin: I wanted to ask you when you feel it's okay to release a version, but you consider the above blocking ? | |
| 13:58:27 | andreykurilin | bauzas: so we need to merge at least https://review.openstack.org/#/c/424256/ . it is required for our release. You previously put +2, but gates decided that I'm doing something wrong, so I push another patch-set | |
| 13:58:28 | bauzas | cdent: it wouldn't work because of the new calculation we made for GET /RPs here https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L615 | |
| 13:59:08 | andreykurilin | bauzas: https://review.openstack.org/#/c/418190/ doesn't block us. But without it, our functional tests can't work with latest openstacksdk, which is needed for several projects | |
| 13:59:20 | bauzas | ok | |
| 13:59:40 | cdent | bauzas: I'm hearing you say that, what I'm asking is for you to explain why that's the case. | |
| 13:59:47 | cdent | (using words, instead of pointing at code) | |
| 13:59:49 | andreykurilin | bauzas: stevemar put -W for his patch to g-r https://review.openstack.org/#/c/424847/ and waiting for us:) | |
| 14:00:27 | alex_xu | johnthetubaguy: gmann Kevin_Zheng sorry, let us continue at here | |
| 14:00:32 | gmann | yea | |
| 14:00:37 | cdent | bauzas: what matters is that AMOUNT_X is less than max_unit. that's all. | |
| 14:01:31 | gmann | johnthetubaguy: alex_xu another point will be, can we do another microversion in Ocata? i can update code soon but review might be issue | |
| 14:01:35 | andreykurilin | bauzas: also, there is patch with clarification docs (relates to thread - "[openstack-dev] [nova] Device tag in the API breaks in the old microversion"), but it is not critical, just nice to have | |
| 14:01:40 | bauzas | cdent: yup, so lemme clarify | |
| 14:01:50 | openstackgerrit | John Garbutt proposed openstack/nova: Add release note and docs for filter/sort whitelist https://review.openstack.org/421760 | |
| 14:02:05 | bauzas | cdent: previously, we were calculating if (amount + used) was under total * ratio, that's it | |
| 14:02:13 | bauzas | I mean in the legacy filter | |
| 14:02:35 | bauzas | cdent: now the placement method does extra checks, one being that amount is less than max unit, period. | |
| 14:02:43 | cdent | correct | |
| 14:02:45 | johnthetubaguy | gmann: it does seem too close to the wire, but also feels less urgent than the other pieces of the puzzle | |
| 14:02:58 | cdent | those values are set the "real" values on the compute node | |
| 14:03:00 | bauzas | cdent: if so, we can't say to operators to just modify their ratios in order to get the same behaviour | |
| 14:03:13 | cdent | it doesn't matter | |
| 14:03:26 | bauzas | cdent: because once the scheduler upgraded to Ocata, it will not return the exact same nodes | |
| 14:03:44 | cdent | an operator could never place a host on a node that had fewer vcpus than requested | |
| 14:03:45 | bauzas | cdent: and hosts that were okay for Newton won't be available per Ocata | |
| 14:03:53 | cdent | but they are not okay | |
| 14:03:54 | bauzas | cdent: people did | |
| 14:04:03 | cdent | how does that even work? | |
| 14:04:14 | bauzas | cdent: because they disabled their filters | |
| 14:04:21 | cdent | can I run an 8vcpu server on a 2 vcpus host? | |
| 14:04:25 | gmann | johnthetubaguy: ok, let me push changes tomorrow and then we can see till where we can go with those | |
| 14:04:33 | bauzas | you can if you don't enable the CoreFilter | |
| 14:04:41 | cdent | that's bonkers | |
| 14:04:59 | bauzas | cdent: yet again, we can be pedantic and say that | |
| 14:05:12 | edleafe | bauzas: you could get that back from scheduler, but it would fail to build | |
| 14:05:13 | bauzas | or we can be pragmatic and find a way that doesn't trample operators | |
| 14:05:17 | alex_xu | gmann: really appreciate that | |
| 14:05:20 | openstack | Launchpad bug 1658868 in OpenStack Compute (nova) "Should raise retry limit exceed error instead of class exist in Placement API" [Undecided,New] - Assigned to Zhenyu Zheng (zhengzhenyu) | |
| 14:05:20 | Kevin_Zheng | cdent: hi, since you are here, is this an issue? https://bugs.launchpad.net/nova/+bug/1658868 | |
| 14:05:21 | cdent | Well a) clearly I don't know enough about what people are doing to have a straight opinion on this stuff, but b) I don't think we should allow bonker-ness, c) I'd defer to matt and dan on this | |
| 14:05:33 | bauzas | edleafe: the claim could | |
| 14:05:40 | cdent | will look in just a sec Kevin_Zheng | |
| 14:05:51 | edleafe | bauzas: the claim could... what? | |
| 14:05:52 | bauzas | edleafe: but the claim takes care of the ratio as a limit | |
| 14:06:12 | bauzas | edleafe: you know the process, right? | |
| 14:06:21 | bauzas | so | |
| 14:06:24 | edleafe | bauzas: yeah, I've seen it once or twice | |
| 14:06:41 | gmann | alex_xu: np! | |
| 14:06:55 | bauzas | okay, so the problem is that we suddently stop supporting something without a clear upgrade path just because we advocate it's bonkers | |
| 14:07:07 | bauzas | that doesn't look a correct answer to me | |
| 14:07:32 | bauzas | since we allowed for a while to opt-out filters | |
| 14:07:48 | edleafe | bauzas: so are you saying that today if you disable CoreFilter, you could successfully build a VM with 8 VCPUs on a 2 VCPU host? | |
| 14:08:15 | bauzas | edleafe: if you live-migrate, yes | |
| 14:08:19 | cdent | the "build a VM" part is the critical question, not what select_destionations does or does not return | |
| 14:08:42 | edleafe | I am unaware of any hypervisor that can do that magic | |
| 14:09:00 | bauzas | let's be clear, you can live-migrate a 8 VCPU VM to a 2 VCPU node | |
| 14:09:08 | johnthetubaguy | bauzas: we can deprecate something, saying its bonkers, and remove it the following cycle | |
| 14:09:08 | bauzas | at least Nova doesn't prevent you to do so | |
| 14:09:21 | bauzas | johnthetubaguy: that was the original approach | |
| 14:09:32 | edleafe | bauzas: but do you get an 8 VCPU vm? | |
| 14:09:42 | bauzas | johnthetubaguy: but I got strong consensus to not do that and rather straight not accepting | |
| 14:09:45 | johnthetubaguy | thats defiantly my preference, because of the release tags we are signed up to | |
| 14:10:14 | bauzas | edleafe: that depends on your driver | |
| 14:10:36 | cdent | Kevin_Zheng: I'll respond on the issue | |
| 14:10:40 | bauzas | edleafe: but whatever the situation is, nova *is* accepting that | |
| 14:10:51 | Kevin_Zheng | cdent: thanks | |