Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-05
19:07:26 clarkb mriedem: thats the group issue I think
19:07:36 clarkb (I thought we handled both possible groups but maybe that is broken?)
19:07:40 mriedem clarkb: right i was looking at this https://review.openstack.org/#/c/451492/15/stackrc
19:07:48 SamYaple clarkb: that helps me, and i think its safe to ignore those apparmor issues fwiw
19:08:15 clarkb SamYaple: we never root caused the memory issues because upstream basically said EOLD and upgrade
19:08:16 melwitt mriedem: when I separate the index add, is it supposed to get its own migration file under migrate_repo/versions/?
19:08:28 mriedem melwitt: yeah it would have to
19:08:32 melwitt oops. okay
19:08:52 SamYaple clarkb: upstream as in libvirt? or ubuntu? because ubuntu should be fixing that for the next 3(?) years or so
19:08:59 SamYaple clarkb: did you pop a bug with canonical?
19:09:11 clarkb SamYaple: upstream as in libvirt, ya we filed a bug against canonical/ubuntu
19:09:41 mriedem hmm, do we not have a worlddump anymore?
19:09:44 mriedem did that dump the groups?
21:15:48 dansmith and I dunno what to do with the randomize thing.. maybe also a flag about whether to do that or not (spread/pack) ?
21:15:57 mriedem dansmith: that's in that change
21:15:59 mriedem so that's already done
21:16:03 dansmith oh,
21:16:04 leakypipes dansmith: that's already there.
21:16:11 dansmith placement has a config not a query param for the randomize?
21:16:12 mriedem i think the idea being, if your limit is smaller, you do random, and if it's bigger, you don't
21:16:15 dansmith gotcha
21:16:15 leakypipes sorry, that's why I was confused :)
21:16:18 mriedem dansmith: correct
21:16:33 mriedem does seem like it should be a per-request on the client side thing
21:16:34 dansmith right I hadn't actually paid attention to that part
21:16:40 mriedem config-driven api behavior
21:17:03 dansmith the randomize? I would have kinda thought so, since cinder and nova might have different requirements for which 1000 to return
21:17:16 mriedem yeah
21:17:25 mriedem welp, i guess that's a future improvement for rocky
21:17:28 dansmith yeah, that's what I had been assuming, but it
21:17:33 dansmith yeah
21:17:33 dansmith is something we can do later
21:18:21 mriedem i wonder if we'd want to make the limit option on the nova side a multiple of the number of instances to build in a given request...or is that getting too cute?
21:18:55 dansmith opens a DoS though
21:19:05 mriedem true
21:19:24 dansmith I would make it static and then if people need cuteness, we can ask for safe suggestions
21:20:01 mriedem alright, now how to track this - could do it against the blueprint if someone is going to work on it now, else i can open a bug since it's kind of a bug on the nova side that we don't limit
21:20:11 mriedem i'm sure no one cares about that tracking business except me
21:20:24 dansmith I can cook up a patch while you decide how to appease your paperwork fetish
21:20:37 mriedem cool, because i'm already getting rashy
21:21:58 edmondsw the placement api-ref isn't linked from https://developer.openstack.org/api-guide/quick-start/ ... is that intentional or an oversight?
21:27:37 fried_rice mriedem leakypipes dansmith FYI using GET /allocation_candidates limiting is on the sched mtg agenda for Monday.
21:27:57 leakypipes cool, thanks
21:28:21 leakypipes edmondsw: good question...
21:28:32 mriedem edmondsw: likely an oversight
21:28:56 mriedem edmondsw: you should totally add that
21:29:05 edmondsw mriedem leakypipes alright, will do
21:35:25 dansmith I look forward to the rash of "you didn't write this conf option help text right" comments
21:36:40 leakypipes :w
21:40:38 openstackgerrit Merged openstack/nova master: VMware: add support for different firmwares https://review.openstack.org/448034
21:52:57 openstackgerrit Merged openstack/nova stable/pike: Retry _trait_sync on deadlock https://review.openstack.org/528094
22:12:20 mriedem stvnoyes: tempest patch updated with the detach logic and todos for more tests https://review.openstack.org/266605
22:13:59 dansmith hmm, between 1.10 and 1.16 /allocation_candidates result changed ?
22:18:05 figleaf dansmith: yep - https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/microversion.py#L52-L55
22:18:33 dansmith yeah
22:18:56 dansmith figleaf: have links to what they looked like before/after?
22:19:00 dansmith I would go for api_samples normally
22:26:08 figleaf dansmith: IIRC, they were identical, with only the addition of 'project_id' and 'user_id'
22:26:22 figleaf dansmith: but no, I don't have such links handy
22:26:34 dansmith figleaf: no i think the "format now matches that of get" was more of a change
22:26:59 dansmith I'm getting some issues that are related to trying to treat an array like a dict
22:28:05 fried_rice leakypipes Looks like today we don't handle RP generation when we update aggregates.
22:28:30 fried_rice leakypipes At least according to the API ref as it stands. I think that's a problem.
22:30:05 openstackgerrit Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512
22:30:16 leakypipes fried_rice: add it as an item on Monday?
22:30:27 fried_rice leakypipes Ight.
22:30:54 fried_rice leakypipes It comes into play in the discussion around coordinating shared providers from multiple compute nodes
22:31:03 leakypipes ack
22:31:15 fried_rice Unless the agg UUIDs are deterministic, we absolutely need generation handling there.
22:32:39 leakypipes fried_rice: to be discussed :) (I am heading off for dinner...)
22:32:46 fried_rice leakypipes Enjoy
22:34:37 mriedem dansmith: https://developer.openstack.org/api-ref/placement/#list-allocation-candidates
22:35:06 dansmith oh I didn't realize both versions were in there
22:35:08 dansmith awesome
22:38:50 mriedem lbragstad: looks like your patch fixes the issue http://logs.openstack.org/97/531497/2/check/legacy-tempest-dsvm-neutron-src/a196420/logs/screen-n-cpu.txt.gz?level=WARNING
22:39:02 mriedem lbragstad: my question was really, let's say nova has 10 deprecated policies in code,
22:39:14 mriedem and i've overridden one of those deprecated policy rules in my policy.yaml,
22:39:17 mriedem but not the other 9
22:39:28 mriedem will i see warnings about all 10, or just the 1 that overrode the default?
22:39:41 lbragstad you will see a warning for the one you overrode
22:40:00 mriedem ok i figured self.file_rules was just checking if there are any
22:40:03 mriedem but not specific ones
22:40:16 lbragstad that's what https://review.openstack.org/#/c/531497/2/oslo_policy/tests/test_policy.py@1004 tests for
22:40:39 lbragstad since that specific test isn't writing a temp file for policy rules (or overrides)
22:41:03 mriedem default.name in self.file_rules
22:41:03 mriedem oh duh
22:41:09 mriedem i didn't realize it was looping over the rules
22:41:10 lbragstad yup
22:41:19 lbragstad yeah - it goes through everything
22:41:54 mriedem +1
22:41:55 mriedem thanks
22:41:57 lbragstad and logs a single warning (so warnings aren't constantly emitted every time a poilcy is run through enforce())
22:42:06 lbragstad no problem - thanks for raising the issue
22:42:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244
22:42:20 openstackgerrit Matt Riedemann proposed openstack/nova master: [libvirt] Allow multiple volume attachments https://review.openstack.org/267587
22:42:21 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: [api] Allow multi-attach in compute api https://review.openstack.org/271047
22:48:08 dansmith bah, have to figure that format thing out on monday
22:48:10 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Pass limit to /allocation_requests https://review.openstack.org/531517
#openstack-nova - 2018-01-06
00:05:24 fried_rice dansmith FYI, I added ^ under the appropriate discussion point for the sched meeting.
00:06:04 fried_rice So you better be there, or we'll make decisions like you have to follow every comma with a newline.

Earlier   Later