| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-04 | |||
| 18:57:19 | mriedem | sean-k-mooney: yeah, it's a bit bigger but i'm good with it now | |
| 18:57:49 | oomichi | dansmith: melwitt: could you take a look at https://review.openstack.org/#/c/411816? I am not a specialist at the area and nice to get your reviews I think | |
| 18:58:18 | sean-k-mooney | i actully taught the hyperv os-vif support was already in place in newton but i guess it missed the cut off. | |
| 18:58:19 | mriedem | edleafe: is this what your patch was handling? http://logs.openstack.org/21/386221/3/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/14df095/logs/screen-n-cpu.txt.gz#_2017-01-04_12_16_04_616 | |
| 18:58:22 | dansmith | oomichi: I'm not really either but I'll look | |
| 18:58:27 | mriedem | edleafe: on the ceph jobs we send 0 for disk allocatoins | |
| 18:58:30 | mriedem | which placement hates | |
| 18:59:17 | mriedem | edleafe: actually i guess https://review.openstack.org/#/c/414214/ should handle that for the ceph job | |
| 18:59:51 | oomichi | dansmith: thanks :) | |
| 19:01:09 | edleafe | mriedem: yep | |
| 19:01:21 | mriedem | edleafe: actually no it looks like | |
| 19:01:22 | mriedem | http://logs.openstack.org/14/414214/12/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/511c30e/logs/screen-n-cpu.txt.gz#_2017-01-03_23_17_44_750 | |
| 19:01:29 | mriedem | ^ is the ceph job run on jaypipes' patch | |
| 19:01:43 | mriedem | Sending allocation for instance {'allocations': [{'resource_provider': {'uuid': 'f8ce7899-0b48-4294-8df2-057ac325f4d2'}, 'resources': {'MEMORY_MB': 64, 'VCPU': 1, 'DISK_GB': 0}}]} | |
| 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 | |