| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 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 | |
| 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 | |