| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-15 | |||
| 12:11:10 | mriedem | i don't see efried commenting in PS1 | |
| 12:11:18 | mriedem | i also see dansmith did some review on this... | |
| 12:12:13 | stephenfin | I must have changed the Change-ID at some point (initial version simply added use of :oslo.config:option: to one of the docs) | |
| 12:13:23 | efried | Yeah, I remember you saying this was interesting to me, and glancing at it, and not fully understanding why, and balking at the size of it, and not getting further into it where I might have been able to answer that question. | |
| 12:18:24 | mriedem | we could benefit from some docs on the object version registry, nova object serializer, how objects are registered into that, how backporting of versioned objects works, conductors role in all that stuff, etc | |
| 12:25:09 | kashyap | stephenfin: Heh, on your docs patch, very dansmith-esque rationale: "Dropped a bunch of random comments in here, surely some of them addd up to a -1" :D | |
| 12:34:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Trivial typo fix for REST API in policy enforcement docs https://review.openstack.org/643569 | |
| 12:38:23 | mdbooth | dansmith: You in, yet? | |
| 12:38:45 | kashyap | He should be, it is already 05:40 AM. Too late | |
| 12:38:59 | mdbooth | dansmith: I have confirmed btw that my monkey_patch patch fixes non-wsgi, but not wsgi, and crucially I now understand why | |
| 12:40:02 | mdbooth | It's a good patch, but incomplete. I'm just working on a follow up which I hope should fix everything and bring all our monkey patching hacks into 1 place. I'm happy to keep them separate or merge. Discuss when you get in? | |
| 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 | |