| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-15 | |||
| 12:40:25 | mdbooth | kashyap: Heh, for anybody else I wouldn't have bothered to ping at this time ;) | |
| 12:40:36 | kashyap | mdbooth: I know :-) Sorry for trolling | |
| 12:41:33 | mriedem | good god this doc needs updating https://docs.openstack.org/nova/latest/reference/scheduler-evolution.html | |
| 12:41:58 | kashyap | Does anyone here know if Ubuntu maintains Git repo for their Bionic QEMU packages? | |
| 12:42:57 | edleafe | mriedem: updating or deleting? | |
| 12:42:57 | openstack | Launchpad bug 1819794 in OpenStack Compute (nova) "nova-next job fail on Ubuntu Bionic" [Medium,Confirmed] | |
| 12:42:57 | kashyap | I ask because of this: it seems like a very Ubuntu might've messed something: https://bugs.launchpad.net/nova/+bug/1819794 | |
| 12:43:28 | mriedem | edleafe: some of the stuff in there still applies | |
| 12:43:50 | mriedem | but just stuff like "The recent NUMA features" that was written 3 years ago isn't so recent anymore | |
| 12:44:52 | edleafe | mriedem: it just seems that the bits that are still relevant don't merit a whole page in the docs. It's also a page that needs to be updated frequently | |
| 13:13:58 | openstackgerrit | Merged openstack/nova master: Avoid crashing while getting libvirt capabilities with unknown arch names https://review.openstack.org/643458 | |
| 13:24:03 | openstackgerrit | Matthew Booth proposed openstack/nova master: Fix SSL infinite recursion https://review.openstack.org/626952 | |
| 13:25:11 | openstackgerrit | Matthew Booth proposed openstack/nova master: WIP: Assert that we're monkey patching before importing https://review.openstack.org/643579 | |
| 13:25:24 | efried | mordred: dtantsur asked the question about openstacksdk-in-nova via https://review.openstack.org/#/c/642899/ -- which had to come up again sooner or later. When you have a minute, would you mind summarizing what would be involved in plumbing nova to use it? | |
| 13:26:29 | mordred | yes. happy to | |
| 13:26:33 | mordred | want me to do it on the review? | |
| 13:26:43 | openstackgerrit | Matthew Booth proposed openstack/nova master: DNM: What if we just monkey patched at the top level? https://review.openstack.org/643581 | |
| 13:33:49 | mordred | efried, dtantsur: Also - is this a thing you're wanting to squeeze in to stein? or for train? | |
| 13:34:14 | dtantsur | I'd expect Train to avoid surprises | |
| 13:34:35 | openstack | Launchpad bug 1820283 in OpenStack Compute (nova) "Scheduler Evolution in nova - the doc needs updating" [Medium,Confirmed] | |
| 13:34:35 | mriedem | edleafe: i just reported a bug so i don't lose track of the issues since i don't have time to work on it - those could all be worked as separate changes by interested contributors https://bugs.launchpad.net/nova/+bug/1820283 | |
| 13:35:04 | efried | mordred, dtantsur: Oh, yeah, Train fo sho. This first patch only swaps out one API; the work to hit all of them will be fairly extensive. And possibly warrants a blueprint as well. | |
| 13:35:36 | dtantsur | Which reminds me, I need to implement Baremetal Volume API in openstacksdk.. | |
| 13:35:37 | efried | mordred: Here probably better so I can ask questions (like, "whoah, you're assuming I know way more than I actually do") | |
| 13:35:58 | edleafe | mriedem: thanks for recording that. That page needs either a wholesale rewrite or a proper burial | |
| 13:40:34 | mordred | efried: well crap - I just responded to the patch :) | |
| 13:40:59 | mordred | efried: so maybe read that real quick and we can pick it up here | |
| 13:52:12 | efried | mordred: reading now, thanks. | |
| 13:55:53 | efried | mordred: "translating from service name to service type", like https://github.com/openstack/nova/blob/master/nova/utils.py#L1197-L1202 ? | |
| 13:57:29 | mordred | efried: yes. | |
| 13:57:40 | efried | so - already done \o/ | |
| 13:57:42 | efried | more or less | |
| 13:57:53 | mordred | efried: so - basically what we need is a loop that does what that's doing for all of the service types | |
| 13:58:33 | mordred | efried: and then we need to extract the parameters because the ks_loading.load_auth_from_ ... methods don't make sense in this context | |
| 13:58:41 | mordred | but it would be pretty quick/easy to do | |
| 13:58:57 | mordred | if we're talking train, it should be pretty easy to write the loader method in sdk | |
| 13:59:11 | efried | mordred: And as I understand it, the sdk contains "primitives" that will make e.g. https://review.openstack.org/#/c/642899/9/nova/virt/ironic/client_wrapper.py@101 (the node_get method) redundant and unnecessary. | |
| 13:59:18 | mordred | yes, that's right | |
| 13:59:52 | efried | cool. | |
| 14:00:06 | fried_rice | oh yeah ^ | |
| 14:00:25 | fried_rice | mordred: a little more on ks_loading_load_*_from conversion, if you please? | |
| 14:00:30 | mordred | efried: as a concrete example -- once you have a conn - you can either do conn.baremetal.get() for direct rest, or you can do conn.baremetal.chassis() to get a list of chassis | |
| 14:00:49 | fried_rice | mordred: ack, that makes sense (abstractly). | |
| 14:01:33 | mordred | fried_rice: yeah. sdk *needs* to be the one constructing the adapter, so it needs to consume those parameters as config input | |
| 14:01:42 | fried_rice | mordred: so right now we are, for all services (except maybe cinder?), doing this: https://github.com/openstack/nova/blob/master/nova/conf/ironic.py#L114-L115 | |
| 14:01:49 | mordred | it would be easier for it to also create the session and auth rather than having the ks_loading code do it | |
| 14:02:01 | mordred | yeah - totally - register_ksa_opts should stay | |
| 14:02:32 | fried_rice | so the ksa opts themselves don't change in the conf? That would be convenient. | |
| 14:02:35 | mordred | we just want to make the sdk be able to get its config from the same opts that ksa is defining | |
| 14:02:37 | mordred | yeah | |
| 14:02:53 | fried_rice | Ah nice. This sounds like a pretty low-surface-area change then, from a plumbing perspective. | |
| 14:03:04 | mordred | I *Think* there is a method call we can use to ask ksa what the opts are - so we should be able to be clever and the method should be pretty small | |
| 14:03:07 | mordred | yeah | |
| 14:03:29 | fried_rice | mordred: Yes, see https://github.com/openstack/nova/blob/master/nova/conf/utils.py#L58 | |
| 14:03:31 | mordred | it should be fairly easy - no noticable impact to deployers - and we should be able to delete a bunch of things from nova eventually | |
| 14:03:33 | fried_rice | i.e. we're already doing that. | |
| 14:04:03 | fried_rice | or rather https://github.com/openstack/nova/blob/master/nova/conf/utils.py#L36 | |
| 14:04:04 | mordred | yeah - awesome | |
| 14:04:21 | mordred | I can start a patch to sdk to add the conf loader function | |
| 14:04:31 | fried_rice | nice. | |
| 14:06:16 | mordred | I'm excited about this actually - I think it'll wind up being really helpful in both directions | |
| 14:06:20 | fried_rice | mordred: btw, in case you think this is all just serendipity, you helped me write all of that stuff. | |
| 14:06:38 | fried_rice | this is where you get to say things like, "I love it when a plan comes together". | |
| 14:07:28 | bauzas | internal meeting, in case people were looking at me | |
| 14:07:35 | fried_rice | mordred: agreed, there seems to be a lot of support for "get python-*client out of the way", to the point where I almost wonder whether it should be a Train community goal. | |
| 14:08:10 | fried_rice | mordred: I mean, it can be a U community goal, and that shouldn't stop us doing pieces of it in Train | |
| 14:08:22 | fried_rice | but that would get it more attention | |
| 14:09:31 | mordred | fried_rice: yeah - I thnik if we can get the sdk plumbed in and used in the places you're using adapters now (just the adapters on the sdk connection) | |
| 14:09:59 | mordred | then it'll be pretty easy then to pick off transitions one at a time - since the conn will be available and stuff | |
| 14:15:43 | openstackgerrit | Merged openstack/nova master: add python 3.7 unit test job https://review.openstack.org/610694 | |
| 14:20:01 | fried_rice | mordred: Well, tbh, the only place we're *actually* using the adapter that I know of is for talking to placement. | |
| 14:20:20 | fried_rice | mordred: All the other places we retrofitted to get and adapter so we could use its endpoint to pass to the client constructor and then throw the rest away. | |
| 14:20:40 | fried_rice | s/and adapter/an adapter/ | |
| 14:21:58 | fried_rice | mordred: that being the case, perhaps we could use the placement client (known as SchedulerReportClient) to lead the charge of testing the sdk plumbing. <== cdent | |
| 14:22:33 | cdent | i'd be pro that | |
| 14:22:56 | mordred | ++ | |
| 14:24:17 | fried_rice | mriedem, dansmith: Any foundational/historical/other reasons we shouldn't start doing this? (TLDR Incorporating openstacksdk into nova with the eventual goal of ripping out deps on python-*client and (directly) ksa.) | |
| 14:34:28 | bauzas | fried_rice: CLI is a thing, python bindings is another thing | |
| 14:34:43 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Bypass ironicclient for node.get https://review.openstack.org/642899 | |
| 14:34:58 | bauzas | having a client that's managed by the project teams sounds more maintainable | |
| 14:35:14 | bauzas | with regards to microversions in particular | |
| 14:35:30 | bauzas | I honestly thought about the OSC gap we have atm | |
| 14:35:41 | bauzas | with sean mooney as well | |
| 14:36:00 | fried_rice | bauzas: Sorry, I don't follow. Are you suggesting we keep python-*client in the mix?? | |
| 14:36:12 | bauzas | and we wonder whether we could just use the plugin interface of OSC for having our microversions support *in-tree* | |
| 14:37:10 | fried_rice | forget CLI for the moment; I'm talking about e.g. nova talking to ironic via openstacksdk rather than through python-ironicclient | |
| 14:37:22 | bauzas | fried_rice: IIRC we said in the past that we could probably one day have an OSC CLI which'd be using novaclient python PAI | |
| 14:37:26 | bauzas | API* | |
| 14:37:50 | bauzas | fried_rice: yup, got it | |
| 14:38:10 | bauzas | the problem is that we don't have support for OSC microversions. In what openstacksdk would change this ? | |
| 14:38:27 | bauzas | pardon my french | |
| 14:38:39 | bauzas | I mean 'we don't have OSC supporting nova API microversions' | |
| 14:40:26 | fried_rice | bauzas: forget OSC for the moment. | |
| 14:41:11 | fried_rice | Is there a reason we shouldn't rip out nova's dep on the pythot-ironicclient lib (see nova/virt/ironic/client_wrapper.py) | |
| 14:41:43 | fried_rice | s/pythot/python/ wow | |
| 14:44:52 | bauzas | fried_rice: is there a feature parity between ironicclient and openstacksdk ? | |
| 14:46:02 | bauzas | at least for compute, I can't see it https://docs.openstack.org/openstacksdk/latest/user/guides/compute.html | |
| 14:46:03 | fried_rice | bauzas: For many if not all of the APIs - creepy_owlet could answer that - but even if there's a specific API missing, we can use the adapter.get/put/post/delete primitives | |
| 14:46:55 | fried_rice | ...which is what I was starting to do (via ksa directly as opposed to sdk) via https://review.openstack.org/642899 which started this discussion. | |
| 14:48:13 | bauzas | I'm confused, I thought we were talking about the potential TC goal for Train | |