*** goldyfruit_ has joined #openstack-sdks | 00:20 | |
*** goldyfruit_ has quit IRC | 00:55 | |
*** jkulik has quit IRC | 00:58 | |
*** jkulik has joined #openstack-sdks | 00:59 | |
*** dave-mccowan has quit IRC | 01:04 | |
*** enriquetaso has joined #openstack-sdks | 01:46 | |
*** goldyfruit_ has joined #openstack-sdks | 02:17 | |
*** mtreinish has quit IRC | 03:28 | |
*** enriquetaso has quit IRC | 03:33 | |
*** dave-mccowan has joined #openstack-sdks | 03:37 | |
*** goldyfruit_ has quit IRC | 03:40 | |
*** dave-mccowan has quit IRC | 03:40 | |
*** factor has joined #openstack-sdks | 03:47 | |
openstackgerrit | gugug proposed openstack/openstacksdk master: tox: Keeping going with docs https://review.opendev.org/692503 | 07:07 |
---|---|---|
openstackgerrit | gugug proposed openstack/openstacksdk master: tox: Keeping going with docs https://review.opendev.org/692503 | 07:08 |
*** gtema has joined #openstack-sdks | 08:45 | |
*** jpich has joined #openstack-sdks | 08:52 | |
*** ralonsoh has joined #openstack-sdks | 09:07 | |
*** Dinesh_Bhor has quit IRC | 09:07 | |
*** cdent has joined #openstack-sdks | 09:16 | |
openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: versions: Fix 'versions show' help message https://review.opendev.org/686408 | 10:26 |
*** gtema has quit IRC | 10:29 | |
*** cdent has quit IRC | 11:28 | |
*** cdent has joined #openstack-sdks | 11:44 | |
*** gtema has joined #openstack-sdks | 12:11 | |
*** mriedem has joined #openstack-sdks | 13:08 | |
*** goldyfruit_ has joined #openstack-sdks | 13:15 | |
*** enriquetaso has joined #openstack-sdks | 13:43 | |
*** gtema has quit IRC | 13:43 | |
*** gtema has joined #openstack-sdks | 13:44 | |
*** gtema has quit IRC | 13:49 | |
*** gtema has joined #openstack-sdks | 13:50 | |
*** gtema has quit IRC | 13:55 | |
*** gtema has joined #openstack-sdks | 14:17 | |
umbSublime | Is there any way to query the placement API with the SDK ? I can't seem to figure it out | 14:28 |
frickler | umbSublime: iirc there's a plugin for that | 14:28 |
*** mtreinish has joined #openstack-sdks | 14:28 | |
umbSublime | osc-placement ? | 14:28 |
frickler | umbSublime: exactly | 14:29 |
umbSublime | Ok, that works ! thanks | 14:29 |
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:32 |
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 |
umbSublime | hehe no worries I have workarounds currently but it feels hacky :) | 14:35 |
efried | umbSublime: In the sdk you can create a raw placement proxy (connection.placement) and use the REST primitives (.get(), .put(), etc.) | 14:41 |
efried | Extensive examples in nova's report client... | 14:42 |
efried | https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/client/report.py#L170 | 14:42 |
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 |
efried | https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L1012 | 14:43 |
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 |
umbSublime | efried: awesome thanks ! | 14:44 |
efried | for your purposes | 14:45 |
efried | conn = openstack.connection.Connection(...) | 14:45 |
efried | placement_proxy = conn.placement | 14:45 |
efried | placement_proxy.get(...) etc. | 14:45 |
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 |
efried | frickler: not sure how much history you're signing up for. Grab a cup of coffee and scoot closer to the fire... | 14:48 |
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 |
efried | umbSublime: what release are you on? | 14:49 |
umbSublime | for this specific cloud 'queens' | 14:50 |
*** jangutter has quit IRC | 14:50 | |
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:50 |
efried | umbSublime: in queens placement was still part of nova, and sdk wasn't ready to create a generic placement proxy. | 14:51 |
umbSublime | Ahh I see, no worries then, I'll move along with my work around and make a bit more generic | 14:51 |
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:51 |
umbSublime | my sdk is at 0.36 | 14:52 |
cdent | presumably the new sdk release will still work with old | 14:52 |
efried | yeah, I'm not so sure about that ^ | 14:52 |
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 |
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:53 |
*** gtema has quit IRC | 14:53 | |
cdent | I would assume that mordred would be very sad if modern sdk can't talk to old clouds | 14:54 |
umbSublime | currently with .36 I can use it on ocata deployment as well | 14:54 |
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:54 |
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 |
frickler | efried: cdent: o.k., that explains things, thx | 14:57 |
umbSublime | efried: I'm still new to all this, I'm not sure i get what you mean | 15:03 |
umbSublime | Like i can generate a ksa adapter and register my endpoint to it and just use REST methods on it ? | 15:04 |
efried | sorry, I didn't mean to leave that hanging umbSublime | 15:04 |
efried | yes, you should be able to do that. | 15:04 |
umbSublime | And would i be able to register that to my connection object ? | 15:05 |
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:05 |
umbSublime | Ok that makes sense, and would explain why conn.placement doesn't work corrctly | 15:06 |
umbSublime | err it works correctly just not for my deployment | 15:06 |
efried | umbSublime: I want to help you debug this, trying to think how best to do it. | 15:07 |
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:07 |
umbSublime | is that the older 'export OS_VAR_NAME=bleh' conf format ? | 15:08 |
umbSublime | really though I'm able to talk to the placement API without issues as it is using requests module | 15:09 |
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:11 |
efried | (sdk does much more than that obviously for other services, but not yet for placement) | 15:12 |
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:12 |
efried | instead of re-implementing the auth and service catalog pieces, yes | 15:13 |
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:13 |
efried | (from a random CI run on a random recent nova patch) | 15:14 |
efried | umbSublime: So if you wanted to go that route, you could | 15:17 |
efried | - steal nova's get_ksa_adapter https://opendev.org/openstack/nova/src/branch/master/nova/utils.py#L969 | 15:17 |
efried | - register those conf opts like this https://opendev.org/openstack/nova/src/branch/master/nova/conf/placement.py#L19-L30 | 15:17 |
efried | - set up a .conf file like that one | 15:17 |
efried | and then you should be able to do: | 15:17 |
efried | adap = get_ksa_adapter('placement') | 15:17 |
efried | adap.get(...) etc. | 15:17 |
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:19 |
efried | However, that ^ probably means that queens placement wasn't producing a good version document. cdent can you corroborate? | 15:20 |
umbSublime | I can paste the full stacktrace. It's something about parsing the endpoint | 15:20 |
cdent | efried, umbSublime : it's likely it was not, at that time | 15:21 |
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 |
umbSublime | https://hastebin.com/qezivuxivu.sql | 15:21 |
cdent | yeah, that | 15:21 |
umbSublime | Is there a version of the SDK where this would work though ? (prior to train release maybe?) | 15:22 |
cdent | umbSublime: can we wind this back a bit more: what's your end goal? | 15:22 |
umbSublime | We have some issues with allocations that don't exist | 15:22 |
umbSublime | I'm just making a little tool to help show and clean them | 15:23 |
cdent | ah, okay, yeah, that's a common thing, enough that in newer versions nova has some tooling for it | 15:23 |
umbSublime | I have all my code working right now, and the tool works. I'm just trying to make it more "standard" I guess | 15:23 |
cdent | a good inclination but I'd say probably not worth it in this case | 15:24 |
cdent | no "standard" was set with regard to placement around queens time | 15:24 |
umbSublime | agreed, it was also a bit of an exercise to get more familiar with the SDK | 15:24 |
efried | unfortunate that you tried with this particular combination :( | 15:25 |
efried | We didn't have sdk talking to placement until mid-train, and iirc we had to make some tweaks to sdk to make that happen more smoothly. | 15:25 |
umbSublime | I appreciate all your help though. efried I think I'll give that technique you shared a try | 15:25 |
cdent | umbSublime: you can run placement standalone, if you want something to talk to using modern techniques, for educational purposes | 15:26 |
umbSublime | Ohh you mean on a devstack or something ? | 15:26 |
cdent | no, much more standalone, let me find you a ref | 15:27 |
cdent | https://docs.openstack.org/placement/latest/contributor/quick-dev.html as well as https://github.com/cdent/placedock | 15:27 |
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:27 |
cdent | that would be great, openstack badly needs more people with field experience working on it to make it easier to manage | 15:28 |
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:29 |
cdent | the openstack-discuss mailing list is supposed to be, in part, for that | 15:31 |
* umbSublime subscribed | 15:33 | |
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:34 |
* cdent defers to frickler and efried on that question | 15:35 | |
mriedem | umbSublime: #openstack-operators channel | 15:35 |
mriedem | though it's generally quiet | 15:35 |
efried | umbSublime: That's really a mordred (sitting shirtless on a mountain with supplicants bringing him burnt offerings) question. | 15:35 |
efried | but I'll give it a shot... | 15:36 |
mriedem | umbSublime: if you send to the ML, tag ops stuff with [ops] to filter properly in people's mailbox | 15:36 |
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 |
efried | Only more recently have we started to want to use it as a way for one service to talk to another. | 15:37 |
umbSublime | hence the merge of shade into the sdk in the bigining | 15:37 |
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:38 |
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:54 |
efried | umbSublime: it's something like: | 15:59 |
efried | from oslo_config import cfg | 15:59 |
efried | register_ksa_options(..) # This should register the opts onto cfg.CONF | 15:59 |
efried | cfg.CONF(args=['--conf-file', '/path/to/your.conf']) # This loads up your config file into cfg.CONF | 15:59 |
efried | get_ksa_adapter... | 15:59 |
efried | gotta run to a meeting, that ^ is a bit rough but hopefully gets you pointed in the right direction. | 15:59 |
umbSublime | efried: thanks that's exactly what I need :) | 16:00 |
*** mriedem is now known as mriedem_feeds | 16:16 | |
openstackgerrit | Pedro Henrique Pereira Martins proposed openstack/keystoneauth master: Fixes OIDC authentication with multiple IdPs https://review.opendev.org/692140 | 16:16 |
*** goldyfruit___ has joined #openstack-sdks | 16:45 | |
*** goldyfruit_ has quit IRC | 16:47 | |
*** cdent has quit IRC | 16:53 | |
*** enriquetaso has quit IRC | 16:59 | |
*** jpich has quit IRC | 17:18 | |
openstackgerrit | Merged openstack/python-openstackclient master: versions: Fix 'versions show' help message https://review.opendev.org/686408 | 17:25 |
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:29 |
*** mriedem_feeds is now known as mriedem | 17:34 | |
efried | umbSublime: You're just running this code in isolation? | 17:35 |
openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | 17:38 |
efried | umbSublime: It looks right to me, but I was able to repro locally. Investigating... | 17:38 |
umbSublime | efried: yes, only the code in hastebin in a venv | 17:40 |
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 |
efried | If you want to be able to use this cleanly, I suggest just copying in the guts of register_ksa_options | 17:43 |
efried | ...so you don't need to rely on nova existing at all. | 17:44 |
umbSublime | Ohh I see what you mean. | 17:44 |
efried | umbSublime: Um, except you can simplify a lot further | 17:45 |
efried | you don't need to remove and re-add the _ADAPTER_VERSION_OPTS for your purposes. | 17:45 |
efried | though I guess you can, shrug. | 17:45 |
umbSublime | same for get_ksa_adapter (I just use the guts of the function) ? | 17:46 |
openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | 17:48 |
openstackgerrit | Pierre Prinetti proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs https://review.opendev.org/691989 | 17:50 |
umbSublime | got it working. Thanks again efried ! | 18:04 |
efried | \o/ | 18:04 |
*** ralonsoh has quit IRC | 18:06 | |
umbSublime | Here is what I end up with https://hastebin.com/huhajekiso.py | 18:13 |
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:15 |
umbSublime | efried: yup. I'm doing that right now :) but being unfamiliar with the codebase i'm taking my time :) | 18:16 |
efried | but yeah, this looks good. | 18:17 |
efried | umbSublime: okay, let me know if you need help | 18:17 |
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 |
efried | and as I said before, you probably don't care to scrub those version opts for your purposes. | 18:17 |
umbSublime | Well I'm baking this into my more general purpuse lib module, so I'll try and keep it generic | 18:17 |
umbSublime | just in case I need it for another service at some point | 18:18 |
efried | mmkay | 18:18 |
umbSublime | efried: I tried without and I get the same stack-trace as when using the nova register_ksa_opts | 18:18 |
efried | you would need to remove that hackup from both places | 18:18 |
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:19 |
umbSublime | Ohhh I see, remove lines for "Removing version opts" and the ones that "add dummy opts for version" | 18:20 |
efried | actually, it gets simpler. | 18:20 |
efried | I only did this conf.register(get_opts) thing because I had to hack out those version things. | 18:21 |
efried | There ought to be a ks_loading method like ks_loading.register_adapter_conf_options which you can call directly. | 18:22 |
umbSublime | Ok, I'll look into that | 18:22 |
efried | umbSublime: like this http://paste.openstack.org/show/785725/ | 18:30 |
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:37 |
efried | add to your conf: | 18:39 |
efried | service_type = placement | 18:39 |
efried | I simplified out the bit that detects that :P | 18:39 |
efried | here's super pared down: http://paste.openstack.org/show/785726/ | 18:39 |
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 |
umbSublime | this fixed it for me http://paste.openstack.org/show/785727/ | 18:40 |
umbSublime | ohh very neat trick ! | 18:41 |
efried | and Response has a magic __bool__ so you can actually say things like: | 18:41 |
efried | if resp: | 18:41 |
efried | # status code was 2xx/3xx, do success path | 18:41 |
efried | else: | 18:41 |
efried | # status code was 4xx/5xx, do failure stuff | 18:41 |
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 |
efried | so, either way | 18:42 |
umbSublime | \o/ | 18:43 |
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 | 18:50 |
umbSublime | Ahh even easier I can just override the region_name attribute from the adapter | 19:02 |
efried | depending where in the flow you want to do it, you could do CONF.set_override(region_name='foo', group='placement') | 19:15 |
efried | (I may not have that syntax exactly right) | 19:15 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: neutron: autogenerate docs https://review.opendev.org/691767 | 19:22 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: common: autogenerate docs https://review.opendev.org/691989 | 19:22 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: Update a stale doc reference to use :neutron-doc: https://review.opendev.org/692605 | 19:22 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: neutron: autogenerate docs https://review.opendev.org/691767 | 19:25 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: Update a stale doc reference to use :neutron-doc: https://review.opendev.org/692605 | 19:25 |
openstackgerrit | Eric Fried proposed openstack/python-openstackclient master: common: autogenerate docs https://review.opendev.org/691989 | 19:25 |
*** enriquetaso has joined #openstack-sdks | 20:30 | |
*** slaweq has joined #openstack-sdks | 20:46 | |
*** slaweq has quit IRC | 21:05 | |
*** goldyfruit_ has joined #openstack-sdks | 21:08 | |
*** goldyfruit___ has quit IRC | 21:10 | |
*** enriquetaso has quit IRC | 21:10 | |
*** goldyfruit___ has joined #openstack-sdks | 21:32 | |
*** goldyfruit_ has quit IRC | 21:34 | |
*** enriquetaso has joined #openstack-sdks | 21:34 | |
*** enriquetaso has quit IRC | 21:35 | |
*** mriedem has quit IRC | 21:39 | |
*** goldyfruit___ has quit IRC | 22:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!