| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 17:46:47 | melwitt | yeah | |
| 17:47:14 | feefifofum | memory_mb - mb_used - x = free_ram_mb | |
| 17:47:17 | feefifofum | i don't know what x is though | |
| 17:47:45 | mriedem | feefifofum: you know that skipping from L to O isn't supported upstream right? and you'd need to check the release notes for M, N and O first | |
| 17:48:20 | mriedem | lbragstad: where is the default policy rule defined in keystone again? | |
| 17:48:22 | mriedem | i can never find it | |
| 17:48:40 | mriedem | it's not this https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L11 | |
| 17:50:00 | feefifofum | mriedem: yes i'm aware of the release notes | |
| 17:50:32 | sean-k-mooney | jangutter: i think this is legacy code that you dont need https://github.com/Netronome/agilio-ovs-openstack-plugin/blob/90c38378b772c8f82d5bc1752df60ec5055dca23/vif_plug_agilio_ovs/objects/vif.py#L24-L30 also multiple inheritence for multiple oslo_versioned objects will likely not work out well for you | |
| 17:50:47 | mriedem | feefifofum: are you looking in code? | |
| 17:50:52 | mriedem | it could be an overhead value | |
| 17:50:54 | sean-k-mooney | jangutter: on the plus side https://github.com/Netronome/agilio-ovs-openstack-plugin/search?utf8=%E2%9C%93&q=VIFAgilioOpenVSwitch&type= its not used anyware in the code | |
| 17:50:56 | mriedem | calculated from the virt driver | |
| 17:51:10 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L192 | |
| 17:51:37 | feefifofum | hmmm, this looks interesting. i'll take a closer look | |
| 17:51:41 | feefifofum | thanks mriedem | |
| 17:51:43 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/claims.py#L105 | |
| 17:57:46 | lbragstad | mriedem: we removed it | |
| 17:58:21 | lbragstad | mriedem: all of our policy bits are here - https://github.com/openstack/keystone/tree/b3fc06c9ef6a0a3d317f414962bab3d309c2e6c0/keystone/common/policies | |
| 17:58:40 | lbragstad | the basic rules are in base.py - https://github.com/openstack/keystone/blob/b3fc06c9ef6a0a3d317f414962bab3d309c2e6c0/keystone/common/policies/base.py#L15-L31 | |
| 17:59:34 | lbragstad | mriedem: edmondsw has proposed the removal of the default rule - https://review.openstack.org/#/c/482164/ | |
| 18:07:38 | mriedem | hmm | |
| 18:07:41 | mriedem | https://github.com/openstack/keystone/blob/b3fc06c9ef6a0a3d317f414962bab3d309c2e6c0/keystone/common/policies/base.py#L61 ok | |
| 18:07:46 | mriedem | well that's what i was looking for anyway | |
| 18:08:00 | mriedem | cdent: ^ | |
| 18:08:43 | lbragstad | mriedem: yeah - we're going to be removing that since every operation will be required to have a default | |
| 18:08:48 | cdent | what does it mean? | |
| 18:09:04 | mriedem | lbragstad: so does that mean if nova didn't defined a default rule, we wouldn't have a default at all then? | |
| 18:09:09 | mriedem | if keystone didn't define it? | |
| 18:09:11 | mriedem | or something else | |
| 18:09:14 | mriedem | https://review.openstack.org/#/c/481443/4/nova/policies/base.py | |
| 18:09:25 | lbragstad | that default is specific to keystone APIs | |
| 18:09:39 | mriedem | ok that's what i was wondering | |
| 18:09:43 | lbragstad | so if you made a request to keystone that we didn't have a policy entry for - we would normally apply that default | |
| 18:09:46 | mriedem | and these are the nova-api specific defaults https://review.openstack.org/#/c/481443/4/nova/policies/base.py | |
| 18:09:59 | lbragstad | but since each policy is formally moved into code and documented - a default of defaults doesn't really make sense | |
| 18:10:13 | lbragstad | aha - sure | |
| 18:10:31 | lbragstad | yeah - removing the keystone-specific defaults shouldn't impact that for nova | |
| 18:10:46 | mriedem | nova's default is different anyway | |
| 18:11:02 | lbragstad | right - and that makes sense | |
| 18:11:22 | lbragstad | i wouldn't expect each service's default rule to be the same | |
| 18:12:19 | cdent | (I think the issue in the review is more that policy file generation was leaving the default out? https://review.openstack.org/#/c/481443/ and if you try to use that file elsewhere, things go awry?) | |
| 18:12:28 | mriedem | cdent: i left a question in there | |
| 18:12:35 | cdent | thanks | |
| 18:12:40 | mriedem | compute:get_all is an old legacy v2 API rule i think | |
| 18:13:20 | mriedem | seems like a horizon bug actually | |
| 18:13:27 | lbragstad | speaking of policy - i was thinking about organizing a session in Denver focused on next steps (much like what we did in atlanta) | |
| 18:13:33 | lbragstad | is anyone here interested in that? | |
| 18:13:36 | cdent | could very welll be | |
| 18:14:52 | mriedem | i'm not interested in thinking about denver at all right now | |
| 18:15:06 | lbragstad | :) that's fair | |
| 18:15:40 | robcresswell | Ah, we still have references to the old style policy rules | |
| 18:15:45 | robcresswell | I can fix that. | |
| 18:16:08 | mriedem | robcresswell: someone already did https://github.com/openstack/horizon/blob/master/openstack_dashboard/conf/nova_policy.json | |
| 18:16:12 | mriedem | compute:get_all isn't in there | |
| 18:16:22 | mriedem | unless it's hard-coded | |
| 18:16:47 | robcresswell | mriedem: I co-authored on that. We've left a check on the rule in our admin > instances panel | |
| 18:17:05 | robcresswell | https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/instances/panel.py#L29 | |
| 18:17:30 | robcresswell | Is there a relevant bug open in Nova I can link to? | |
| 18:17:35 | mriedem | https://bugs.launchpad.net/horizon/+bug/1703066 | |
| 18:17:36 | openstack | Launchpad bug 1703066 in OpenStack Compute (nova) " Add "default" rule when generate policy.yaml.sample" [Undecided,Incomplete] - Assigned to KaiLi (damonl1) | |
| 18:17:39 | mriedem | just added horizon to it | |
| 18:17:46 | robcresswell | Thanks | |
| 18:17:53 | mriedem | np | |
| 18:17:57 | mriedem | cdent: -1 on the nova change then | |
| 18:18:05 | cdent | thanks to all three of you | |
| 18:18:07 | cdent | yeah, totes | |
| 18:21:03 | robcresswell | Whats the equivalent of "get_all"? "os_compute_api:servers:index"? | |
| 18:21:14 | mriedem | yeah | |
| 18:21:33 | mriedem | well, | |
| 18:21:37 | mriedem | depends, do you need details? | |
| 18:21:48 | mriedem | because then it would be os_compute_api:servers:detail | |
| 18:21:51 | mriedem | "os_compute_api:servers:detail" | |
| 18:21:54 | mriedem | blast | |
| 18:22:35 | robcresswell | That particular check is just saying "can I list all instances" I believe. | |
| 18:22:43 | robcresswell | on the horizon side, I mean | |
| 18:22:48 | mriedem | i'll check some old nova code | |
| 18:23:11 | robcresswell | It looks like that last patch replaced get_all with "os_compute_api:servers:index:get_all_tenants" in a couple of places | |
| 18:23:24 | mriedem | that would be wrong | |
| 18:23:38 | mriedem | the old version of that was compute:get_all_tenants | |
| 18:23:50 | robcresswell | gotcha | |
| 18:23:50 | robcresswell | thanks | |
| 18:23:53 | mriedem | the all tenants stuff is admin only by default | |
| 18:24:04 | mriedem | since tenant A shouldn't be able to list instances from tenant B | |
| 18:24:45 | mriedem | compute:get_all was used for both index and detail in the v2 API | |
| 18:24:50 | mriedem | so you can use the index or detail one, either is fine | |
| 18:25:19 | mriedem | well, i mean it really depends on what you're going to be doing - if you're going to be getting servers with details to show details, then you want the details one | |
| 18:25:50 | robcresswell | Is that the same as viewing the details of a specific server? | |
| 18:25:56 | mriedem | nope | |
| 18:25:57 | mriedem | :) | |
| 18:26:25 | robcresswell | Whats the policy for that? | |
| 18:26:36 | mriedem | i think that's "os_compute_api:servers:show" | |
| 18:26:48 | robcresswell | Ah! Yes | |
| 18:26:53 | robcresswell | Very good | |
| 18:28:46 | robcresswell | mriedem: https://review.openstack.org/#/c/483501/ | |
| 18:29:01 | openstackgerrit | zhang zhenzhong proposed openstack/nova master: fix rp registration failed while placement endpoint created after compute start https://review.openstack.org/483460 | |
| 18:29:52 | dansmith | melwitt: agree that less behavioral change is better | |
| 18:30:41 | melwitt | cool. I think we all agree, so I'll nix the pending resizes stuff | |
| 18:30:43 | robcresswell | mriedem: Right, I'll get that merged ASAP and backport it. Thanks for the help. | |
| 18:30:53 | melwitt | and put back the current behavior | |