| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-11-01 | |||
| 15:27:41 | cdent | https://docs.openstack.org/placement/latest/contributor/quick-dev.html as well as https://github.com/cdent/placedock | |
| 15:27:50 | umbSublime | One day I'll try and get more involved into dev in openstack currently I'm just an operator trying to make my life easier :) | |
| 15:28:19 | cdent | that would be great, openstack badly needs more people with field experience working on it to make it easier to manage | |
| 15:29:56 | umbSublime | to be honest I was wondering is there is some type of portal where openstack operators (which don't necesseraly have all the dev experience) could share and discuss some future features/bugs etc. | |
| 15:31:56 | cdent | the openstack-discuss mailing list is supposed to be, in part, for that | |
| 15:34:39 | umbSublime | What is the actual goal the SDK is trying to fill (not historically, but nowadays) ? Is it meant to be a one stop shop for os services needing to talk to another ? Or is it more dev/ops oriented to standardize talking to all the different APIs | |
| 15:35:46 | mriedem | umbSublime: #openstack-operators channel | |
| 15:35:52 | mriedem | though it's generally quiet | |
| 15:35:58 | efried | umbSublime: That's really a mordred (sitting shirtless on a mountain with supplicants bringing him burnt offerings) question. | |
| 15:36:11 | efried | but I'll give it a shot... | |
| 15:36:25 | mriedem | umbSublime: if you send to the ML, tag ops stuff with [ops] to filter properly in people's mailbox | |
| 15:37:01 | efried | Yes, one stop shop. Originally I think for cloud operators writing tooling that talks to their cloud. Yes standardize how we talk to the different APIs. | |
| 15:37:25 | efried | Only more recently have we started to want to use it as a way for one service to talk to another. | |
| 15:37:34 | umbSublime | hence the merge of shade into the sdk in the bigining | |
| 15:38:12 | efried | We made some inroads on that in nova in train: we're most of the way through replacing nova's use of python-ironicclient with sdk; and we already swapped out placement (which had been using ksa directly) as you saw. | |
| 15:54:30 | umbSublime | efried: One last question concerning using get_ksa_adapter. Here https://opendev.org/openstack/nova/src/branch/master/nova/conf/placement.py#L28 what is conf ? I know it's what you showed with the .ini style config. But what type of object do I use to generate it ? | |
| 15:59:24 | efried | umbSublime: it's something like: | |
| 15:59:25 | efried | from oslo_config import cfg | |
| 15:59:25 | efried | register_ksa_options(..) # This should register the opts onto cfg.CONF | |
| 15:59:25 | efried | cfg.CONF(args=['--conf-file', '/path/to/your.conf']) # This loads up your config file into cfg.CONF | |
| 15:59:25 | efried | get_ksa_adapter... | |
| 15:59:36 | efried | gotta run to a meeting, that ^ is a bit rough but hopefully gets you pointed in the right direction. | |
| 16:00:19 | umbSublime | efried: thanks that's exactly what I need :) | |
| 16:16:40 | openstackgerrit | Pedro Henrique Pereira Martins proposed openstack/keystoneauth master: Fixes OIDC authentication with multiple IdPs https://review.opendev.org/692140 | |
| 17:25:57 | openstackgerrit | Merged openstack/python-openstackclient master: versions: Fix 'versions show' help message https://review.opendev.org/686408 | |
| 17:29:13 | umbSublime | I must be missing something https://hastebin.com/utuhuyinur.python I don't see what could be a duplicate. I'm trying to dig in the code, but i'm a bit lost | |
| 17:35:27 | efried | umbSublime: You're just running this code in isolation? | |
| 17:38:09 | openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | |
| 17:38:15 | efried | umbSublime: It looks right to me, but I was able to repro locally. Investigating... | |
| 17:40:37 | umbSublime | efried: yes, only the code in hastebin in a venv | |
| 17:43:26 | efried | umbSublime: oh, I see what's happening. I didn't notice you were importing from nova. That import is already registering the conf opts via nova.conf.__init__. | |
| 17:43:58 | efried | If you want to be able to use this cleanly, I suggest just copying in the guts of register_ksa_options | |
| 17:44:08 | efried | ...so you don't need to rely on nova existing at all. | |
| 17:44:17 | umbSublime | Ohh I see what you mean. | |
| 17:45:08 | efried | umbSublime: Um, except you can simplify a lot further | |
| 17:45:21 | efried | you don't need to remove and re-add the _ADAPTER_VERSION_OPTS for your purposes. | |
| 17:45:38 | efried | though I guess you can, shrug. | |
| 17:46:05 | umbSublime | same for get_ksa_adapter (I just use the guts of the function) ? | |
| 17:48:40 | openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | |
| 17:50:14 | openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | |
| 18:04:15 | umbSublime | got it working. Thanks again efried ! | |
| 18:04:24 | efried | \o/ | |
| 18:13:47 | umbSublime | Here is what I end up with https://hastebin.com/huhajekiso.py | |
| 18:15:48 | efried | umbSublime: Some of that stuff is nova-specific and/or legacy gorp you're dragging along. If this is for more than just playing around, I would suggest simplifying. | |
| 18:16:59 | umbSublime | efried: yup. I'm doing that right now :) but being unfamiliar with the codebase i'm taking my time :) | |
| 18:17:01 | efried | but yeah, this looks good. | |
| 18:17:12 | efried | umbSublime: okay, let me know if you need help | |
| 18:17:31 | efried | for example, if this is always going to be a placement-specific tool, you can remove all the stuff about service types and just hardcode 'placement'. | |
| 18:17:51 | efried | and as I said before, you probably don't care to scrub those version opts for your purposes. | |
| 18:17:57 | umbSublime | Well I'm baking this into my more general purpuse lib module, so I'll try and keep it generic | |
| 18:18:05 | umbSublime | just in case I need it for another service at some point | |
| 18:18:14 | efried | mmkay | |
| 18:18:30 | umbSublime | efried: I tried without and I get the same stack-trace as when using the nova register_ksa_opts | |
| 18:18:52 | efried | you would need to remove that hackup from both places | |
| 18:19:43 | efried | so 1) get_ksa_adapter_opts can go away and just use ks_loading.get_adapter_opts directly; and 2) kill L36-8 | |
| 18:20:17 | umbSublime | Ohhh I see, remove lines for "Removing version opts" and the ones that "add dummy opts for version" | |
| 18:20:47 | efried | actually, it gets simpler. | |
| 18:21:32 | efried | I only did this conf.register(get_opts) thing because I had to hack out those version things. | |
| 18:22:07 | efried | There ought to be a ks_loading method like ks_loading.register_adapter_conf_options which you can call directly. | |
| 18:22:54 | umbSublime | Ok, I'll look into that | |
| 18:30:48 | efried | umbSublime: like this http://paste.openstack.org/show/785725/ | |
| 18:37:58 | umbSublime | For some reason i'm getting "keystoneauth1.exceptions.catalog.EndpointNotFound: Could not find requested endpoint in Service Catalog." with that code (adapted to my env of course) | |
| 18:39:14 | efried | add to your conf: | |
| 18:39:15 | efried | service_type = placement | |
| 18:39:39 | efried | I simplified out the bit that detects that :P | |
| 18:39:48 | efried | here's super pared down: http://paste.openstack.org/show/785726/ | |
| 18:40:38 | efried | btw, raise_exc=False means that for 4xx/5xx responses, instead of raising an exception, you still just get a Response back, which you can inspect yourself. | |
| 18:40:45 | umbSublime | this fixed it for me http://paste.openstack.org/show/785727/ | |
| 18:41:06 | umbSublime | ohh very neat trick ! | |
| 18:41:45 | efried | and Response has a magic __bool__ so you can actually say things like: | |
| 18:41:45 | efried | if resp: | |
| 18:41:45 | efried | # status code was 2xx/3xx, do success path | |
| 18:41:45 | efried | else: | |
| 18:41:45 | efried | # status code was 4xx/5xx, do failure stuff | |
| 18:42:19 | efried | umbSublime: yes, what fixed you there was the cfg.set_defaults(service_type='placement') which is the same thing as you setting it in the conf (but in code) | |
| 18:42:49 | efried | so, either way | |
| 18:43:05 | umbSublime | \o/ | |
| 18:50:33 | umbSublime | Say I want to wrap all this in a function that takes a region_name and return the adapter for the specified region. I'd need to do something similar to "example 3" and then do CONF(['--my-opt', "my_val"]) https://www.programcreek.com/python/example/106145/oslo_config.cfg.CONF | |
| 19:02:17 | umbSublime | Ahh even easier I can just override the region_name attribute from the adapter | |
| 19:15:09 | efried | depending where in the flow you want to do it, you could do CONF.set_override(region_name='foo', group='placement') | |
| 19:15:16 | efried | (I may not have that syntax exactly right) | |
| 19:22:44 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: neutron: autogenerate docs https://review.opendev.org/691767 | |
| 19:22:45 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: common: autogenerate docs https://review.opendev.org/691989 | |
| 19:22:45 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: Update a stale doc reference to use :neutron-doc: https://review.opendev.org/692605 | |
| 19:25:56 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: neutron: autogenerate docs https://review.opendev.org/691767 | |
| 19:25:57 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: Update a stale doc reference to use :neutron-doc: https://review.opendev.org/692605 | |
| 19:25:57 | openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: common: autogenerate docs https://review.opendev.org/691989 | |
| #openstack-sdks - 2019-11-04 | |||
| 07:33:19 | jawad_axd | Hi all, Is there any function to get instance console url from openstacksdk? I can not find any.. | |
| 09:24:34 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Add router add/remove route operations https://review.opendev.org/674324 | |
| 09:24:51 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 13:33:04 | mriedem | can i get another osc core on https://review.opendev.org/#/c/691039/ to help unblock novaclient 16.0.0? https://review.opendev.org/#/c/690097/ | |
| 13:33:08 | mriedem | please and thanks | |
| 15:14:56 | gtema | mriedem: you are not alone with that, I would also like to get any review on https://review.opendev.org/#/c/650374/ for switching from glanceclient to SDK. | |
| 15:20:35 | mriedem | heh, that glance one is much much bigger change | |
| 15:20:55 | mriedem | mine is "change this one nova call to use the sdk", not "change all compute api calls to use the sdk" | |
| 20:46:57 | openstackgerrit | Merged openstack/osc-lib master: Update master for stable/train https://review.opendev.org/683493 | |
| 21:39:46 | umbSublime | Is it accurate to say openstack-sdk is just added functionnality around osc-lib ? | |
| 21:41:28 | umbSublime | err other way around | |
| 21:42:42 | dtroyer | umbSublime: neither really, osc-lib is the basis for the CLI commands in OpenStackClient, but it does not depend on the SDK specifically, it provides the common bits for OSC plugins | |
| 21:43:57 | umbSublime | so then osc-lib is another layer ontop of cliff to facilitate plugin creation ? | |