Earlier  
Posted Nick Remark
#openstack-nova - 2017-08-03
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
18:19:33 mriedem dansmith: i left some random thoughts in your cells v2 docs patch
18:19:43 mriedem fighting with over/under doc'ing
18:20:04 mriedem edmondsw: yeah here https://docs.openstack.org/nova/latest/configuration/sample-policy.html
18:20:08 dansmith mriedem: I was leaving the console thing to melwitt
18:20:09 mriedem #"os_compute_api:os-server-groups": "rule:admin_or_owner"
18:20:11 mriedem was the old thing
18:20:18 mriedem and was changed to
18:20:19 mriedem #"os_compute_api:os-server-groups:create": "rule:os_compute_api:os-server-groups"
18:20:44 mriedem which is exactly backward incompatible
18:22:37 mriedem edmondsw: also going back to mitaka before policy in code https://github.com/openstack/nova/blob/mitaka-eol/etc/nova/policy.json#L445
18:25:26 openstackgerrit Ed Leafe proposed openstack/nova master: Handle ironicclient failures in Ironic driver https://review.openstack.org/487925
18:27:24 mriedem edmondsw: https://bugs.launchpad.net/nova/+bug/1708508
18:27:24 openstack Launchpad bug 1708508 in OpenStack Compute (nova) "os-server-groups policy rules are wrong" [Undecided,New]
18:27:45 mriedem lbragstad: what happens if you define a policy action to have a rule which is not actually defined?
18:27:50 mriedem does it just default to the default rule?
18:28:18 lbragstad mriedem: i would assume that to error
18:28:20 lbragstad i can test though
18:28:27 mriedem lbragstad: like say i define "os_compute_api:os-server-groups:create": "rule:doesnotexist",
18:28:31 mriedem and there is no rule for doesnotexist
18:28:46 edmondsw mriedem os_compute_api:os-server-groups is a rule... the value for that rule is by default "rule:admin_or_owner" because there's another rule called admin_or_owner, and then you look at the value for admin_or_owner... they chain
18:28:53 edmondsw so what we did here was add another level to that chain
18:29:06 edmondsw when you use a rule as a value, you need to prefix "rule:"
18:29:14 edmondsw make sense?
18:29:22 mriedem no
18:29:24 mriedem looking at https://docs.openstack.org/nova/latest/configuration/sample-policy.html
18:29:34 mriedem i see
18:29:34 mriedem #"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
18:29:42 mriedem defining the policy for the admin_or_owner rule
18:29:50 edmondsw take "os_compute_api:os-server-groups:create": "rule:os_compute_api:os-server-groups" for example
18:29:56 mriedem oh shit
18:29:57 mriedem i get it now
18:29:57 mriedem #"os_compute_api:os-server-groups": "rule:admin_or_owner"
18:30:00 edmondsw :)
18:30:00 mriedem gdi
18:30:15 mriedem #"os_compute_api:os-server-groups:create": "rule:os_compute_api:os-server-groups"

Earlier   Later