| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-22 | |||
| 15:22:47 | bauzas | for my flight :( | |
| 15:23:14 | bauzas | but yeah, we could discuss about rebuilding volume-backed stuff with Cinder folks | |
| 15:23:16 | bauzas | anyway | |
| 15:23:40 | mriedem | we'll be sure to schedule all cheese-related discussions for friday morning | |
| 15:26:12 | dansmith | jaypipes: I approved that spec | |
| 15:26:25 | dansmith | jaypipes: you can repay me by approving this compute rpc compat drop, which I know you want anyway: https://review.openstack.org/#/c/543580/ | |
| 15:27:17 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813 | |
| 15:31:15 | bauzas | mriedem: on an interop concern, should we accept other APIs but the ones we have in-tree ? https://bugs.launchpad.net/nova/+bug/1751036 | |
| 15:31:15 | openstack | Launchpad bug 1751036 in OpenStack Compute (nova) "ConfigFileValueError when defining enabled_apis" [Undecided,New] | |
| 15:31:19 | bauzas | I tend to say no | |
| 15:36:10 | melwitt | mriedem: please double check me on the rc3 tag https://review.openstack.org/#/c/547031/1/deliverables/queens/nova.yaml | |
| 15:37:58 | mriedem | efried: jaypipes: dansmith: left a comment in that spec https://review.openstack.org/#/c/546009/ - fine to amend with some details | |
| 15:39:07 | mriedem | melwitt: done | |
| 15:39:32 | mriedem | melwitt: also that commit hash might end up being a merge commit | |
| 15:39:41 | mriedem | that's why we need the depends-on | |
| 15:39:59 | melwitt | mriedem: thanks. so if I keep the commit hash the same + depends-on, it will work fine? | |
| 15:40:37 | mriedem | not if we need to use a merge commit | |
| 15:40:47 | mriedem | i would just add the depends-on and then WIP | |
| 15:41:02 | mriedem | don't want to get caught by the old smcginnis trigger finger | |
| 15:41:15 | melwitt | oh okay. I thought I had seen you propose a commit hash ahead of merge before but maybe I made that up | |
| 15:41:29 | smcginnis | :) | |
| 15:41:31 | mriedem | i generally do, and the job fails until i fix it up | |
| 15:41:36 | melwitt | thanks | |
| 15:44:03 | openstackgerrit | Merged openstack/nova-specs master: Filter Resource Provider List for Traits https://review.openstack.org/546009 | |
| 15:44:08 | jaypipes | mriedem: k | |
| 15:45:30 | mriedem | bauzas: i'm sort of surprised we don't allow ec2 in enabled_apis? i'm not sure how the ec2api code works w/o that | |
| 15:46:53 | bauzas | mriedem: ec2api is somehow stale now AFAIK | |
| 15:47:05 | bauzas | ansiwen: around ? | |
| 15:47:23 | bauzas | ansiwen: see mriedem's point about ec2api not being in the enabled apis | |
| 15:47:31 | bauzas | if so, is it run separately? | |
| 15:47:56 | mriedem | it's still maintained | |
| 15:47:56 | bauzas | mriedem: back to my original concern, I don't see why Nova should support other out-of-tree APIs | |
| 15:48:26 | bauzas | if people want to run their own APIs, why not running a specific WSGI server et voilà ? | |
| 15:48:32 | bauzas | a new endpoint | |
| 15:49:31 | edleafe | bauzas: I've wanted to simplify the pathing to reflect that there is only one Nova API | |
| 15:49:48 | edleafe | bauzas: e.g., change nova/api/openstack/compute to just nova/api/compute | |
| 15:50:13 | edleafe | But alex_xu has pointed out there are compatibilty issues | |
| 15:50:24 | edleafe | with api-paste.ini | |
| 15:50:35 | bauzas | edleafe: so you pointed me that enabled_apis shouldn't accept more than just nova and metadata ? | |
| 15:50:52 | mriedem | what does the GCE API do? | |
| 15:50:53 | bauzas | s/pointed/agreed with ? | |
| 15:52:32 | bauzas | mriedem: mmm, WAT ? | |
| 15:52:34 | dansmith | mriedem: I guess I see that distinction as a fundamental difference between allocation_candidates and resource_providers | |
| 15:52:36 | mriedem | https://github.com/openstack/gce-api/blob/master/gceapi/cmd/api.py#L34 | |
| 15:52:38 | bauzas | we have a GCE proxy ? | |
| 15:52:48 | mriedem | bauzas: the gce api proxy is way old | |
| 15:52:49 | dansmith | mriedem: which is kinda why we ended up adding a_c I think | |
| 15:53:15 | edleafe | bauzas: yeah, we only support the openstack api, so the extra directory level in the project is not needed | |
| 15:53:30 | bauzas | anyhow | |
| 15:53:34 | bauzas | let's triage the bug as Invalid | |
| 15:53:45 | bauzas | and ask them to run their own WSGI service | |
| 15:54:24 | bauzas | (FWIW, I know those OCCI folks since 2013, I'm not surprised they never went upstream) | |
| 15:55:03 | bauzas | mriedem: back to the ec2api, ansiwen told us that it was barely maintained | |
| 15:55:19 | mriedem | bauzas: done | |
| 15:55:24 | bauzas | so maybe it's some misunderstanding from me | |
| 15:55:38 | mriedem | well the occi nova ooi or whatever code is in github | |
| 15:55:47 | mriedem | so it's available, which is fine | |
| 16:02:14 | efried | mriedem: What dansmith said. It doesn't make sense for me to say "return me a list of resource providers where the union of all their traits is [this list]". Because I would either get all of them or none of them. An allocation candidate is a list of *groups* of resource providers, where each *group* must satisfy the list of traits. s/traits/resources/ and the answer is the same. | |
| 16:02:47 | efried | I.e. the difference between rp and ac for traits is the same as the difference between rp and ac for resources, if that makes any sense :) | |
| 16:03:14 | dansmith | efried: right, that's how I think of it exactly | |
| 16:06:47 | mriedem | i get it fellas | |
| 16:06:55 | mriedem | and it was discussed in comments in the spec, | |
| 16:07:00 | mriedem | but for posterity sake, | |
| 16:07:02 | mriedem | let's doc that in the spec | |
| 16:07:06 | mriedem | so a year from now we can say why | |
| 16:07:13 | efried | mriedem: Roger that, will do. | |
| 16:07:39 | dansmith | mriedem: if you mean saying "because a_c is $description, we behave this way on this..." then sure | |
| 16:08:13 | dansmith | I don't really want to have to fully explain a_c every time we do something like this, but... | |
| 16:08:30 | mriedem | you can explain it now in a doc so we can point people to it, | |
| 16:08:38 | mriedem | or you can explain it in channel once per quarter | |
| 16:10:43 | efried | or I can win the lottery and dansmith can explain it. | |
| 16:10:53 | efried | I'll write a fup. | |
| 16:12:27 | mriedem | will there be duty free irish spring at the airport? | |
| 16:12:35 | ansiwen | bauzas: mriedem , yeah, ec2api is a pure "hobby" project nowadays. Which doesn't mean it's not maintained. But there is less activity to be expected, compared to a project which is backed by a company that has commercial interests. | |
| 16:13:10 | mriedem | ansiwen: ack, and it has users, so maintenance is probably ok | |
| 16:13:24 | bauzas | call it maintenance state then | |
| 16:13:29 | bauzas | anyway | |
| 16:15:06 | ansiwen | bauzas: mriedem _if_ something breaks, it could take quite a while until it is fixed. | |
| 16:15:24 | mriedem | ansiwen: it takes us 4 years to fix a bug | |
| 16:15:26 | mriedem | so it's fine | |
| 16:15:27 | bauzas | that's exactly what a maintenance state describes | |
| 16:15:40 | bauzas | it doesn't tell you how long you will fix bugs | |
| 16:15:46 | ansiwen | mriedem: he he... ok, fair enough :-) | |
| 16:15:57 | bauzas | it will just say "okay, we know we have bugs and we will provide bugfixes soon" | |
| 16:16:18 | mriedem | soon, or not, | |
| 16:16:19 | mriedem | whatever | |
| 16:16:23 | bauzas | "but for features, don't get me wrong and don't expect a pony" | |
| 16:16:34 | mriedem | unless that pony makes it run at the EDGE | |
| 16:17:01 | bauzas | "unless you have your pockets full of dollars" | |
| 16:17:09 | bauzas | or euros, rather | |
| 16:17:12 | mriedem | right that too | |
| 16:17:14 | bauzas | given the exchange rate | |
| 16:18:35 | mriedem | jaypipes: so on your compute capabilities traits patch, i was thinking, | |
| 16:18:43 | bauzas | mriedem: unrelated, I looked at that bug this EU morning https://bugs.launchpad.net/nova/+bug/1750790 | |
| 16:18:43 | jaypipes | uhoh | |
| 16:18:43 | openstack | Launchpad bug 1750790 in OpenStack Compute (nova) "resources on target host aren't released if resize fails" [Undecided,New] | |
| 16:19:03 | mriedem | it should be possible to do my nova patch that adds the custom capabilities traits, then if/when we have them standardized in os-traits, we can swap those out, should be ok... | |
| 16:19:04 | bauzas | mriedem: and I wonder if that would merit a Wontfix given it's a pike change | |
| 16:19:15 | mriedem | although, anything relying on the former would have to change.. | |
| 16:19:28 | bauzas | s/pike change/pike bug/ | |