| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-09-24 | |||
| 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 | ++ | |
| 12:32:48 | dtantsur | to use matchers, do we need to inherit the jobs? or can I do it in project.jobs.<>? | |
| 12:33:02 | mordred | dtantsur, Shrews, gtema_: the new hotness in ansible land is collections, and the intent is to split out modules from ansible core into externally managed collections. these can be hosted anywhere. so - I think we should host the openstack collection in opendev as a deliverable of the sdk project (since the overlap is very high) | |
| 12:33:16 | dtantsur | I very much agree with that | |
| 12:33:18 | mordred | dtantsur: you can do it in project.jobs.<> | |
| 12:33:23 | dtantsur | nice | |
| 12:34:02 | mordred | I'll get some patches up today for project creation and initial content import and whatnot | |
| 12:34:29 | dtantsur | great! then we can add a bifrost job to verify ironic bits | |
| 12:55:19 | mordred | dtantsur: it's going to be some amount of fun for bifrost - because the module names are going to change | |
| 12:56:03 | dtantsur | mordred: can we also re-engineer ironic modules then? | |
| 12:56:09 | dtantsur | they're awkward to say the least | |
| 12:56:09 | mordred | totally | |
| 12:56:27 | dtantsur | and we should be doing os_baremetal_node, not os_ironic, etc, etc | |
| 12:56:38 | mordred | I'm going to start by importing the existing modules as they are - but I figure since the modules names are changing anyway, it's a good time to rework stuff we're annoyed by | |
| 12:56:51 | dtantsur | \o/ | |
| 12:57:03 | mordred | new names will be like 'openstack.cloud.ironic_node' instead of os_ironic_node - fwiw | |
| 12:57:38 | dtantsur | openstack.cloud.baremetal_node ;) | |
| 12:58:07 | mordred | ++ | |
| 12:59:30 | gtema | oh cool. I like the idea. Let's do this | |
| 14:02:51 | efried | mordred: Given that nova's versioned endpoint is requiring auth (I can fix that, but it's going to take time before we can rely on it), I'm seeing odd behavior in _validate_proxy. | |
| 14:03:26 | efried | in that it *seems* as though it's not using the Connection's auth when querying that URI | |