| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 17:08:23 | jaypipes | 143gg | |
| 17:08:27 | jaypipes | guh | |
| 17:20:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Consistent policies https://review.openstack.org/479774 | |
| 17:20:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update policy descriptions for base. https://review.openstack.org/472622 | |
| 17:25:55 | cdent | mriedem: if you’re in a policy kind of way, does this make sense: https://review.openstack.org/#/c/481443/ | |
| 17:37:44 | melwitt | internet is on the fritz again. comcast ... | |
| 17:37:56 | melwitt | dansmith: roger that. will update | |
| 17:38:56 | mriedem | cdent: oh boy | |
| 17:39:13 | mriedem | so, it usually takes me about 3 days to figure out where the rules are defined | |
| 17:39:45 | melwitt | dansmith, mriedem I have been wondering about the behavior change for resize confirm/revert. currently, it's possible to fail confirm/revert with OverQuota. during earlier discussions on the quota patch review (the monolith) we were thinking we should change the behavior and not block confirm/revert and instead limit max pending resizes | |
| 17:39:55 | cdent | this is part of why I’m asking because me<->policies, not friends | |
| 17:39:55 | melwitt | should we keep with that change or should we maintain the current behavior? | |
| 17:40:25 | mriedem | melwitt: i'm generally not in favor of behavior changes slipping in with major refactors | |
| 17:40:35 | mriedem | because it adds all the extra complication | |
| 17:40:44 | mriedem | but i don't know why the original decision was made | |
| 17:40:49 | mriedem | ? | |
| 17:40:49 | mriedem | you said that was from johnthetubaguy | |
| 17:41:16 | melwitt | I thought it was johnthetubaguy who suggested it but I might be remembering that wrong. it was months ago | |
| 17:41:56 | melwitt | yeah, I feel like I'm not too into the idea of changing the behavior either. I was thinking about it and I don't think you can get stuck in a limbo state with a pending resize | |
| 17:42:13 | melwitt | if you get blocked on confirm, you can revert. if you get blocked on revert, you confirm. unless I'm missing something | |
| 17:42:13 | mriedem | cdent: so i think the answer is it comes from somewhere in the bowels of keystone | |
| 17:42:56 | mriedem | so you'd get blocked on confirm if you are resizing up, yes? | |
| 17:43:02 | melwitt | yes | |
| 17:43:06 | mriedem | how do you get blocked on revert? resizing down? | |
| 17:43:08 | mriedem | so the revert goes up | |
| 17:43:09 | melwitt | yes | |
| 17:43:22 | melwitt | resize down generally isn't a thing but I think it's allowed for BFV | |
| 17:43:25 | mriedem | since we don't have reservations for resize now, | |
| 17:43:37 | mriedem | well, | |
| 17:43:46 | mriedem | nvm | |
| 17:43:54 | mriedem | i was thinking somehow reservations in the old way helped this here | |
| 17:44:04 | mriedem | but that would only help when you're resizing up | |
| 17:44:24 | mriedem | well either way i guess, | |
| 17:44:41 | mriedem | but yeah if this was a way you could fail over quota before, i don't know why we wouldn't just continue to count quota on confirm/revert | |
| 17:44:50 | mriedem | and fail if the current state of the world has changed and you're screwd | |
| 17:44:53 | mriedem | *screwed even | |
| 17:45:33 | openstackgerrit | Merged openstack/nova master: api-ref: Add missing parameters in limits.inc https://review.openstack.org/475640 | |
| 17:45:51 | feefifofum | hi, i'm working on upgrading from liberty to ocata and noticed a difference in how hypervisor memory usage is reported | |
| 17:46:12 | feefifofum | in liberty, memory_mb - memory_mb_used = free_ram_mb | |
| 17:46:37 | feefifofum | however in ocata, there is a different quantity now | |
| 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 | |