| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-03 | |||
| 16:03:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: policies: Fix Sphinx issues https://review.openstack.org/480516 | |
| 16:03:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485 | |
| 16:03:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Remove dead files https://review.openstack.org/478470 | |
| 16:04:12 | mriedem | cdent: ok i was going to see if we needed any changes to the api-ref for the allocations minItems:1 thing | |
| 16:05:15 | cdent | mriedem: i think this one is allocations: https://review.openstack.org/#/c/470933/ | |
| 16:05:17 | cdent | so not merged yet | |
| 16:08:48 | cdent | mriedem: when you use the term “latent issue” what does that actually mean? | |
| 16:09:35 | mriedem | not introduced in pike | |
| 16:09:37 | mriedem | not a regression | |
| 16:10:02 | cdent | thanks | |
| 16:15:06 | mriedem | cdent: ok questions in https://review.openstack.org/#/c/470933/ | |
| 16:16:18 | cdent | mriedem: cool, I’ll hope andrey can look at those soon. If not, I can, I’m in the api-wg meeting now and then after that am gone (officially) until monday | |
| 16:31:11 | mriedem | dtantsur: jlvillal: did ironic ever go ahead with raising minimum required microversions? | |
| 16:31:51 | dtantsur | mriedem: nope, we haven't got to it | |
| 16:32:04 | dtantsur | I think we have an api-wg guideline for that, resulting from our discussions | |
| 16:33:17 | mriedem | ok | |
| 16:33:24 | mriedem | edleafe: i think the unit test failures in https://review.openstack.org/#/c/487925/ are probably related | |
| 16:33:42 | mriedem | it's super rare to have a random unit test failure with the ironic stuff in nova, and it's suspect when you're touching that driver | |
| 16:35:00 | mriedem | need some cores to look at this https://review.openstack.org/#/c/489763/ - it's a regression in pike, pretty simple fix | |
| 16:35:56 | edleafe | mriedem: those failures do seem to be more or less random. They don't happen locally | |
| 16:37:56 | mriedem | edleafe: i've never seen either of those happen in our ci though | |
| 16:39:13 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22AssertionError%3A%20Expected%20call%3A%20call('node.list'%2C%20associated%3DTrue%2C%20limit%3D0)%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d | |
| 16:39:28 | mriedem | that only shows up in that change | |
| 16:40:22 | openstackgerrit | Merged openstack/nova master: reflow rpc doc to 80 columns https://review.openstack.org/490455 | |
| 16:41:10 | openstackgerrit | Merged openstack/nova master: doc: Make use of definition lists, literals https://review.openstack.org/490481 | |
| 16:44:22 | mriedem | bauzas: any idea why the ServerGroupAntiAffinityFilter would stop working if you aren't tracking instance changes between the compute and scheduler service? Like i know there is a race possibility, but is that filter completely dependent on those? shouldn't it fallback to check the db or something if it's not tracking instance updates? | |
| 16:44:46 | mriedem | because with superconductor we don't have the upcalls from the computes to the scheduler for tracking instance chnages | |
| 16:44:48 | mriedem | *changes | |
| 16:48:39 | dansmith | jaypipes: I have emerged from my hole | |
| 16:50:43 | dansmith | jaypipes: any progress? | |
| 16:51:12 | jaypipes | dansmith: finishing up test runs now | |
| 16:51:50 | jaypipes | dansmith: had to go into your sched utils patch and add support for boot-from-volume... :( | |
| 16:54:05 | dansmith | my patch didn't regress that, right? | |
| 16:54:25 | dansmith | I dunno what change is needed for that, but I'll check it out when you push | |
| 16:55:54 | jaypipes | dansmith: mriedem had pointed out that we were not handling bfv in the "cheating" section. | |
| 16:56:06 | jaypipes | dansmith: thus my needing to put it into the resources_from_flavor() method | |
| 16:56:22 | dansmith | I'm saying I don't know what needs doing is all | |
| 16:56:31 | openstackgerrit | Jay Pipes proposed openstack/nova master: remove provider allocs in confirm/revert resize https://review.openstack.org/488510 | |
| 16:56:32 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add resource utilities to scheduler utils https://review.openstack.org/490514 | |
| 16:56:43 | jaypipes | dansmith: gotcha. it required passing the instance as well as flavor. pls see above. | |
| 16:56:57 | jaypipes | dansmith: I'm still working on the top patch (confirm resize one) | |
| 16:57:06 | jaypipes | dansmith: but figured I'd push to show you what I changed. | |
| 16:57:39 | dansmith | oh zeroing root, I see | |
| 16:57:54 | jaypipes | dansmith: ya | |
| 16:58:11 | jaypipes | dansmith: I added you as co-author on the confirm resize one. | |
| 16:58:21 | jaypipes | dansmith: tag, you're it. :) | |
| 16:58:24 | dansmith | co-blamee | |
| 16:58:34 | jaypipes | heh | |
| 16:58:36 | dansmith | jaypipes: does that mean you want me fixing the tests now? | |
| 16:59:11 | jaypipes | dansmith: nah, I might in a little bit, but I'm currently working on them. I need to head out at 12:15 your time, at which point I'll push what I've gotten done. | |
| 16:59:16 | dansmith | ah | |
| 16:59:19 | dansmith | er ack | |
| 17:04:09 | dansmith | once again, BFV is a blemish on otherwise organized stuff | |
| 17:07:26 | mriedem | didn't you see the ops thread? boeing wants all bfv all the time | |
| 17:07:43 | dansmith | lots of people do | |
| 17:07:53 | mriedem | by extension, the entire US military wants BFV | |
| 17:08:04 | mriedem | 25% budget baby! | |
| 17:08:05 | dansmith | and if we had the ephemeral driver, that would be totally fine | |
| 17:08:39 | mriedem | sorry, 60% i think | |
| 17:39:50 | mriedem | danicus maximus, are you ok with me adding the other limitations to the cells v2 doc like upcalls and such | |
| 17:39:51 | mriedem | ? | |
| 17:40:35 | dansmith | mriedem: sure, I was going to do that but then it merged | |
| 17:40:43 | dansmith | so I can if you want, but feel free | |
| 17:43:15 | mriedem | i'm going to poke through logs first and try to sort out just why the anti affinity group filter fails if we're not tracking instances | |
| 17:44:02 | dansmith | okay I'll push up some things for the doc then | |
| 17:50:36 | dansmith | mriedem: | |
| 17:50:53 | openstackgerrit | Dan Smith proposed openstack/nova master: Add a caveat section about cellsv2 upcalls https://review.openstack.org/490612 | |
| 18:02:13 | mriedem | what the f | |
| 18:02:38 | mriedem | sdague: this is totally wrong, right? https://github.com/openstack/nova/blob/master/nova/policies/server_groups.py#L34 | |
| 18:02:58 | mriedem | BASE_POLICY_RULE == rule:os_compute_api:os-server-groups | |
| 18:03:04 | mriedem | which should be something like, rule:admin_or_owner | |
| 18:05:04 | jaypipes | dansmith: still working on fixes. down to the one func test failure (that ocata pike ironic one). unit tests all fixed up now. | |
| 18:05:08 | sdague | mriedem: yeh, that doesn't look right | |
| 18:05:17 | dansmith | jaypipes: ack | |
| 18:06:07 | mriedem | sdague: goes back to ocata https://review.openstack.org/#/c/391113/ | |
| 18:06:21 | mriedem | edmondsw: ^ you helped review this | |
| 18:06:25 | mriedem | does this make any sense? | |
| 18:10:32 | edmondsw | mriedem sdague yeah, there's some odd history there | |
| 18:11:06 | mriedem | well i see that here https://review.openstack.org/#/c/391113/13/nova/api/openstack/compute/server_groups.py | |
| 18:11:13 | mriedem | it was doing context.can(sg_policies.BASE_POLICY_NAME) | |
| 18:11:21 | edmondsw | originally there was only rule:os_compute_api:os-server-groups and for backward compat we wanted whatever someone had for that to still be what they got if they used the new rules | |
| 18:11:25 | mriedem | and the rule for that was | |
| 18:11:26 | mriedem | policy.RuleDefault( | |
| 18:11:26 | mriedem | name=BASE_POLICY_NAME, | |
| 18:11:26 | mriedem | check_str=base.RULE_ADMIN_OR_OWNER), | |
| 18:11:49 | mriedem | it was using rule:admin_or_owner before | |
| 18:11:58 | mriedem | i don't see where rule:os_compute_api:os-server-groups came from | |
| 18:13:49 | edmondsw | tat is rule:os_compute_api:os-server-groups that you just pasted | |
| 18:14:21 | edmondsw | BASE_POLICY_NAME = os_compute_api:os-server-groups | |
| 18:14:44 | edmondsw | so in order for the the new rules to default to whatever you have set for that old rule, we pointed them to the old rule... rule:os_compute_api:os-server-groups | |
| 18:14:49 | edmondsw | mriedem make sense? | |
| 18:15:08 | edmondsw | backward compat and policy are a nightmare... | |
| 18:15:19 | edmondsw | one of the things we want to talk about fixing at the PTG | |
| 18:18:06 | mriedem | so context.can(sg_policies.BASE_POLICY_NAME) turns that into rule:os_compute_api:os-server-groups ? | |
| 18:18:09 | mriedem | in oslo.context? | |
| 18:18:12 | mriedem | or oslo.policy | |
| 18:18:39 | mriedem | isn't context.can just looking up the action? | |
| 18:18:44 | mriedem | which was os_compute_api:os-server-groups | |
| 18:18:51 | mriedem | and in the before times, that mapped to rule:admin_or_owner | |
| 18:18:53 | mriedem | not rule:os_compute_api:os-server-groups | |