| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-14 | |||
| 14:17:34 | bauzas | yeah zactly | |
| 14:17:51 | sdague | bauzas: so, please don't use the lessons from 5 years ago about the right patterns for today | |
| 14:17:58 | bauzas | fair enough | |
| 14:18:29 | bauzas | but the scheduler.report client module is doing more than just GET and POST, right? | |
| 14:19:16 | bauzas | should we leave other service projects writing their own methods like we do in that current scheduler module ? | |
| 14:19:42 | macsz | johnthetubaguy: thanks, will take a look as soon as I get a break from the training | |
| 14:21:27 | sdague | bauzas: the things that seem to be common is pretty much just the safe_connect wrapper there, what bits of complex logic would you expect would be needed in neutron? | |
| 14:22:12 | dansmith | no, I think a lot of what is there is pretty nova-specific | |
| 14:22:31 | sdague | bauzas: I'd much rather start under the assumption that a library is not needed, walk through doing an implementation in another service, figure out if there are common things that would be handy to share (like the safe connect bit) and maybe put that into a utility mixin or back in keystoneauth | |
| 14:22:40 | dansmith | there may be a few re-usable things, like "ensure_resource_provider()" but that's really just a get-and-post-on-404 | |
| 14:22:41 | dansmith | which is not worth a separate client | |
| 14:22:46 | bauzas | sdague: this for example https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L484 | |
| 14:23:09 | bauzas | neutron would provide their inventories, right? | |
| 14:23:12 | bauzas | or cinder | |
| 14:24:18 | cdent | (safe connect in keystoneauth makes good sense) | |
| 14:24:19 | sdague | bauzas: maybe, how about implement that first in one of those services and see | |
| 14:24:48 | openstackgerrit | Danil Akhmetov proposed openstack/nova master: Use proper user and tenant in the owner section of libvirt.xml. https://review.openstack.org/399679 | |
| 14:25:01 | bauzas | sdague: yeah we could possibly wait for other service projects calling the placement API and see if we need a common client package, maybe | |
| 14:25:03 | dansmith | bauzas: it's long, but really not much meat in there.. retry on 409 | |
| 14:25:14 | cdent | bauzas: neutron built in their own custom client for inventories: https://review.openstack.org/#/c/358658/ | |
| 14:26:07 | bauzas | cdent: but they don't have our story yet | |
| 14:26:16 | bauzas | sorry | |
| 14:26:20 | bauzas | s/story/background | |
| 14:26:33 | cdent | meaning what? | |
| 14:26:35 | bauzas | so I'm afraid of them missing some corner case | |
| 14:26:47 | bauzas | that we could have fixed in the scheduler.report module | |
| 14:26:55 | bauzas | like https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L596 | |
| 14:27:37 | bauzas | anyway, I'm not *that* concerned | |
| 14:27:54 | bauzas | if there is no traction around a specific common client, fine by me | |
| 14:28:00 | sdague | bauzas: honestly, I feel like this is part of the anti pattern. Deciding that projects that consume other project apis don't need to know how to use those APIs, and we'll hide everything in a library. If the API is hard to use correctly, that's data, and we should take it back to the API, not put a bunch of work around code around it | |
| 14:28:10 | bauzas | let's wait other projects using the placement API, and we'll see if we need a common one | |
| 14:28:52 | sdague | I mean, we were seriously talking 2 cycles ago about the neutron team building a nova consumption interface on top of their neutron client, because it was too hard to use. | |
| 14:28:52 | bauzas | sdague: that's a reasonable concern | |
| 14:29:02 | sdague | maybe it was more than 2 cycles ago | |
| 14:29:24 | bauzas | :) | |
| 14:29:53 | bauzas | yeah, that's a trade-off, I agree | |
| 14:30:09 | bauzas | if we can keep things simple, I'm all good | |
| 14:30:31 | bauzas | again, I'm seeing myself in a minority on that, so fair enough | |
| 14:30:37 | mriedem | i'm back, caught up | |
| 14:30:45 | jaypipes | mriedem: I'm strongly opposed to a separate client for placement. Having an openstackclient module for resource providers and inventories/allocations/aggregate associations is A-OK, but not a separate python client. | |
| 14:30:50 | mriedem | so no to the client for APIs, and no to CLI for osc? | |
| 14:30:57 | bauzas | it's a valid concern, and if people don't really want to have that common client, plus the concerns you mention, then I'm okay | |
| 14:31:27 | mriedem | i'm good with not having a python API client | |
| 14:31:37 | bauzas | jaypipes: OSC being only a CLI wrapper ? | |
| 14:31:38 | mriedem | i was wondering more about CLI | |
| 14:31:48 | mriedem | osc is a cli wrapper, not an api library | |
| 14:31:54 | mriedem | it uses the other client API libraries and the sdk | |
| 14:31:57 | bauzas | yeah, just wanted to reassure that | |
| 14:32:08 | bauzas | that we won't push smart code in OSC | |
| 14:32:40 | bauzas | again, if people feel confident with that, let's stick with dansmith's plan given in the ML | |
| 14:32:53 | bauzas | I don't want to divert too much on that | |
| 14:33:08 | bauzas | and we could raise a priority on writing a python client module if we need to | |
| 14:35:19 | jaypipes | mriedem: OSC doesn't *have* to import a placementclient lib, though. for example, we could just have make_client() return something similar to the keystone session object in the scheduler report client. | |
| 14:35:30 | jaypipes | mriedem: in other words, here's the compute example make_client() https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/client.py#L38 | |
| 14:35:55 | jaypipes | mriedem: we could just as easily change that code to just make a "client" for placement be the requests session and keystoneauth session | |
| 14:38:41 | bauzas | jaypipes: given how we heavily mention OSC in our docs, and given we would need that for shared storage stories, is there someone actively working on that? | |
| 14:38:45 | bauzas | for Pike, I mean | |
| 14:38:48 | jroll | jaypipes: your ironic get_inventory() thing lgtm, nice work | |
| 14:39:28 | jaypipes | bauzas: pretty sure we can find folks, yes. | |
| 14:40:08 | bauzas | cool :) | |
| 14:40:24 | mriedem | jaypipes: i know, i was actually thinking we'd have the osc plugin in nova, | |
| 14:40:26 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance-live_migration_abort notification https://review.openstack.org/420453 | |
| 14:40:32 | mriedem | and that gets split out with the server api stuff when it all happens | |
| 14:40:54 | mriedem | i thought projects were supposed to host osc plugins now, rather than try and put them all in osc itself and make that core team own them, | |
| 14:41:01 | mriedem | that's what i remember from a session in austin anyway | |
| 14:41:15 | jaypipes | mriedem: that's fine by me. | |
| 14:41:39 | mriedem | sdague: dansmith: are you against an osc plugin living in nova purely for CLI? | |
| 14:41:46 | mriedem | or meh? | |
| 14:41:59 | dansmith | against existence, or against living in nova? | |
| 14:42:04 | jaypipes | mriedem: probably a question for dtroyer too? | |
| 14:42:08 | mriedem | the former | |
| 14:42:11 | dansmith | no | |
| 14:42:29 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225 | |
| 14:42:40 | dansmith | there is that thing already yes? | |
| 14:42:48 | mriedem | dansmith: i don't see one | |
| 14:42:58 | mriedem | mlavalle's is a full blown client, like novaclient | |
| 14:43:03 | dansmith | oh, I thought it was a plugin | |
| 14:43:15 | mriedem | https://github.com/miguellavalle/python-placementclient/tree/adding-grp-support | |
| 14:44:07 | sdague | mriedem: in the nova tree? | |
| 14:44:30 | mriedem | sdague: yes, where placement currently lives | |
| 14:44:33 | sdague | I'm definitely -1 on in the nova tree, those things shouldn't be coupled that way | |
| 14:44:44 | mriedem | so openstack/placement-osc-plugin? | |
| 14:44:52 | sdague | mriedem: sure | |
| 14:45:05 | sdague | it can be under nova control, but you don't want to pip install all of nova | |
| 14:45:14 | sdague | to get 200 lines of osc plugin | |
| 14:45:14 | mriedem | oh right i didn't think about that | |
| 14:45:20 | bauzas | good point | |
| 14:45:21 | sean-k-mooney | mriedem: would it not make sense to have the placement osc plugin live in the placement repo when that is created | |
| 14:45:29 | mriedem | sean-k-mooney: but that's not pike, | |
| 14:45:32 | mriedem | or maybe even queens | |
| 14:45:39 | sdague | sean-k-mooney: no, it would not | |
| 14:45:51 | sdague | osc plugins should not be in the trees of larger projects | |
| 14:45:55 | bauzas | yeah | |
| 14:45:56 | jroll | mriedem: how we do osc stuff is the osc plugin goes in the python-ironicclient tree | |
| 14:46:08 | sdague | because osc plugins should be super minimal | |
| 14:46:21 | jroll | seems to work well, and you'll need the ironicclient dep anyway | |
| 14:46:34 | mriedem | jroll: we wouldn't have a dep on a placementclient though | |
| 14:46:49 | sean-k-mooney | sdague: oh ok. i guess you can use depends-on to track patches to both but i just assumend it would be eaisier to keep them in sync if the clients and apis were in the same repo | |
| 14:46:55 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance-exists notification https://review.openstack.org/403660 | |
| 14:47:07 | sdague | sean-k-mooney: the whole point of osc is to optimize for consumption | |