Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-04
19:01:49 edleafe mriedem: ok gimme a few - on a call now
19:02:37 mriedem oh that's allocations,
19:02:40 mriedem jay fixed inventories
19:03:13 jaypipes ya
19:03:20 jaypipes edleafe fixed allocs.
19:03:20 mriedem ok looking at https://review.openstack.org/#/c/407180/ now
19:10:25 mriedem would be cool if we could define ranges on ovo integer fields like we can for IntOpts in oslo.config
19:11:29 openstackgerrit Jay Pipes proposed openstack/nova: Return uuid attribute for aggregates https://review.openstack.org/415031
19:11:56 sean-k-mooney mriedem: if ovo cant do it as an integer type field im sure a bounded integer field could be introduced if needed
19:12:27 sean-k-mooney mriedem: probably not this cycle though
19:14:20 mriedem jaypipes: replied in https://review.openstack.org/#/c/415031/7/nova/tests/functional/api_sample_tests/test_aggregates.py - i think what alex was asking for is redundant
19:14:23 mriedem which is why i removed it
19:16:44 openstackgerrit Rafael Folco proposed openstack/nova: DELETE all inventory for a resource provider https://review.openstack.org/416669
19:28:00 mriedem cdent: edleafe: got some issues in https://review.openstack.org/#/c/407180/ - for whenever
19:30:12 jaypipes mriedem: oh, I figured you removed it because you found a bug in using a regex substitution for uuids.
19:30:34 mriedem nope it was just confusing me and was redundant
19:31:01 mriedem we can't actually compare the response to a known uuid in those tests without hacking the aggregate create db method
19:31:03 mriedem to use a static uuid
19:31:07 mriedem and i didn't want to do that in those tests
19:31:32 mriedem i guess we could for some of the other tests that build on an existing created aggregate where we already know the uuid
19:33:43 jaypipes mriedem: I had copied that subs['uuid'] stuff from test_servers.py :)
19:34:10 mriedem like most tihngs in api samples tests, who knows, things are cludged until they pass
19:34:40 mriedem i can poke at using the actual created aggregates uuid in later test response subs in a bit
19:39:40 mriedem edleafe: i'm not sure why Allocation.create() is even touched in https://review.openstack.org/#/c/407180/ since nothing in nova uses that method today from what i can tell
19:39:48 mriedem everything goes through AllocationList.create_all()
19:40:17 mriedem which is why we don't handle ObjectActionError in the handler
19:48:17 mriedem nice https://review.openstack.org/#/q/topic:bp/use-neutron-by-default
19:48:22 mriedem another bp to check off
19:51:59 edleafe mriedem: ok, back from meeting. Let me dig in further
19:52:28 edleafe mriedem: the long holiday wiped out all my context
19:53:13 mriedem edleafe: i think the fix is really just in the report client to filter out 0-value allocatoins
19:53:15 mriedem *allocations
19:53:18 mriedem and that's a fix we can backport to newton
19:53:51 mriedem the additional guarding and error handling stuff in the REST API could be separate, and doesn't fix thebug
19:53:59 cdent mriedem: we can't just fix the report client because there will be other clients, eventually. It might be okay for now, but we'll need to fix it before end of cycle
19:54:30 mriedem well, what does 'fix' mean?
19:54:38 mriedem because Allocation.create() changes don't fix anything b/c it's dead code
19:55:00 cdent i mostly mean the use of the exception
19:55:11 mriedem sure, that's fine, and makes the API response more clear to the real error
19:55:11 cdent we can probably remove create() now that we don't have remotable
19:55:27 mriedem i'd prefer to split the REST API handler change out from the report client fix
19:55:33 mriedem b/c i want to backport the report client fix to newton
19:55:46 edleafe mriedem: that makes sense
19:55:58 edleafe mriedem: let me revert all but the report client change in that patch
19:56:10 edleafe I can address the remaining issues in a separate patch
19:56:57 mriedem cool thanks
20:02:33 openstackgerrit Ed Leafe proposed openstack/nova: Do not post allocations that are zero https://review.openstack.org/407180
20:02:40 edleafe mriedem: ^^ just the report client changes
20:07:01 satyar Thanks jaypipes and mriedem
20:07:28 satyar putting the rbd_secret_uuid to cinder.conf solved the boot from volume issue
20:07:41 jaypipes satyar: that was all mriedem :)
20:08:03 mriedem woot
20:08:08 satyar mreidem i dont think we need rnd_secret_uuid in nova.conf anymore
20:08:09 satyar :)
20:08:29 mriedem satyar: only if you're using rbd for ephemeral storage on the computes with the libvirt driver
20:08:30 satyar jaypipes you also helped :)
20:08:32 mriedem and want them encrypted
20:08:43 satyar ok
20:08:52 mriedem nova.conf is for the ephemeral storage, cinder.conf is for the persistent
20:09:57 satyar git it :) Thanks mridem
20:10:22 mriedem jaypipes: dansmith: so i think we assume that we'd like resource providers and the reporting client to work for ironic in newton before upgrades to ocata, yes?
20:10:57 mriedem because backporting https://review.openstack.org/#/c/414214/ is turning out to be a pain in the ass because of https://github.com/openstack/nova/commit/f1cd928bf5daac3b344d0c6cd095aabec14cdbff not being in newton
20:13:24 dansmith mriedem: you could backport that dependent patch easily, no?
20:13:48 dansmith but yeah I guess we'd want ironic pre-reporting
20:14:09 mriedem dansmith: i could, even though it says blueprint in it and is just a refactor
20:14:10 dansmith tbh, we (redhat) aren't really as prepared for placement being required in ocata as we'd like
20:14:27 mriedem but i guess we just say 'this is for the next thing which we need and makes the backport simpler, no functional changes, so eat it tonyb'
20:14:35 dansmith so at some point we'll probably need to decide how likely things are to make ocata in whole and maybe decide to punt the requirement
20:14:54 dansmith yeah, I mean, doesn't seem like it should be that controversial, tbh
20:15:12 mriedem punt the requirement upstream or rhosp?
20:15:26 mriedem because besides the scheduler bits to talk to the placement api, i think we're pretty close
20:15:28 dansmith well, osp can't punt if it's not punted upstream, but I meant upstream nova yeah
20:15:30 dansmith okay
20:15:42 dansmith I haven't been paying as much attention as I should
20:15:46 dansmith but that's good if so
20:15:54 mriedem that's fine, you're cells v2 plus vacation
20:16:16 mriedem jaypipes can correct me if i'm wrong about status though
20:16:35 dansmith after detoxing for 2.5 weeks and feeling not so great today, I've determined that I'm allergic to work
20:16:50 mriedem more coffee
20:16:53 dansmith heh
20:17:12 mriedem or https://www.youtube.com/watch?v=RAZQ769_EUU
20:17:17 mriedem at very loud levels
20:17:31 dansmith when my headache goes away, maybe :)
20:30:47 mriedem crap even with backporting that one change there are a bunch of conflicts
20:30:52 mriedem so i probably won't try backporting that one
20:42:13 mriedem edleafe: +2 on that simpler change, will check the ceph job logs when that's done
20:42:26 mriedem edleafe: are you going to roll the REST API error handling stuff back on top of that?
20:42:28 edleafe mriedem: kewl
20:42:37 edleafe mriedem: yeah, starting on that now
20:42:45 jaypipes mriedem: I'd support backporting that dependent patch (which as you point out is just a refactor, not a functional change)
20:42:53 mriedem jaypipes: yeah i'm doing that, plus 2 before it
20:42:58 mriedem jaypipes: you went refactor crazy in ocata
20:43:01 jaypipes mriedem: sorry man :(
20:43:06 mriedem it's fine :)
20:43:11 mriedem we'll just have to bribe lyarwood
20:44:09 jaypipes heh
21:04:01 mriedem hmm, do we want to backport https://review.openstack.org/#/c/392933/
21:04:45 mriedem because if not, then i don't need to backport https://review.openstack.org/#/c/395971/
21:05:16 mriedem and without https://review.openstack.org/#/c/392933/ i'm not sure that ironic will have issues that we saw on master...
21:05:39 mriedem i might need to just run a DNM patch on stable/newton in ironic that enables the placement-api service to see what blows up

Earlier   Later