Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-02
19:56:02 mriedem so you don't even need the request spec
19:56:40 arvindn05 great
19:57:11 arvindn05 i would just need to load the new image meta then to compare each other
19:58:29 mriedem you have the new image here https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3013
20:00:04 arvindn05 btw is there an instance.image_meta? i dont see it under objects.instance.Instance
20:02:46 mriedem https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L238
20:03:43 arvindn05 ahh..its not a field...but a property got it
20:07:34 melwitt mriedem: indeed, here's a job pass on stable/queens from today http://logs.openstack.org/68/565668/1/check/legacy-tempest-dsvm-full-devstack-plugin-ceph/b6047e4/job-output.txt.gz#_2018-05-02_09_46_32_680582
20:08:11 mriedem hmm, tempest and devstack-plugin-ceph are branchless,
20:08:20 mriedem so whatever is broken must be in master only for nova or cinder
20:08:39 melwitt yeah, exactly. odd. going to see if I can find what's different
20:10:13 mriedem melwitt: my money is on that schema change in the cinder api which is queens only, merged in march
20:10:30 melwitt you mean rocky only?
20:10:32 mriedem before that, the api would just pass attachment_id=None down to the volume manager which handled it https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L1296
20:10:40 mriedem yeah, i'll never adapt to rocky
20:10:49 melwitt QueensMan
20:11:00 melwitt okay, I think I missed where you pointed out the schema change. *scrolls back*
20:13:26 melwitt ah yep, so there used to be no schema validation I guess? agreed that has to be the reason for the failure now
20:15:48 openstack Launchpad bug 1768650 in Cinder "POST /volumes/{volume_id}/action os-detach incorrectly requires attachment_id is not None" [Undecided,New]
20:15:48 mriedem melwitt: https://bugs.launchpad.net/cinder/+bug/1768650
20:15:59 mriedem i'll push a patch to cinder
20:16:37 melwitt sounds great
20:41:41 mriedem yeehaw http://paste.openstack.org/show/720250/
20:42:32 melwitt old school, email it
20:42:52 mriedem heh, i thought about it
21:29:15 cfriesen has anyone ever looked at supporting "-cpu host,migratable=no,+invtsc" in order to get the "nonstop_tsc" flag in the guest? The tricky bit seems to be that nova might want to block attempts to migrate or snapshot the instance if it's enabled since it's going to fail down in qemu.
22:07:54 dansmith melwitt: HEY. This country was built with patch-on-ML!
22:08:15 melwitt ;D
22:12:45 lbragstad melwitt: o/ johnthetubaguy was telling me that you are a quota expert
22:14:43 melwitt lbragstad: o/ an accidental one, maybe
22:15:35 lbragstad :) i was working with john on documenting CERN's usecase for hierarchical quotas/limit with the unified limit approach
22:15:55 lbragstad i think i got it all out on paper now, https://review.openstack.org/#/c/565412/
22:16:14 lbragstad but figured you'd be pretty good at poking holes in what we have so far
22:16:38 lbragstad (there are a ton of diagrams, but the rendered version isn't bad- http://logs.openstack.org/12/565412/3/check/build-openstack-sphinx-docs/22ea042/html/specs/keystone/rocky/strict-two-level-enforcement-model.html )
22:17:10 melwitt a-ha, very cool. I will definitely take a look
22:17:56 lbragstad thanks melwitt
22:18:49 melwitt oh, heh, so failed == excluded from the output entirely. that's helpful of it :P
22:19:37 melwitt lbragstad: np, thanks for linking me
22:20:21 lbragstad no problem - latest patch set should render the python example for service to incorporate the limit usage
22:20:35 melwitt excellent
22:22:46 openstackgerrit Eric Fried proposed openstack/nova master: Get anchors for sharing providers https://review.openstack.org/565279
22:22:47 openstackgerrit Eric Fried proposed openstack/nova master: placement: Object changes for granular https://review.openstack.org/564351
22:22:48 openstackgerrit Eric Fried proposed openstack/nova master: placement: Granular GET /allocation_candidates https://review.openstack.org/517757
22:25:56 openstackgerrit karim proposed openstack/nova master: Pushing image traits to ironic node https://review.openstack.org/565620
22:51:10 efried mriedem: Good job distancing yourself from the image traits rebuild issue.
22:52:10 efried That lasted, what, four hours?
22:52:47 mriedem almost 9
22:55:19 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886
22:55:20 mriedem mgagne: now with functional tests ^
22:56:37 mgagne mriedem: cool stuff! are there multiple cells in the test?
22:57:03 mriedem yes, except that doesn't currently work b/c there is a bug in our fixtures, i need to test it with https://review.openstack.org/#/c/524264/ or https://review.openstack.org/#/c/558160/ underneath
22:57:14 mriedem but, in-laws are here and i'm going to get yelled at soon
22:58:45 mgagne mriedem: there is no rush, have a good one ;)
23:11:22 openstackgerrit Hongbin Lu proposed openstack/nova master: Use revision_number on adding/removing security group https://review.openstack.org/535510
23:15:51 melwitt guh, all that hacking on CellDatabases that I was trying to fix with https://review.openstack.org/508432 makes me sad
23:21:01 arvindn05 melwitt: thanks for the reply on the rebuild thread....wanted to get your thoughts on whether the approach is easy to maintain going forward
23:21:58 arvindn05 melwitt: my main concern is if we decide to support forbidden/granular traits etc for images at some point, this part of the logic will need to be updated
23:22:02 melwitt well, rejecting a valid request doesn't seem correct and would likely require later maintenance too
23:22:08 arvindn05 aand maintained going forward...
23:22:36 melwitt meaning, the placement queries would have to be updated?
23:24:56 arvindn05 not just that....the current approach is to get allocations for current instance and then match them in the conductor
23:25:46 arvindn05 the matching happens in the conductor for required traits for now...but if we need to handle granular/forbidden traits etc this matching logic will need to be updated
23:27:00 melwitt can you point me to the code you're referring to?
23:27:19 arvindn05 my point is that since required traits are qualitative requirements, if they change its better to ask the scheduler rather than try to duplicate logic in placement and in conductor
23:27:52 arvindn05 there is not code yet....but eric summarized in this post http://lists.openstack.org/pipermail/openstack-dev/2018-April/129740.html
23:28:27 melwitt okay. well, I'm just saying verifying the traits in placement seems like the only correct thing to do
23:30:38 arvindn05 ideally yes, but a rebuild request never gets to placement api with any of the options described in the thread i think
23:31:34 arvindn05 is there an different alternative where verifying the traits can happen in placement code in case of rebuild?
23:32:49 melwitt what? some of the options involve calling placement
23:35:01 arvindn05 sorry if its unclear...i meant if there is way to utilize the matching logic of placement instead of trying to duplicate that in the conductor/schedulers
23:39:15 melwitt if there's a way to ask placement "do these providers have these traits?" then that's what we need right? we need to ask if the providers hosting our current allocations have the traits requested in the image
23:40:11 melwitt if we could ask it that way, placement would do the matching. but I don't have deep knowledge the placement APIs
23:41:10 melwitt that is, I don't know if there's an available API like that
23:41:24 arvindn05 As i understand it its not just "do these providers have these traits?"...its also "do we have allocations from these providers for those traits?"
23:42:07 arvindn05 since we cannot do allocations during rebuild...we need to make sure our existing allocations satisfy all the trait requirements
23:42:15 melwitt it is, and that's what I tried to say. we have to 1) know our allocations 2) know what providers are hosting our allocations 3) know what traits the providers in 2) have
23:44:22 melwitt so I guess it would be 1) query for own allocations by consumer == our instance 2) use the providers returned by that to ask 2) do these providers have these traits. again, I'm making up the second query, I don't know if one like that exists
23:44:54 melwitt maybe I made up the first one too, but you get the idea
23:45:45 arvindn05 yea...that was what efried had...
23:47:36 arvindn05 the only 2 cons for this approach
23:47:36 arvindn05 1.the rebuild may or may not succeed, depending on how well the original allocations match up with the new requirements.
23:47:36 arvindn05 2. we need to need to account for handling preferred traits or granular resource traits if we decide to implement them for images at some point...
23:47:39 arvindn05 see http://lists.openstack.org/pipermail/openstack-dev/2018-May/130087.html
23:48:12 arvindn05 to see why 1 may occur....
23:51:35 melwitt are traits the same as properties? do they replace properties or?
23:51:42 melwitt *image properties
23:53:13 arvindn05 they are an addition to image properties...
23:53:34 arvindn05 maybe long term they can start to replace some of the image properties....
23:53:58 melwitt okay. was just thinking about whether 1. would be a regression on how it behaves today. you can rebuild with a new image with new image properties if they pass scheduler filtering
23:54:41 melwitt if image property == image trait then if you reject any rebuild with new traits, then that's a step backward from what's possible today
23:56:23 arvindn05 nope traits are independent of image properties...they use the same key:value and are expressed as such in the image properties...but not the same
#openstack-nova - 2018-05-03
00:01:23 arvindn05 i think either of the 2 options we boiled down to work for me....i put this in open dicussion for tommorow's meeting...hopefully we get concensus then :)
00:25:06 openstackgerrit Jake Yip proposed openstack/nova master: Add --before to nova-manage db archive_deleted_rows https://review.openstack.org/556751
00:46:00 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886
01:13:36 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP new migration threads control https://review.openstack.org/563505
01:23:28 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies https://review.openstack.org/546925
02:52:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix the request context in ServiceFixture https://review.openstack.org/558160
02:52:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886
02:54:04 openstackgerrit Matt Riedemann proposed openstack/nova master: Add multi-cell negative test for cold migration with target host https://review.openstack.org/524027
03:14:27 openstackgerrit jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658

Earlier   Later