Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-27
15:28:14 mriedem the plan was to disable that by default starting in stein
15:28:27 mriedem so you can't boot a server with a root_gb=0 flavor unless you're doing boot from volume
15:28:35 cdent dansmith: microversions :(
15:28:52 mriedem how are microversions related to this?
15:29:08 dansmith I assume because I messed up a version in my test
15:29:10 cdent (sorry, his test)
15:29:13 mriedem ah
15:29:16 mriedem whew
15:29:48 sean-k-mooney mriedem: right ok cool. if you have existing instces booted that way we sould have to update teh embeeded flavor or resouce dict to indicate or live migration will explode
15:29:51 mriedem sean-k-mooney: so figuring out how we track disk usage for those types of flavors in the resource tracker would be good to know
15:30:05 mriedem because if it was never tracked as usage before, then it's not really a huge regression to not be tracking it in placement
15:30:08 sean-k-mooney mriedem: im pretry sure we track it as 0
15:30:20 sean-k-mooney e.g. we dont track it at all
15:30:42 mriedem sean-k-mooney: i think that too b/c https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1461
15:30:49 mriedem object_or_dict.flavor.root_gb
15:31:00 sean-k-mooney it was a way to bypass qouta in the past
15:31:01 mriedem the is_bfv in there was just recently added in the same series of fixes for the bfv thing
15:31:32 mriedem right, so to summarize, don't set flavor root_gb=0 *unless* those flavors are only used with bfv instances,
15:31:44 mriedem and we have the is_bfv root_gb reporting in the RT and placement fixed in rocky
15:32:31 dansmith melwitt: aight, well, anyway, my recommendation is that we just remove that inventory quirk for rocky since it can't work and it's one line. alternatively, at least a known-issue reno just to cover our butts in case someone hits it
15:32:35 sean-k-mooney mriedem: ya i think though we will have to fix up the allcoation for existing instance that are not bfv going forward
15:32:51 mriedem sean-k-mooney: we do
15:32:52 dansmith melwitt: it's like having a half-merged feature.. doesn't really serve any purpose and is externally tickle-able to failure
15:33:02 dansmith obviously your call on what to do
15:33:12 mriedem sean-k-mooney: https://review.openstack.org/#/c/583715/
15:33:24 mriedem sean-k-mooney: we'll heal on move
15:33:26 cdent any swag on how hard to make it go, now-ish?
15:33:38 mriedem "make it go" == make it work?
15:33:53 mriedem we don't even have multi-node shared storage provider CI
15:33:56 mriedem so very high risk IMO
15:33:57 sean-k-mooney mriedem: in the non BFV case we need to read the size form the image if the flavor root_gb=0
15:34:00 mriedem way too late
15:34:11 mriedem sean-k-mooney: yup
15:34:13 dansmith yeah, way too late to try to make any of the broken non-broken
15:34:19 mriedem but that's not reported to the RT as far as i know
15:34:27 fried_rice dansmith: I can propose that if you like.
15:34:39 dansmith fried_rice: which?
15:34:41 mriedem dansmith: so we should likely start with a bug saying this stuff will nuke your DISK_GB allocations on failure or revert at least
15:34:51 mriedem fried_rice: melwitt: ^
15:34:53 fried_rice dansmith: Taking that line out of the libvirt driver.
15:35:09 dansmith mriedem: for sure
15:35:24 dansmith fried_rice: sure, I'm happy to do it as well, either way
15:35:28 mriedem and we can track the various bugs in a spec in stein if we're going to go full on and support this
15:36:01 fried_rice dansmith: You want to write up the bug, I'll do the patch?
15:36:02 mriedem b/c we need a spec for the upgrade impacts obviously, and how to deploy the thing, plus CI requirements (which i'm already half-way done with)
15:36:03 melwitt sounds like a plan
15:36:21 dansmith fried_rice: if mriedem isn't going to
15:36:34 mriedem go ahead
15:36:43 dansmith fried_rice: I think mriedem really wants to do it
15:36:46 dansmith I heard him say earlier
15:36:53 dansmith so I don't want to step on his toes
15:36:57 mriedem i'm cleaning up stephenfin's last 2 changes in his vswitc hseries
15:37:04 dansmith because I think he measures his weekly progress by bugs reported
15:37:07 dansmith mriedem: more?
15:37:08 mriedem plus, zuul just f'ed my ceph ci run that was almost done!
15:37:12 melwitt this is new, gate failure RETRY_LIMIT
15:37:15 melwitt great
15:37:19 mriedem melwitt: yes same
15:37:34 openstackgerrit Chris Dent proposed openstack/nova master: WIP: funtional test with sharing providers https://review.openstack.org/586589
15:37:36 mriedem #status alert A zuul config error slipped through and caused a pile of job failures with retry_limit - a fix is being applied and should be back up in a few minutes
15:37:36 mriedem infra just posted a status
15:37:44 mriedem so don't recheck
15:38:15 cdent dansmith: ^ that gets the test actually making reasonable requests, but no more that that
15:38:27 cdent not sure if you care given the earlier discussion, but in case you do...
15:38:52 dansmith cdent: yeah, probably don't care now that I found this other one
15:38:57 dansmith but thanks for setting me straight
15:40:57 fried_rice cdent: All I care about is that you misspelled funtional
15:40:59 mriedem i can write the bug if no one has started yet
15:41:27 fried_rice Do it. And let the English see you do it.
15:41:40 mriedem alright
15:42:00 cdent fried_rice: that was dansmith in this case
15:42:16 cdent but I can see how it being me would be unsurprising
15:42:16 dansmith I was rushing
15:42:34 cdent is my new excuse
15:42:40 fried_rice cdent: If it had been three weeks ago, and it had been fuctional, I would have totally known it was you.
15:43:42 cdent I fuctional tests all the time
15:44:16 fried_rice Is there a way to mark a normal funtional test as an xfail?
15:45:46 fried_rice oh, shit, bhagyashri's test still succeeds with that bit commented out :(
15:46:32 fried_rice ignore me, phew.
15:47:02 cdent fried_rice: https://docs.python.org/3/library/unittest.html#unittest.expectedFailure
15:47:22 cdent https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures
15:47:24 fried_rice thanks cdent
15:47:54 fried_rice only py3? Are we running func tests on only py3 these days?
15:48:28 sean-k-mooney fried_rice: i think we have both. still
15:48:55 fried_rice yup sean-k-mooney
15:49:02 sean-k-mooney you can proably do a version check and jsut skip on 2 and expect failure on 3
15:50:10 openstack Launchpad bug 1784020 in OpenStack Compute (nova) "Shared storage providers are not supported and will break things if used" [High,Triaged]
15:50:10 mriedem here you go https://bugs.launchpad.net/nova/+bug/1784020
15:50:21 mriedem dansmith: fried_rice: melwitt: ^
15:50:27 dansmith oh thanks
15:50:39 cdent fried_rice: https://docs.python.org/2.7/library/unittest.html#skipping-tests-and-expected-failures
15:50:48 melwitt now that's a bug report
15:51:03 dansmith mine would have been 5% of that
15:51:11 mriedem fried_rice: testtools has an expectedFailure thing
15:51:14 melwitt hah, I know
15:51:22 mriedem you said i take pride in it...
15:51:26 dansmith "s'broken, kthx"
15:51:34 mriedem mostly because if i don't put those details in there, i'll totally forget wtf we talked about a year from now
15:51:57 melwitt yeah. the details are super helpful
15:52:18 sean-k-mooney mriedem: i think that bug also falls into the catagory of "we dont have ci for it so its broken by default"

Earlier   Later