Earlier  
Posted Nick Remark
#openstack-sdks - 2019-10-31
13:44:34 mriedem https://review.opendev.org/#/c/691980/ unblock osc in the gate so would be nice to prioritize that
14:18:34 efried mordred, dtroyer: ^ is green in zuul now, please merge soonest :*
15:51:38 efried amotoki: ^
16:00:02 elmiko API SIG office hour has begun!
16:09:57 efried o/
16:10:12 efried (I got nothing, just happened to be in the room)
16:10:22 elmiko hey efried =)
16:10:57 elmiko it's mostly quiet these days, but we are here if folks need us
16:18:52 dtroyer mriedem, efried, etc: +W on https://review.opendev.org/#/c/691980/, thank you for chasing that down.
16:19:01 efried thanks dtroyer
16:48:29 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Use SDK to get compute API extensions https://review.opendev.org/691039
16:48:39 efried dtroyer: if you're still about, would you also please send this one, which is holding up the python-novaclient release? https://review.opendev.org/#/c/691039/
16:48:53 efried mriedem: fyi rebased that on the gate fix to smooth its path
16:50:52 mriedem thanks
16:51:09 mriedem i'm gonna go smooth some food into my gullet
16:53:30 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Remove redundant OpenStackShell.prepare_to_run_command https://review.opendev.org/691865
17:00:54 elmiko later all o/
17:47:40 openstackgerrit Merged openstack/python-openstackclient master: Fix functional tests for py3 https://review.opendev.org/691980
18:01:37 mgariepy can i have a quick push for this patch please ? https://review.opendev.org/#/c/691375/
18:56:27 efried mgariepy: FYI I'm working on making all of those pages autogenerated from the command classes
18:57:52 efried mgariepy: https://review.opendev.org/#/c/691767/ -- for this specific case, here's how it renders, which I think is the same as what you've done https://21fbb9beee6499333383-b4831d08abece0047714b6befcdb357a.ssl.cf5.rackcdn.com/691767/1/check/openstack-tox-docs/8df38ae/docs/cli/command-objects/network-agent.html#network-agent-remove-router
21:49:57 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: neutron: autogenerate docs https://review.opendev.org/691767
23:41:59 openstackgerrit Eric Fried proposed openstack/cliff master: WIP: Add autoprogram_cliff_app_dist_name config opt https://review.opendev.org/692464
23:42:52 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Let autoprogram-cliff know who's running https://review.opendev.org/692465
#openstack-sdks - 2019-11-01
07:07:43 openstackgerrit gugug proposed openstack/openstacksdk master: tox: Keeping going with docs https://review.opendev.org/692503
07:08:47 openstackgerrit gugug proposed openstack/openstacksdk master: tox: Keeping going with docs https://review.opendev.org/692503
10:26:24 openstackgerrit Pierre Prinetti proposed openstack/python-openstackclient master: versions: Fix 'versions show' help message https://review.opendev.org/686408
14:28:18 umbSublime Is there any way to query the placement API with the SDK ? I can't seem to figure it out
14:28:38 frickler umbSublime: iirc there's a plugin for that
14:28:47 umbSublime osc-placement ?
14:29:07 frickler umbSublime: exactly
14:29:21 umbSublime Ok, that works ! thanks
14:32:28 umbSublime frickler: I don't think I've ever user anything but the sdk or requests to query the API, is there a way I can just register a proxy on my connection object from this ?
14:35:20 frickler umbSublime: oh, you said sdk and not osc, not sure about that. maybe cdent or others can help, but likely many are on their way to the summit currently
14:35:46 umbSublime hehe no worries I have workarounds currently but it feels hacky :)
14:41:53 efried umbSublime: In the sdk you can create a raw placement proxy (connection.placement) and use the REST primitives (.get(), .put(), etc.)
14:42:10 efried Extensive examples in nova's report client...
14:42:41 efried https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/client/report.py#L170
14:43:31 efried https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/client/report.py#L229 is where we create the proxy. That calls into...
14:43:31 efried https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L1012
14:44:02 efried which in nova's case uses oslo.config opts to create the connection; but you should use your regular clouds.yaml thing.
14:44:38 umbSublime efried: awesome thanks !
14:45:01 efried for your purposes
14:45:02 efried conn = openstack.connection.Connection(...)
14:45:02 efried placement_proxy = conn.placement
14:45:02 efried placement_proxy.get(...) etc.
14:48:01 frickler efried: hmm, I'm assuming that that code is in nova for historical reasons, wouldn't it make sense to move it into a library? not sure whether osc-placement would be the right target or something like python-placementclient
14:48:40 efried frickler: not sure how much history you're signing up for. Grab a cup of coffee and scoot closer to the fire...
14:49:21 umbSublime efried: I've tried what you suggest but I get this message "Skipping over invalid version data. No stability status in version."
14:49:41 efried umbSublime: what release are you on?
14:50:15 umbSublime for this specific cloud 'queens'
14:50:43 efried frickler: The SchedulerReportClient previously talked to placement through a generic ksa Adapter. We cut over to the SDK in Train, after putting a bit of framework in the SDK to accept oslo.config opts. Having done that, the change was a one-liner (plus test): https://review.opendev.org/#/c/656023/
14:51:15 efried umbSublime: in queens placement was still part of nova, and sdk wasn't ready to create a generic placement proxy.
14:51:50 umbSublime Ahh I see, no worries then, I'll move along with my work around and make a bit more generic
14:51:55 efried umbSublime: you *might* be able to get away with it if you upgrade your openstacksdk to train-level code. But it's also possible you'll encounter some incompatible changes.
14:52:07 umbSublime my sdk is at 0.36
14:52:07 cdent presumably the new sdk release will still work with old
14:52:17 efried yeah, I'm not so sure about that ^
14:53:07 umbSublime in fact I was wondering which version to use. i couldn't find any documentatyion saying "Queens should use sdk version XX"
14:53:21 cdent frickler: one of the issues is that the previous PTL of placement (me) thinks people should just write get and put requests to placement as that's the way it was designed to be used, but the newer PTL (tetsuro) feels a bit differently, so there may be changes afoot. efried: meh. meh to that I say
14:54:03 cdent I would assume that mordred would be very sad if modern sdk can't talk to old clouds
14:54:32 umbSublime currently with .36 I can use it on ocata deployment as well
14:54:37 efried frickler: yes, what cdent said, I was getting to that. We will "never" have a python-placementclient. But we may someday add more SDK-ish methods in the SDK.
14:57:04 efried umbSublime: hm, I don't see anything from 0.36.0 to 0.37.0 that should be making a difference for you. It is possible that the hitch is placement being integrated in nova. A generic ksa adapter ought to be able to talk to $service with REST primitives; but depending which incarnation of the service-types-authority you're using...
14:57:33 frickler efried: cdent: o.k., that explains things, thx
15:03:15 umbSublime efried: I'm still new to all this, I'm not sure i get what you mean
15:04:34 umbSublime Like i can generate a ksa adapter and register my endpoint to it and just use REST methods on it ?
15:04:34 efried sorry, I didn't mean to leave that hanging umbSublime
15:04:47 efried yes, you should be able to do that.
15:05:28 umbSublime And would i be able to register that to my connection object ?
15:05:32 efried If you're paying attention to requirements files, the fact that you have sdk 0.36.0 probably means you have os-service-types at a train-ish level, and that ost thinks that placement is no longer part of nova.
15:06:09 umbSublime Ok that makes sense, and would explain why conn.placement doesn't work corrctly
15:06:42 umbSublime err it works correctly just not for my deployment
15:07:22 efried umbSublime: I want to help you debug this, trying to think how best to do it.
15:07:46 efried Do you have the ability to set up an oslo.config style .conf file with ksa opts to talk to your placement service?
15:08:32 umbSublime is that the older 'export OS_VAR_NAME=bleh' conf format ?
15:09:25 umbSublime really though I'm able to talk to the placement API without issues as it is using requests module
15:11:31 efried cool, ksa is a wrapper around requests that handles the auth and service catalog pieces. And sdk is a wrapper around ksa that lets you use a yaml file for config.
15:12:04 efried (sdk does much more than that obviously for other services, but not yet for placement)
15:12:38 umbSublime Ohhh I see now, so I could just use ksa and at least get the same interface as conn.compute.<HTTP METHOD> instead of re-implementing it !
15:13:41 efried instead of re-implementing the auth and service catalog pieces, yes
15:13:59 efried umbSublime: Here's an example of oslo.config style setup to talk to placement: https://zuul.opendev.org/t/openstack/build/8d219a6777234f349caf02883b9e0a4d/log/logs/etc/nova/nova.conf.txt.gz#104-112
15:14:14 efried (from a random CI run on a random recent nova patch)
15:17:02 efried umbSublime: So if you wanted to go that route, you could
15:17:02 efried - steal nova's get_ksa_adapter https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L969
15:17:02 efried - register those conf opts like this https://opendev.org/openstack/nova/src/branch/master/nova/conf/placement.py#L19-L30
15:17:02 efried - set up a .conf file like that one
15:17:02 efried and then you should be able to do:
15:17:02 efried adap = get_ksa_adapter('placement')
15:17:02 efried adap.get(...) etc.
15:19:29 efried I would be interested to know more about how the sdk is failing though. I'm not sure "Skipping over invalid version data. No stability status in version." should actually be preventing sdk from creating a proxy for you...
15:20:31 efried However, that ^ probably means that queens placement wasn't producing a good version document. cdent can you corroborate?
15:20:52 umbSublime I can paste the full stacktrace. It's something about parsing the endpoint
15:21:13 cdent efried, umbSublime : it's likely it was not, at that time
15:21:36 cdent because there was never any plan to have other versions, so for a while it was not a list, if I remember right
15:21:38 umbSublime https://hastebin.com/qezivuxivu.sql
15:21:49 cdent yeah, that
15:22:21 umbSublime Is there a version of the SDK where this would work though ? (prior to train release maybe?)
15:22:33 cdent umbSublime: can we wind this back a bit more: what's your end goal?
15:22:52 umbSublime We have some issues with allocations that don't exist

Earlier   Later