Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-09-25
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
14:03:31 efried because I'm getting a 401
15:33:24 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Add collections metadata info https://review.opendev.org/684787
15:33:25 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Import modules from ansible/ansible https://review.opendev.org/684788
15:33:34 mordred mnaser, dtantsur|afk: ^^
15:34:06 mordred efried: ah. hrm. maybe there is an issue there we need to fix :(
15:34:33 efried mordred: let me resurrect the repro steps from yesterday...
15:34:39 mordred mnaser, dtantsur|afk: we obviously need to add some zuul jobs and stuff
15:36:27 cdent "add some zuul jobs and stuff" is my mantra
15:39:22 Shrews mordred: what is the proposal for keeping the modules in sync (for the time being) between a-c-o and ansible/ansible?
15:41:42 mordred Shrews: mnaser and I were discussing just not doing that. saying that the a/a modules are good for 2.9 - and starting with 2.10 we just recommend people install the collection
15:42:11 mordred Shrews: and basically stopping accepting PRs in devel branch or something
15:42:14 mnaser i think it's also neat if we added some sort of warning to repoint people too
15:42:23 mnaser ^ yeah and we should kill all issues/prs/etc
15:43:00 Shrews are collections compatible with older versions of ansible?
15:43:07 mnaser nope :<
15:43:26 Shrews then i don't see how you can just tell people to install the collections
15:43:44 mnaser well i guess moving forwards the os_server will be frozen
15:43:53 mnaser but yeah i guessif someone jumps from 2.5 to 2.10
15:43:58 mnaser it would magically disappear
15:44:04 Shrews and not accept bug fixes? i don't see that going over well
15:44:08 mordred Shrews: I think it's that older versions of ansible already have the built in modules in them
15:44:32 mordred so we don't really need to do anything with those - it's only for ansible 2.10 and greater, which support collections, that anything would happen to the modules in a/a
15:45:41 mordred Shrews: I think accepting stable branch bugfixes is totally a legit thing to do
15:45:58 efried mordred: okay, here we go:
15:45:58 efried - Vanilla devstack running nova
15:45:58 efried - Clone cyborg, pull down 682565 (to get proper opt registration) and pip install -e it
15:45:58 efried - This /etc/cyborg/cyborg.conf: http://paste.openstack.org/show/779250/
15:45:58 efried - Run this script: http://paste.openstack.org/show/779251/
15:45:59 efried - Observe this output: http://paste.openstack.org/raw/779252/
15:46:51 mordred efried: uh...
15:46:55 Shrews mordred: so i return to my original question... how are we going to keep those fixes in sync in both places?
15:47:17 efried mordred: just skip to the last paste :)
15:47:57 Shrews i'm guessing this is a problem all external collections are going to have. just wondering if there was talk about that process
15:48:03 mordred Shrews: magic?
15:48:28 mordred Shrews: I think we should be able to make a zuul job that runs on changes to those that proposes patches to gerrit
15:49:12 mordred efried: yeah. like - that is not output we want to see - but it makes me wonder how anything would be working
15:49:12 efried mordred: the last ten lines or so of that output show the 401 for auth required for the versioned endpoint, which shouldn't be happening because a) endpoint shouldn't require auth, but even if it does, b) we're using a proper auth to set up the Connection (which can be proven by using strict_proxies=False and using the resulting proxy to do real things).
15:49:44 efried mordred: The most obvious guess is that version discovery is not using the auth I pass in.
15:49:51 efried it's using... some other auth, or no auth.
15:49:59 efried that would cause this behavior.
15:50:16 efried edit: this particular version discovery path
15:51:28 mordred yeah. something seems very strange there. I need to dig in to that - but it's lunchtime
15:51:41 efried ack
15:52:02 mordred that is definitely not behavior I expect :(

Earlier   Later