| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-24 | |||
| 17:27:57 | cdent | indeed, wtf? | |
| 17:28:06 | edleafe | I was just typing the same thing - optimizing when we don't know that that's the problem | |
| 17:28:17 | cdent | but the great thing is: it mostly works, we have a temporary workaround, and we can keep on improving stuff | |
| 17:28:24 | efried | so now on the table is a third option, even broader. | |
| 17:28:28 | efried | for the long term | |
| 17:28:38 | efried | which is: rip out the cache | |
| 17:30:41 | cdent | efried, edleafe: so fairly productive conversation to some extent; more pages shared | |
| 17:30:50 | mriedem | this reminds me, we're GETing aggregates twice per update_available_resource periodic for 0 reason :) | |
| 17:30:57 | cdent | yes _that_ is a bug | |
| 17:31:08 | cdent | but I think efried fixes it in ProviderTree? | |
| 17:31:27 | mriedem | i was going to push a simple backportable patch to remove that unnecessary callin | |
| 17:31:45 | efried | I'm actually not sure any of the stuff I've done touches the legacy update_available_resource code paths. | |
| 17:31:48 | mriedem | like just remove the shit, and leave a comment saying "revert git hash xyz once aggregates are a thing the client cares about" | |
| 17:32:10 | mriedem | the ever growing todo list | |
| 17:32:15 | cdent | mriedem: is it enough of a concern to do anything? I seem to recall someone reporting it as a problem? | |
| 17:32:37 | cdent | oh, I get you, take it all out | |
| 17:32:38 | mriedem | klindgren__ at godaddy was just noticing the number of placement REST API calls in a single periodic run w/o no changes otherwise | |
| 17:32:54 | efried | mriedem If aggregates were only useful for sharing providers, maybe. Also, it won't be as simple as "revert this commit". That's gonna be merge conflict central on the patch series in flight right now. | |
| 17:32:55 | mriedem | i assume to start planning for the scale reqiurements | |
| 17:33:13 | mriedem | efried: i realize, but it would be a breadcrumb to look at what existed before, | |
| 17:33:27 | mriedem | idk, could just be simpler / better to remove it all and when needed, add the stuff back in fresh as needed | |
| 17:33:51 | cdent | I gotta go before getting sucked into another thing, I feel like ass. | |
| 17:33:56 | efried | mriedem On what time frame? Before FF? Or between now and when we cut Q? | |
| 17:34:16 | mriedem | efried: i should be backported, so whenever | |
| 17:34:36 | mriedem | *it | |
| 17:34:38 | mriedem | o/ | |
| 17:34:47 | efried | Bye cdent, thanks for the talk. | |
| 17:35:25 | efried | mriedem So that backport is gonna be very different for Q and pre-Q, just sayin. | |
| 17:35:36 | mriedem | melwitt: want to hit this cleanup patch and the docs one after it? https://review.openstack.org/#/c/536871/ - i've got the osc-placement 1.0.0 release dependent on this series | |
| 17:35:48 | mriedem | efried: because the provider tree stuff changed everything? | |
| 17:35:59 | melwitt | mriedem: sure thing | |
| 17:36:00 | mriedem | i haven't looked at things there in 2 weeks | |
| 17:36:15 | efried | mriedem Yes, changed some things, and added lots of things. | |
| 17:36:26 | mriedem | anyway, whatever, it should be pretty straight-forward | |
| 17:36:47 | mriedem | melwitt: thanks | |
| 17:42:35 | melwitt | mriedem: will this link be working after the change merges or does it need to be corrected now? https://review.openstack.org/#/c/536858/4/releasenotes/notes/commands-v1.0.0-894ea659825b3757.yaml@36 | |
| 17:43:04 | mriedem | melwitt: it'll work as a result of this change | |
| 17:43:07 | mriedem | and once the docs get published | |
| 17:43:21 | melwitt | k | |
| 17:44:47 | mriedem | bauzas: what do you need from me wrt the libvirt gpu series? | |
| 17:47:40 | dansmith | mriedem: : | |
| 17:47:46 | openstackgerrit | Dan Smith proposed openstack/nova master: Avoid suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 17:47:55 | dansmith | mriedem: I just fixed up all the things we commented on | |
| 17:47:59 | mriedem | ack | |
| 17:48:01 | mriedem | reviewing | |
| 17:48:22 | dansmith | mriedem: I can try to find someone else to be the second +2 if my hands are too dirty.. I'll let you make that call | |
| 17:54:17 | openstackgerrit | Dan Smith proposed openstack/nova master: Avoid suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 17:54:19 | dansmith | mriedem: sorry, I forgot to replace one line in the test ^ | |
| 17:59:46 | dansmith | lbragstad: hey, mriedem told me you fixed the copious warnification about policy deprecativity recently | |
| 17:59:58 | dansmith | but I still experience said pain | |
| 18:00:22 | dansmith | is there something we're doing that blocks us from experiencing intended test euphoria? | |
| 18:01:09 | lbragstad | dansmith: oh - really? | |
| 18:01:20 | dansmith | lbragstad: yah | |
| 18:01:28 | lbragstad | i had a few patches in flight for a couple different issues, let me check to see where they are at | |
| 18:02:40 | openstackgerrit | OpenStack Release Bot proposed openstack/os-traits master: Update reno for stable/queens https://review.openstack.org/537512 | |
| 18:02:55 | openstackgerrit | OpenStack Release Bot proposed openstack/os-vif master: Update reno for stable/queens https://review.openstack.org/537514 | |
| 18:03:42 | lbragstad | dansmith: what version of oslo.policy are you experiencing this with? | |
| 18:03:59 | dansmith | lbragstad: I just tox -r'd, but let me look | |
| 18:04:12 | dansmith | oslo.policy>=1.30.0 # Apache-2.0 | |
| 18:04:12 | dansmith | (r/s/b/add-suppo)% grep policy requirements.txt | |
| 18:04:45 | mriedem | dansmith: +2 on https://review.openstack.org/#/c/535693/ - i think you're ok to +W | |
| 18:04:50 | lbragstad | https://review.openstack.org/#/c/531497/ is the patch that should have fixed the issue you're seeing | |
| 18:04:56 | dansmith | mriedem: rr thanks | |
| 18:04:59 | lbragstad | and that *should* be in oslo.policy 1.33.1 | |
| 18:05:50 | lbragstad | which looks good here - https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L446 | |
| 18:06:08 | dansmith | lbragstad: hmm, but I've got 1.30 in requirements.. am I missing how g-r overrides that or something? | |
| 18:07:36 | lbragstad | that's a good question | |
| 18:07:59 | mriedem | dansmith: upper-constraints should pull in 1.33.1 | |
| 18:08:01 | lbragstad | dansmith: do you know exactly which version of oslo.policy you have in your env? | |
| 18:08:10 | melwitt | mriedem: can you remind me if you know if anything is unique to the cells v1 tempest job? in looking at the libvirt errors on stable, it's both stable branches and only the cells v1 job | |
| 18:08:11 | mriedem | he's got 1.30 | |
| 18:08:14 | dansmith | lbragstad: above I quoted what is in requirements.txt | |
| 18:08:33 | mriedem | melwitt: cellsv1 job shouldn't have anything unique about the compute / virt setup | |
| 18:08:35 | lbragstad | mriedem: i thought he had >=1.30 in requirements | |
| 18:08:42 | mriedem | oh, | |
| 18:08:45 | mriedem | pip freeze your tox venv | |
| 18:08:53 | dansmith | I hacked my requirements.txt, tox -r, and still get it | |
| 18:08:56 | mriedem | 1.33.1 is in u-c | |
| 18:09:15 | melwitt | mriedem: thanks | |
| 18:09:24 | dansmith | (r/s/b/add-suppo)% .tox/py27/bin/pip freeze | grep policy | |
| 18:09:25 | dansmith | oslo.policy==1.33.1 | |
| 18:09:26 | dansmith | after my hack | |
| 18:09:57 | lbragstad | ah | |
| 18:10:04 | mriedem | bauzas: is this the final piece of the vgpu puzzle for libvirt https://review.openstack.org/#/c/535693/ ? i don't see any other libvirt patches for vgpu - so assuming we're done once that merges | |
| 18:10:15 | dansmith | trying again without the hack, but assume I'll get that same thing again | |
| 18:10:30 | mriedem | do we have any patch that has a feature support matrix update for vgpu support? | |
| 18:11:56 | lbragstad | dansmith: do you have a policy file you're testing with locally, or are you just running nova tests? | |
| 18:12:11 | dansmith | lbragstad: just nova tests | |
| 18:12:18 | mriedem | dansmith: if it's always a handful of rules, it could be something in the policy fixture or a specific test | |
| 18:13:28 | lbragstad | the fix in 1.33.1 just makes it so a warning is logged iff a policy is deprecated *and* you're specifying it in a policy file or somewhere on disk | |
| 18:13:49 | dansmith | mriedem: there are 11 warnings, seemingly regardless of what tests I run | |
| 18:15:12 | mriedem | nova.tests.unit.policy_fixture.PolicyFixture maybe? | |
| 18:15:17 | mriedem | loads things up from some fake rules | |
| 18:15:33 | mriedem | from nova.tests.unit.fake_policy | |
| 18:15:44 | dansmith | mriedem: wouldn't that only affect me if I'm running those tests though? | |
| 18:15:49 | dansmith | I get this if I run a single-shot test | |
| 18:17:03 | lbragstad | so - it is writing them to disk https://github.com/openstack/nova/blob/master/nova/tests/unit/policy_fixture.py#L97 | |
| 18:17:32 | mriedem | dansmith: i think the base test case class loads up the policy fixture | |
| 18:17:33 | mriedem | for all tests | |
| 18:17:47 | lbragstad | which would trip this case - https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L610-L625 | |