Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-21
21:47:40 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Trivial: remove unused var from policies.base.py https://review.openstack.org/645380
21:49:29 mriedem dansmith: i've got this pretty much done, without using a pre-request filter https://review.openstack.org/#/c/645316/ but not sure if i need a blueprint or not, since i'm not adding a configurable filter, it's just going to always be required if you're booting from volume
21:50:01 mriedem cuz it's kind of dumb to even try to boot with a multiattach volume if the scheduler isn't going to filter out hosts that won't support them
21:51:03 efried does that mean they would break further on down the line?
21:51:13 efried I mean, would initial spawn succeed or fail?
21:51:23 mriedem it would fail,
21:51:25 mriedem it's arguably a bug fix
21:51:49 mriedem the bare minimum we do today is check if the computes are new enough, but that was minimum of queens
21:52:01 mriedem that doesn't say bfv wo'nt work for vmware for exapmle
21:52:17 mriedem if you're using vmware exclusively, you'd just have to never enable multiattach volumes on the cinder side via policy
21:52:30 mriedem that's a pain if you're doing multi-hypervisor though
21:52:55 mriedem you'd have to setup aggregates and filter using some flavor extra spec or something
21:55:38 mriedem anywho, idk, it's janky, i suppose you can't reasonably do bfv with vmware and libvirt mixed anyway because you have different volume types, and the libvirt driver isn't going to support vmware volumes and vice versa, so i'm not sure what if anything people do for mixed hypervisor - definitely at least aggregates/AZs
21:56:39 sean-k-mooney efried: ... this change https://github.com/openstack/nova/commit/6b844af57eebda6317b1ed3bf5a2f85dcba0bc13 does not work after i fix the lower constrating so im going to have to change it
21:57:39 efried mriedem: I say no bp, bug good, reno optional
21:58:33 efried sean-k-mooney: I'm on board with that. Long as you don't have to go changing the prod code, I say do what you gotta do to get this fixed.
21:59:38 sean-k-mooney im actully not sure why this is even working upstream honestly
22:00:34 sean-k-mooney i think it is depending on something having previously loaded messaging._drivers.impl_fake
22:00:50 sean-k-mooney *imported
22:02:35 sean-k-mooney ya it is
22:02:38 sean-k-mooney >>> import oslo_messaging as messaging
22:02:40 sean-k-mooney >>> messaging._drivers.impl_fake.FakeExchangeManager._exchanges
22:02:42 sean-k-mooney Traceback (most recent call last):
22:02:47 sean-k-mooney AttributeError: 'module' object has no attribute 'impl_fake'
22:02:47 sean-k-mooney File "<stdin>", line 1, in <module>
22:02:48 sean-k-mooney >>> import oslo_messaging._drivers.impl_fake
22:02:50 sean-k-mooney >>> messaging._drivers.impl_fake.FakeExchangeManager._exchanges
22:02:52 sean-k-mooney {}
22:03:40 sean-k-mooney so there is a race based on the execution order of the tests
22:16:14 openstackgerrit Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access https://review.openstack.org/631242
22:16:15 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244
22:16:15 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec. https://review.openstack.org/631243
22:16:16 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245
22:26:57 dansmith mriedem: why is that not in request_filter.py, just without a conf flag?
22:27:11 dansmith that way all these "check a thing about the request and add a trait requirement" things are in one place
22:27:17 sean-k-mooney efried: so just as an fyi we have other dodgy test too that are wrong upstream :(
22:27:29 efried sean-k-mooney: I am not surprised at all.
22:27:44 efried sean-k-mooney: I wonder if we need to file a bug for this.
22:27:51 sean-k-mooney oh we do
22:28:00 sean-k-mooney but that is not what im concerned about
22:28:20 sean-k-mooney the test issue im finding shoudl be broken in other jobs
22:28:32 sean-k-mooney https://github.com/openstack/nova/blob/d2dc7549ce9a0c979fd319cf0332a861b9cd2000/nova/tests/unit/api/openstack/compute/test_serversV21.py#L5129
22:28:43 sean-k-mooney self.stub_out('uuid.uuid4', lambda: FAKE_UUID)
22:29:02 sean-k-mooney that stubs out uuid.uuid4 to return FAKE_UUID
22:29:09 sean-k-mooney FAKE_UUID is a string
22:29:31 sean-k-mooney oslo messaging does unique_id = uuid.uuid4().hex'
22:29:44 sean-k-mooney .hex is not defiend on a string
22:29:49 sean-k-mooney so it explodes
22:30:06 sean-k-mooney oslo.messaging still does unique_id = uuid.uuid4().hex on master
22:30:06 efried why isn't it exploding now?
22:31:02 sean-k-mooney i think its another race in the tests
22:32:23 sean-k-mooney hum running that test on its own on the py36 target passes but files in lower constratits
22:34:39 efried are you running stop-on-first-failure or do you have a sense of how many tests are broken?
22:34:47 sean-k-mooney ok so my theory is that thing have moved and we are not mocking the right things when usign the older version of oslo.messaging
22:34:56 openstackgerrit Mohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default https://review.openstack.org/645352
22:35:49 sean-k-mooney i was running all the test but while i was getting many of the test to pass the lower-constratits job was hannging after running for a bit
22:36:54 mnaser mriedem: ^ this worked locally running the unit tests
22:37:49 openstackgerrit Mohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default https://review.openstack.org/645352
22:38:17 cfriesen mriedem: I assume the vTPM blueprint status change is because it didn't make it in for Stein?
22:39:09 sean-k-mooney cfriesen: mriedem mentioned he set the state back to pending approval for any blupritn that was approved last cycle but needs to have the spec reapproved
22:39:26 cfriesen thx, figured as much
22:40:31 mriedem cfriesen: right, re-propose the spec for train
22:40:38 mriedem i forgot to switch the bp status when deferring
22:40:55 mriedem mnaser: want to report a bug for this?
22:45:17 mnaser mriedem: oh dang i had one but i didnt add closes-bug
22:45:35 openstackgerrit Mohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default https://review.openstack.org/645352
22:46:02 openstackgerrit sean mooney proposed openstack/nova master: make lower-constratints env use lower-constratins https://review.openstack.org/645392
22:46:19 mnaser ok just noticed your reviews too ill try to address them after foodz
22:46:26 sean-k-mooney im going to keep working on ^
22:46:55 efried sean-k-mooney: Thanks for doing that.
22:47:38 mriedem mnaser: ok i left some comments in PS3, not really worth -1ing over though
22:48:28 sean-k-mooney efried: i can fix the FAKE_UUID issue but i still suspect that our mocking is wrong in some of the tests and code that should not be run actully is being run
22:48:40 mriedem dansmith: it's not a request filter because the request spec doesn't store the bdms, and during server create the bdms won't have multiattach information in them anyway, so to figure it out, i'd have to, within the filter, pull the list of bdms for the instance and for all with a volume_id, query cinder to figure out if the volume is multiattach or not
22:48:55 sean-k-mooney if the lower constraitn job explodes or times out then that is likely why
22:49:26 mriedem if we actually had a BDM.multiattach field, that could maybe work - but we'd still have to get the bdms during scheduling...which might suck
22:56:13 dansmith mriedem_afk: okay, seemed like it was just examining the reqspec to determine what to do, which is exactly like the other filters, but I admittedly was skimming
22:56:18 dansmith can look again tomorrow
23:32:49 sean-k-mooney mriedem_afk: dansmith melwitt i have been talking to erric for the last hour or two about the fact our lower constrats job has been broken since we created it
23:34:13 sean-k-mooney im assuming we are not going to fix this in RC1 i can likely have it fixed tomorow or early next week once i figure out where we are not mocking the rpc bus in some test but is this something we would fix in RC2 or in train?
23:34:43 sean-k-mooney i assume we would want to fix lower constraitn on the stable branches too?
23:34:52 sean-k-mooney https://review.openstack.org/#/c/645392/1
23:36:58 melwitt sean-k-mooney: I think you'll want to open a bug for that, yeah?
23:37:22 sean-k-mooney ya i have left a todo in the review for that
23:37:34 sean-k-mooney but ill do it when i start on this again tomorow
23:37:34 melwitt I'm not sure this is an RC thing because it's our test job not working, not a user deliverable?
23:37:58 sean-k-mooney true but the minium requirement we had listed were wrong
23:38:13 melwitt and then yes, I think we'd want to fix it on stable too. probably not pike since it's bound for EM in the next few weeks
23:38:33 melwitt sean-k-mooney: oh, I see. yeah, so maybe it would be RC
23:39:17 sean-k-mooney lower-constrtis has only been a thing since queens i think so its only the last 2 release + stien
23:39:22 melwitt RC2, that is. I'll add it to the etherpad
23:40:41 sean-k-mooney ya its not rc1 in anycase. but cool ill keep workign on this again tomorow
23:42:47 melwitt sean-k-mooney: sounds good, thank you
23:46:01 sean-k-mooney crap.. this same issue is in a bunch of repos
23:46:14 sean-k-mooney http://codesearch.openstack.org/?q=install_command%20%3D%20pip%20install%20-c%7Benv%3AUPPER_CONSTRAINTS_FILE%3A&i=nope&files=&repos=
23:46:32 sean-k-mooney i should also send a mail to the list about this tomorow
23:50:08 melwitt sean-k-mooney: ++ good idea
23:50:48 sean-k-mooney does this fall under the remite or the requireemtn team, qa team or relase team.
23:51:14 sean-k-mooney i think its the same people more or less on all of them but ill chat to them on irc too
23:52:59 melwitt sean-k-mooney: I would think #openstack-requirements
23:58:15 sean-k-mooney ya so apparently lower-constraints is not actully requried by the PTI which explaing why many of the proejct with the prolematic install command have not seen this issue as they are not testing with lower constratints

Earlier   Later