Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-09-23
13:29:46 dtroyer enriquetaso: I'm not sure exactly what you are asking, OSC _does_ use the current python-cinderclient, however any changes should consider switching to the SDK and using that to support microversions properly. Now if we just had a stable 1.0 release… /me ducks
13:32:03 dtantsur heh
13:33:44 enriquetaso dtroyer, oh
13:52:53 enriquetaso thanks dtroyer
15:38:01 openstackgerrit Merged openstack/cliff master: Stop wildcard importing argparse https://review.opendev.org/611889
16:53:03 openstackgerrit Merged openstack/openstacksdk master: Make the bifrost job non-voting https://review.opendev.org/683946
#openstack-sdks - 2019-09-24
09:16:36 openstackgerrit Vishakha Agarwal proposed openstack/keystoneauth master: Generate pdf documentation https://review.opendev.org/682272
11:38:46 mordred enriquetaso: I think dtroyer got you - but I agree with dtantsur and dtroyer - and I think the best outcome would be switching to sdk
11:42:09 enriquetaso mordred, thanks for answering me. This is my first time working with openstacksdk. Is openstack cli going to deprecate?
11:53:26 mordred oh no - openstack cli is the future. sdk is what we want to use for REST interactions with services instead of the per-service python-*client libraries
11:54:36 mordred but the idea is that we put shared needed logic for things into sdk - then it's available to python users, as well as other sdk consumers like ansible and salt, and we can build the osc commands from that same logic
11:55:13 mordred *AND* - nova is starting to use sdk to talk to services - so the same logic can be reused for service-to-service interactions... but we don't have to maintain 30 different libraries
11:56:21 enriquetaso mordred++
11:56:25 enriquetaso thanks!
14:18:42 mriedem dtroyer: got a question about an osc-placement patch proposed to stable/train b/c of an osc 4.0.0 change to remove support for --os-url and replace it with --os-endpoint https://review.opendev.org/#/c/684292/1
14:18:55 mriedem cdent says that if you have python-openstackclient < 4.0 that won't work
14:19:17 mriedem but #14 on https://docs.openstack.org/python-openstackclient/latest/cli/backwards-incompatible.html makes it sound like that was a long-standing thing that we should have just not been using
14:19:49 cdent I made it not work by only changing python-openstackclient, not osc-lib at the same time, so that may have been a factor
14:20:02 mriedem so we're trying to figure out if we need to bump the minimum required version of osc to >= 4.0.0 in osc-placement's test-requirements
14:21:01 dtroyer I'd have to refresh my memory, but —os-endpoint did not change, only the removal of —os-url. The plugin I took out basically just aliased the option names
14:21:25 mriedem cdent: ok so maybe you have to downgrade osc-lib to stein level and see if it works
14:21:40 cdent one mo
14:21:47 mriedem osc-lib 1.12.1 i guess?
14:21:47 dtroyer I do not recall making the sorts of changes to osc-lib that would affect this going backward, only to support taking things out of osc4 itself
14:22:19 dtroyer but then my head went back to stx-land so who knows what I recall now… ;)
14:22:34 mriedem so --os-endpoint should work with osc 3.19.0
14:23:56 cdent if I downgrade just python-openstackclient it fails
14:24:32 cdent if I downgrade also osc-lib it still fails
14:24:55 cdent osc-lib 1.12.1 and p-osc 3.19.0
14:25:31 dtroyer I want to say osc-lib should not be a factor here
14:26:08 cdent dtroyer: as you may recall, this is from the weird stuff that osc-placement is doing for its functional tests where it is sending an explicit token ("admin") to a defined url/endpoint
14:26:44 cdent the change that "fixes it" just replaces the use of --os-url with --os-endpoint in a call to shell.run()
14:31:11 dtroyer some of the logic for deducing the proper auth-type has been removed from osc to make it compatible with sdk/ksa, that included changing os-url to os-endpoint to specifically set —os-auth-type to 'admin_token'
14:31:24 dtroyer https://review.opendev.org/#/c/677795/4/openstackclient/shell.py
14:32:10 dtroyer I can't imagine that ksa has changed in this area at all recently, that should not be a factor
14:34:21 dtroyer cdent: look at the comment in https://review.opendev.org/#/c/678059/1/openstackclient/tests/functional/base.py and see if that applies to what you are doing
14:35:01 dtroyer it is about setting —os-auth-type in some cases and letting it default in others
14:40:19 cdent dtroyer: what the osc-p functional tests are doing is shell.OpenStackShell().run(list_of_args) without setting --os-cloud or --os-auth-type. Solely: --os-endpoint, --os-token, --os-placement-api-version (if asked), -f json, and then whatever the command being tested happens to be
14:41:29 cdent things work correctly like that in 4.0.0
14:41:39 cdent and when it was --os-url they worked correctly in < 4.0.0
14:42:06 cdent If I'm hearing you properly, what might be going on is that the os-endpoint support in < 4.0.0 needed an explicit --os-auth-type when --os-url did not?
14:43:22 dtroyer yes, the check in osc was only on —os-url to set os-auth-type to 'token_endpoint'. We never did a default for —os-endpoint before 4.0
14:44:16 mriedem ah, so cdent - if you specify --os-auth-type in the functional test maybe we don't need to bump the required version of osc
14:47:52 cdent how should I orchestrate that patch wise?
14:47:55 cdent just do it on train?
14:48:01 cdent do it on both and backport
14:48:05 cdent something else?
14:48:06 mriedem do it on both and backport
14:48:14 mriedem if we want to require osc>=4.0 we should do that on master only
14:48:19 mriedem but i'm not sure it's necessary anymore
14:48:26 cdent roger con aye, 10 degree down bubble
14:48:43 dtroyer osc4 will be the stable/train branch f that matters…
14:51:47 cdent dtroyer: what is the proper auth-type to specify?
14:54:32 cdent I guess 'admin_token'?
14:56:48 efried mordred: is a versioned root endpoint supposed to require auth?
14:56:59 efried e.g. http://192.168.218.28/compute/v2.1
14:57:12 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Microversion 2.78 - server show topology https://review.opendev.org/680928
14:58:57 dtroyer cdent, mriedem: yes, admin_token is correct
14:59:10 cdent thanks dtroyer
18:21:39 openstackgerrit guang-yee proposed openstack/keystoneauth master: Generate pdf documentation https://review.opendev.org/682272
20:25:04 openstackgerrit guang-yee proposed openstack/keystoneauth master: Generate pdf documentation https://review.opendev.org/682272
22:23:07 openstackgerrit Eric Fried proposed openstack/openstacksdk master: Make proxy honor raise_exc in REST primitives https://review.opendev.org/684433
22:25:08 openstackgerrit Eric Fried proposed openstack/openstacksdk master: Make proxy honor raise_exc in REST primitives https://review.opendev.org/684433
#openstack-sdks - 2019-09-25
00:52:22 openstackgerrit guang-yee proposed openstack/keystoneauth master: Generate pdf documentation https://review.opendev.org/682272
05:56:23 openstackgerrit Shogo Saito proposed openstack/openstacksdk master: Adding basic implementation for Accelerator(Cyborg) https://review.opendev.org/679914
09:02:39 openstackgerrit Vishakha Agarwal proposed openstack/keystoneauth master: Generate pdf documentation https://review.opendev.org/682272
11:21:51 mordred efried: no - i version discovery endpoints should never require auth
11:22:23 mordred gtema: nice photo :)
11:31:27 frickler mordred: iiuc efried was talking about the versioned endpoint. the discovery endpoint would seem to be just http://192.168.218.28/compute/ in his example
11:39:46 mordred frickler: yeah- but that versioned endpoint is still a version discovery endpoint (it's where the versioned discovery doc would be located) - and should never require auth
11:39:52 mordred efried: ^^
11:48:05 frickler mordred: efried: hmm, then at least cinder, glance and nova are broken in that respect
11:49:43 frickler the only service where I see this working is identity
11:50:59 cdent placement does no auth for the version doc
11:51:57 cdent or if it doesn't, then something is broken
11:55:06 frickler cdent: placement seems special in that it runs directly under the main endpoint afaict, i.e. there is no /placement/v1.0/ path
11:55:22 cdent that's correct
11:56:04 cdent version numbers ins URLs are icky
11:58:31 mordred frickler: *awesome*
11:58:59 mordred frickler: well, I guess it probably doens't break sdk most of the time because we're usually set up with auth anyway
11:59:35 mordred but in a perfect world no version discovery docs should be auth protected - as they do not present any user-specific or special info
11:59:56 mordred they should also be naturally aggressively cacheable
12:01:32 cdent i was surprised to discover on the ML recently that some entries in the service catalog still have project ids?
12:01:41 cdent (in the urls)
12:11:09 mordred yeah. some people still haven't gotten rid of those
12:11:49 mordred keystoneauth version discovery knows how to strip them and add them back when it's looking for version discovery docs - so I stopped caring, even though it's ultimately a tragedy
12:21:27 dtantsur mordred: an interesting topic came up on #release. with more and more projects relying on openstacksdk for x-project interaction, how do we prevent breakages?
12:21:37 dtantsur we cannot reasonably run so many jobs, can we?
12:23:19 frickler I think we can and we should. possibly most of them non-voting
12:25:28 dtantsur okay, I'll add an ironic-inspector job then
12:28:07 mordred dtantsur: I think we might want to do some file matchers ...
12:28:31 mordred dtantsur: you probably don't need to run ironic-inspector jobs on patches to openstack/image/* - for instance :)
12:28:44 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add a non-voting ironic-inspector job https://review.opendev.org/684729
12:28:45 dtantsur mordred: that was my thought as well
12:28:51 dtantsur although I'm not sure how to express it
12:29:00 dtantsur I wonder to run it on e.g. openstack/resource.py
12:29:44 mordred yeah - I think openstack/{connection,resource,proxy}.py should likely run the world - but those should also be rare at this point
12:30:16 mordred fwiw - I'm not opposed to these becomming voting if we figure out the right file matchers
12:30:23 mordred but one step at a time
12:32:21 dtantsur ++

Earlier   Later