| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 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 | |
| 14:11:01 | johnthetubaguy | bauzas: you have to get an 8 VCPU vm, else it wouldn't live-migrate, as I understand it | |
| 14:11:03 | bauzas | in other words, folks, how can I make that functional test be working when using the placement API ? | |
| 14:11:24 | bauzas | I think there is a big misunderstanding between vcpus and pcpus | |
| 14:11:37 | cdent | bauzas: when you say "accepting that" what do you mean by "that", explicitly? | |
| 14:11:56 | bauzas | cdent: accepting to give you a destination that is not verifying the max unit | |
| 14:11:59 | johnthetubaguy | FWIW, I know rackspace cloud have never run the core filter, we only run the RAM filter | |
| 14:12:11 | bauzas | johnthetubaguy: then you could be in serious touble | |
| 14:12:21 | cdent | bauzas: sure but destinations don't matter, where vms are built does | |
| 14:12:30 | bauzas | johnthetubaguy: see https://review.openstack.org/#/c/417961/24/releasenotes/notes/resource_providers_scheduler_db_filters-16b2ed3da00c51dd.yaml | |
| 14:12:42 | johnthetubaguy | we would just have to set the over-comitt ratio correctly, but thats OK as a warning | |
| 14:12:49 | cdent | that's what I keep trying to clarify here: is the behavior of where vms built actually changing, or just the list of destinations? | |
| 14:12:52 | sahid | johnthetubaguy: i replied to your questions about the patch related to the feature emulator threads | |
| 14:13:11 | sahid | hope that is going to clarify your mind | |
| 14:13:49 | bauzas | johnthetubaguy: cdent: seriously, I'm done | |
| 14:14:09 | bauzas | I'm trying to spot issues that could come up in production and I'm only seeing a "meh, it's bonkers" | |
| 14:14:15 | cdent | bauzas: why? I'm really trying hard to understand the situation. | |
| 14:14:34 | bauzas | cdent: Jenkins will tell you the situation | |
| 14:14:43 | cdent | If it is the case that "the behavior of where vms built actually changing" then we have an issue. | |
| 14:15:08 | cdent | functional tests failing isn't necessarily telling us anything because we've demonstrated time and again (recently) that the functional tests have bad setups. | |
| 14:15:38 | bauzas | cdent: in particular, tbp, some functional tests in the test_server_group testcase won't give you the same exact result once we call the placement service, which is to me a good indicator that placement decisions are not feature-parity between Newton and Ocata | |
| 14:16:11 | cdent | that's a good indicator, but only if we verify that the tests are correct | |
| 14:16:23 | cdent | so I guess the next step is to wait and see what fails and go from there | |
| 14:17:21 | johnthetubaguy | so for folks with the core filter turned off the decisions will be different now we enforce that, it seems to me | |
| 14:17:37 | bauzas | johnthetubaguy: my point indeed | |
| 14:17:49 | bauzas | johnthetubaguy: I spotted that problem in a ML thread | |
| 14:17:49 | johnthetubaguy | bauzas: yep, I am trying to agree with you here | |
| 14:18:01 | johnthetubaguy | bauzas: I liked that first version of your code that dealt with that | |