| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 13:46:12 | openstack | bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,New] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 13:46:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 13:46:18 | mriedem | dansmith: see ^ | |
| 13:46:19 | mriedem | :) | |
| 13:46:30 | dansmith | mriedem: you said < pike | |
| 13:46:44 | mriedem | i was told python3 packages were in the pike UCA | |
| 13:46:46 | mriedem | maybe they arent | |
| 13:46:56 | mriedem | dansmith: same problem though | |
| 13:47:02 | dansmith | okay | |
| 13:47:11 | mriedem | https://review.openstack.org/#/c/512622/ should fix it | |
| 13:48:17 | alex_xu | efried: yes, for that case, we defintely need the numbered request. I think the case we only request VCPU & MEMORY_MB and VF, this case whether can work for non-numbered request | |
| 13:51:14 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 13:51:17 | efried | alex_xu But you're right - it sounds like we need to write up some scenarios for the non-numbered group. Not sure where it would be appropriate to do that. Perhaps a delta to your traits-in-allocations spec? | |
| 13:53:12 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add attachment_get to refresh_connection_info https://review.openstack.org/512626 | |
| 13:54:39 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 13:54:51 | alex_xu | efried: yea, i'm not sure it should be in the trait spec, but I feel it should be at somewhere | |
| 13:56:07 | efried | alex_xu I covered some of it in passing in the granular request syntax spec, but dansmith will eviscerate me if I put more words in that one. | |
| 13:56:25 | dansmith | efried: not only that, | |
| 13:56:35 | dansmith | efried: but I'm reserving my +2 until you remove some :) | |
| 13:56:49 | efried | vay, really? Sigh, okay. | |
| 13:57:14 | efried | I read "just a tip" as "do better next time" | |
| 13:57:46 | dansmith | efried: the two use cases you call out and then say are out of scope really need to go, IMHO | |
| 13:58:00 | dansmith | the just a tip bit was a suggestion, and I think you should | |
| 13:58:04 | alex_xu | learned a new word 'eviscerate', that is terrible | |
| 13:58:17 | dansmith | lol | |
| 13:58:24 | dansmith | alex_xu: his word not mine :) | |
| 13:58:38 | alex_xu | okay.. | |
| 13:59:04 | mriedem | dansmith: if you're looking at stuff for pike, we need to get this fix in and backported to pike https://review.openstack.org/#/c/510938/ | |
| 13:59:12 | mriedem | otherwise restart after evacuate blows up | |
| 13:59:12 | openstackgerrit | Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879 | |
| 13:59:29 | dansmith | mriedem: I was just looking at your backport of my context fix when I saw that | |
| 13:59:30 | efried | dansmith This ^ oughtta be passing now, I believe. | |
| 13:59:47 | dansmith | efried: I was just getting ready to respond to cdent on that | |
| 14:00:38 | mriedem | bauzas: you want to look at this then? https://review.openstack.org/#/c/510938/ | |
| 14:00:53 | mriedem | need to wrangle our pike fixes for a release | |
| 14:01:03 | mriedem | since we have several high severity ones that are unreleased | |
| 14:01:15 | efried | dansmith I'll wait to respond until I see what you have to say, then. | |
| 14:02:38 | bauzas | mriedem: sure, will look | |
| 14:03:01 | gibi | mriedem: there is another bug 1724172 with fix top of https://review.openstack.org/#/c/510938/ | |
| 14:03:02 | openstack | bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 14:03:38 | bauzas | edmondsw: sdague: does that https://bugs.launchpad.net/nova/+bug/1716344 ring a bell to you ? (tl;dr: the fact that we only lookup the public endpoint when querying the SC) | |
| 14:03:39 | openstack | Launchpad bug 1716344 in OpenStack Compute (nova) "Nova-API uses Keystone's public endpoint for project id verification" [Undecided,New] | |
| 14:04:39 | johnthetubaguy | edmondsw: very late but I found that patch you were asking me about that the PTG, at least I think you asked me: https://review.openstack.org/#/c/434870 | |
| 14:07:26 | mriedem | ildikov: reading | |
| 14:07:44 | sdague | bauzas: so, we might be missing an option there | |
| 14:07:56 | sdague | that being said, this is definitely never called in vm crate | |
| 14:07:58 | sdague | create | |
| 14:08:20 | sdague | the only places this path is called is quota updates and flavor access calls | |
| 14:09:14 | dansmith | efried: left you a suggestion about the actual method, and one about cdent's retry | |
| 14:09:35 | dansmith | efried: the retry could be a follow-on since it really isn't related to this if you use the common method | |
| 14:09:39 | ildikov | mriedem: tnx | |
| 14:09:57 | efried | dansmith Roger wilco, and thanks. | |
| 14:10:13 | ildikov | mriedem: as the spec deadline is coming up I'm trying to clean this one up so we can merge it and update later on specifics if needed | |
| 14:10:53 | efried | dansmith Did you mean report.SchedulerReportClient.get_allocations_for_instance? | |
| 14:11:04 | dansmith | efried: rebase | |
| 14:11:15 | efried | dansmith ah, beaut. | |
| 14:11:21 | dansmith | efried: https://review.openstack.org/#/c/511306/ | |
| 14:11:25 | mriedem | bauzas: replied in that bug | |
| 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? | |