Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-25
12:46:59 gmann Kevin_Zheng: cool thanks
12:50:02 alex_xu gmann: thanks for the review!
12:50:36 gmann alex_xu: np!
12:52:25 openstackgerrit Zhenyu Zheng proposed openstack/nova: Add new policy for server list/detail with all_tenants https://review.openstack.org/415330
12:59:22 Kevin_Zheng https://review.openstack.org/#/c/421760/
12:59:41 Kevin_Zheng ^ please also review the doc patch?
13:01:50 openstackgerrit Balazs Gibizer proposed openstack/nova: Fix race condition in instance.update sample test https://review.openstack.org/424574
13:02:58 alex_xu nova api meeting is running
13:41:19 bauzas cdent: have you seen our discussion with matt yesterday and the conclusion email ?
13:41:42 bauzas cdent: we agreed on rather asking to modify the allocation ratios
13:42:01 bauzas cdent: so I needed to modify a functional test for server_groups
13:42:09 bauzas cdent: but I discovered a problem
13:42:28 bauzas cdent: when having an allocation, it still doesn't work because we also verify the max unit
13:42:38 bauzas which is not changed if using the ratio
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 bauzas for those tests
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: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 Kevin_Zheng cdent: hi, since you are here, is this an issue? https://bugs.launchpad.net/nova/+bug/1658868
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: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?

Earlier   Later