| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 14:11:36 | bauzas | sdague: you mean, calling verify_project_id is just made by quota updates and flavor calls? | |
| 14:11:41 | mriedem | efried: your new ksa adapter stuff defaults to the internal interface right? | |
| 14:11:45 | mriedem | it goes internal and then public? | |
| 14:11:51 | mriedem | bauzas: correct | |
| 14:11:56 | mriedem | it wouldn't make vm create fail | |
| 14:12:12 | efried | mriedem Yes | |
| 14:12:34 | efried | mriedem nova.conf.utils.py L47 | |
| 14:12:49 | mriedem | ok, just checking. we can't rely on that for fixing this anyway. | |
| 14:12:54 | mriedem | since the fix here would have to be backported | |
| 14:13:31 | bauzas | mriedem: okay, so I'll triage it as Wontfix if that bug is punted by efried's KSA rework | |
| 14:13:46 | mriedem | bauzas: i don't think that's the right way to handle this | |
| 14:13:56 | bauzas | open to ideas :) | |
| 14:13:58 | mriedem | you can't backport the ksa fixes | |
| 14:14:13 | bauzas | so we at least need to idenfify the impact | |
| 14:14:13 | mriedem | and we effectively made a backward incompatible change in pike to those apis | |
| 14:14:29 | mriedem | you can't update quota or flavor access if nova can't access keystone's public endpoint | |
| 14:14:51 | bauzas | so it was a design decision to use the public endpoint for such calls ? | |
| 14:15:02 | bauzas | I'm having trouble understanding your sentence about ^ | |
| 14:15:13 | mriedem | yes, but the same design decision was made with placement and we later changed that when someone said it broke their deployment | |
| 14:15:18 | bauzas | I mean "There was a conscious decision to hard-code the public endpoint as the interface when this change was made, but we changed that hard-coding for nova talking to the placement endpoint so I don't see why we wouldn't also allow different endpoints for talking to keystone. " | |
| 14:15:36 | bauzas | ah gotcha | |
| 14:15:56 | bauzas | mriedem: there are 2 possibilities honestly | |
| 14:16:07 | mriedem | https://review.openstack.org/#/c/435010/6/nova/identity.py@34 | |
| 14:16:21 | bauzas | mriedem: either we say it's a bug that is backportable, and I'm tagging the bug as Confirmed | |
| 14:16:32 | edmondsw | johnthetubaguy thanks! Looking at it now | |
| 14:17:02 | sdague | mriedem: what is your concern here? | |
| 14:17:03 | bauzas | mriedem: or we just consider it's more a new design rearchitecture, and in that case, that would make the changes very difficult to backport | |
| 14:17:52 | mriedem | "Keystone's public endpoint should only visible to external clients. All internal OpenStack services should use the internalURL for authentication purposes. I think my configuration is correct. The "auth_url" point to Keystone's internal URL, whereas "auth_uri" points to Keystone's public endpoint. I want to avoid https based communication for my internal cloud services." | |
| 14:19:03 | sdague | mriedem: yes, I've read the bug. I don't understand the backwards incompatibility concern | |
| 14:20:02 | mriedem | asking for clarification in the bug | |
| 14:20:09 | mriedem | it's not clear to me if the apis fail, or if they just dump errors | |
| 14:20:47 | sdague | I think it's a real fail | |
| 14:20:58 | sdague | but not on the API call they stated | |
| 14:21:05 | mriedem | yes it's not instance create | |
| 14:21:13 | mriedem | they later said it was the flavor access project id verification | |
| 14:21:23 | mriedem | "It took some time to narrow down the problem. The issue was introduced with the Pike release, where project id verification for flavor access and quota modification got added." | |
| 14:22:22 | gongysh | hi | |
| 14:22:32 | mriedem | i don't think the api actually fails, they hit this: https://github.com/openstack/nova/blob/master/nova/api/openstack/identity.py#L57 | |
| 14:22:37 | gongysh | it seems the nested-quota is not implemented yet. right? | |
| 14:22:38 | mriedem | which dumps a stacktrace and returns True | |
| 14:22:42 | mriedem | gongysh: correct | |
| 14:23:14 | gongysh | mriedem, do you if there is alter option? | |
| 14:23:19 | sdague | mriedem: it might b | |
| 14:23:26 | mriedem | gongysh: not in nova no | |
| 14:23:45 | mriedem | gongysh: see the unified limits effort in keystone | |
| 14:23:58 | mriedem | gongysh: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html | |
| 14:29:55 | mriedem | ildikov: johnthetubaguy: replied in https://review.openstack.org/#/c/499777/4 about delete_on_termination | |
| 14:30:14 | mriedem | tl;dr is that if we fail to delete a volume we handle the error and log a warning, everywhere | |
| 14:30:54 | johnthetubaguy | mriedem: so you think we just allow delete_on_termination for multi-attach volumes? | |
| 14:30:58 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 14:30:59 | mriedem | so if you boot from volume with a multi-attach volume and specify delete_on_termination=True, and that volume is attached to another instance when the first is deleted, it won't prevent the deletion on the first instance, it will just log a warning in the logs about being unable to delete the volume | |
| 14:31:32 | johnthetubaguy | I guess it would just be deleted by the last detach, probably | |
| 14:31:34 | mriedem | johnthetubaguy: i'm not sure there is a great reason to not allow it | |
| 14:31:44 | mriedem | johnthetubaguy: well, not necessarily | |
| 14:32:12 | mriedem | if instance A and B are attached to volume X, and A.delete_on_termination=True and B.delete_on_termination=False, then deleting A won't delete X and deleting B won't either | |
| 14:32:15 | johnthetubaguy | I think its a race for the delete, like it could delete it | |
| 14:32:17 | johnthetubaguy | yeah | |
| 14:32:30 | johnthetubaguy | I should have defined my "probably" bit better | |
| 14:32:51 | mriedem | if B is deleted before A, then yes X would be deleted | |
| 14:33:00 | mriedem | ultimately the lock is supposed to be on the cinder side | |
| 14:33:15 | johnthetubaguy | ++ | |
| 14:33:43 | mriedem | and i think it's just something a user would have to understand if they are attaching a multi-attach volume to an instance with delete_on_termination, that nova can't actually delete that volume if it's attached to another instance | |
| 14:33:56 | johnthetubaguy | OK, my thinking was, seems odd to delete a multi-attach volume on delete, gonna be racey, lets just not allow that flag to be set. | |
| 14:33:59 | ildikov | so the conclusion is to allow it, right? | |
| 14:34:02 | ildikov | mriedem: +1 | |
| 14:34:07 | mriedem | ildikov: i don't see a reason not to | |
| 14:34:18 | ildikov | mriedem: cool, my thinking as well | |
| 14:34:27 | johnthetubaguy | OK, so you are both thinking that way, willing to go with that | |
| 14:34:38 | ildikov | johnthetubaguy: thank you :) | |
| 14:35:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879 | |
| 14:35:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 14:35:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 14:56:15 | johnthetubaguy | mriedem: if you get a moment, I attempted pseudo code for the shared connection locking, that feels like the last bit of detail we need in there: https://review.openstack.org/#/c/499777/5/specs/queens/approved/cinder-volume-multi-attach.rst@53 | |
| 14:58:06 | sean-k-mooney | johnthetubaguy: cfriesen am i remebering correctly that ye were both interested in bandwidth based scheduling at the ptg | |
| 14:58:40 | johnthetubaguy | sean-k-mooney: I was probably incorrectly interested, snowed up with other things honestly | |
| 14:59:19 | sean-k-mooney | johnthetubaguy: ack ok i was just going to flag https://review.openstack.org/#/c/502306/12 to you if you cared to review | |
| 15:00:05 | johnthetubaguy | sean-k-mooney: cool, can't promise I will get to that I am afraid, chasing a few other things | |
| 15:00:26 | sean-k-mooney | johnthetubaguy: no worries | |
| 15:01:27 | mriedem | sean-k-mooney: i know huawei is interested in that | |
| 15:01:31 | mriedem | but i haven't had a chance to review the spec yet | |
| 15:02:56 | sean-k-mooney | mriedem: ralonsoh is getting a little concerned that it may get caught by the spec approval deadline on thrusday? | |
| 15:03:10 | mriedem | everyone is getting concerned about that for their specs | |
| 15:03:15 | melwitt | mriedem: the py3 packages are definitely in the pike uca. how does checking for the py3 env protect against packages missing < pike? | |
| 15:03:30 | mriedem | melwitt: because the jobs that this is breaking aren't running with py3 | |
| 15:03:50 | mriedem | that check is based on a localrc flag set by devstack-gate which is set by the job config | |
| 15:04:08 | mriedem | our live migration job which uses ceph does not run under py3 | |
| 15:04:12 | sean-k-mooney | efried: bauzas ye both previously reviewed https://review.openstack.org/#/c/502306/12 is it on your backlog to re review in the next few days? | |
| 15:04:25 | melwitt | mriedem: ack | |
| 15:04:38 | bauzas | sean-k-mooney: thanks for the ping, sure I'll do | |
| 15:04:48 | mriedem | johnthetubaguy: reading - not sure how the lock fixes things when the instances attached to the volume are on different compute hosts and we're not using a DLM | |
| 15:04:52 | mriedem | but i know we've been over that | |
| 15:05:30 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854 | |
| 15:05:31 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/510159 | |
| 15:05:31 | openstackgerrit | Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357 | |
| 15:05:48 | sean-k-mooney | mriedem: ack, that is fair i just said i would flag it again incase anyone was interested. | |
| 15:06:00 | johnthetubaguy | mriedem: there is no conflict there, AFAIK, I thought it was just on the operations os-brick does on the hypervisor (and the operations cinder does on delete_attachment and update_attachment) | |
| 15:06:51 | efried | sean-k-mooney Can do; though I'm not sure I'm qualified to +1 it. | |
| 15:07:12 | johnthetubaguy | mriedem: although I think I see what you mean now | |
| 15:07:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.openstack.org/512552 | |
| 15:07:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1724172 in the functional test env https://review.openstack.org/512553 | |