Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-05-16
15:57:34 dhellmann so a single sphinx project publishing nicely organized content is more appealing
15:57:44 dhellmann edleafe, cdent, dtroyer : ^^
15:58:48 cdent ideally we'd see more places linking into the guidelines, and that makes even more sense if we're covering both creation and consumption
16:01:02 edleafe cdent: +1
16:04:52 elmiko mordred: edleafe, just saw the ping. reading back
16:06:46 elmiko mordred: so, i more or less agree with cdent, edleafe and dtroyer. seems more useful to have things in a place that is easier to find
16:07:22 elmiko i'm not sure what shape that would take, but i like the idea of being able to navigate between the different guideline types in a convenient fashion
16:10:21 mordred sweet
16:11:28 edleafe The only one that seems out of place a bit is the version discovery algorithm
16:11:45 edleafe but in the context of the others, it fits
16:12:00 mordred dhellmann: there is also at least one thing in the service-types-authority consumption spec that assumes we can publish the service-types-authority data to a location that will be solid/stable/well-known. It's currently written up as "https://specs.openstack.org/service-types.json" - which I think a job in s-t-a to publish post-merge should be easy enough to implement
16:13:00 dhellmann mordred: it feels a little odd to publish machine-readable data to the root of the specs site, but I think I get it
16:13:28 mordred dhellmann: yah - we could also spin up a new domain/web root for that I imagine too
16:13:55 cdent i think specs could very well be fine: it's sort of like a spec
16:14:10 dhellmann yeah, it's just a new precedent
16:14:11 cdent and helps give it some ooomph
16:14:31 mordred edleafe: maybe if we re-org that doc slightly more cleanly into "develop/deploy/consume" portions rather than "this is all the information you need about consuming versions - oh, also, deployers please take note of this bit" it'll be easier to read too?
16:19:27 edleafe mordred: or maybe "here's where we are", "here's why we are in the state we are", and "here's where we really want to be"
16:20:21 mordred edleafe: yes. "this is the description of the idea state" - "this is description of the complete current state including the ideal state" - "these are recommendations for people who would like to achieve future perfection"
16:20:41 mordred edleafe, cdent, elmiko: WHILE I'VE GOT YOUR ATTENTION ...
16:23:57 mordred most of the services I've found in openstack with microversions implementations use the nova form of version/min_version rather than the API-WG recommendation of max_version/min_version ... including nova, cinder, manila and ironic - although it seems magnum and zun have the min_version/max_version form
16:24:39 mordred I'm mostly curious about the decision to recommend min/max (since I wasn't paying attentoin then) and how much effort we think should go in to adding max_version to the services which just have version?
16:25:42 mordred (I started a patch to add a "collections" link as from the version discovery thing just to see how bad it was (not) which is what got me thinking about this specifically)
16:25:45 elmiko iirc, some of these projects were impementing microversion while we were still arriving at the guideline, that combined with the "nova effect" (copy what nova did) did not help
16:26:35 elmiko it would be cool to bring the project up to speed with the guideline, but i don't have a strong handle on how interested in taking on the tech debt they would be
16:26:58 elmiko we don't get strong participation on a good day, it's just tough to know how the individual projects would feel about it
16:27:15 sdague well nova, ironic, and manila were out the door before there ever was an api-wg recommendation
16:27:17 elmiko my gut feeling is that it will be like herding a small pack of cats
16:27:20 mordred I mean, from a consume perspective, any consumer is going to have to handle both choices no matter what for the forseeable future so it's not a super big deal there
16:27:26 elmiko sdague: exactly
16:27:28 mordred sdague: yah
16:28:00 edleafe does anyone use max_version?
16:28:04 mordred yes
16:28:12 elmiko imo, it would be nice, but we (api-wg) don't exactly have a habit of chasing folks down to implement the guidelines
16:28:18 mordred magnum and zun at least - I haven't taken full catalog yet
16:28:57 cdent I thnk the change probably happeend because there's a conflict between the default version you get if you don't specific and the concept of "version"
16:28:59 cdent I would expect "version" to mean "what i get if I say nothing"
16:29:02 mordred elmiko: :) -- my next couple of months are going to be essentially chasing folks down to let me implement some of the guidelines ... so I'm kind of poking around the edges to figure out how it's gone so far
16:29:07 cdent which would mean min_version
16:29:15 elmiko mordred: ooh! neat =)
16:29:26 elmiko in that case, +1 to adding them
16:29:26 mordred elmiko: wish me luck!
16:29:41 cdent so by being explicit about max, min, we avoid the confusion
16:29:53 edleafe hmmm... maybe add a note to the microversion guideline about the existing services that don't follow
16:30:06 mordred edleafe: I can do that in one of my next passes through the stack
16:30:44 edleafe yeah, I mean, I know nova will never change this, so we should at least acknowledge reality
16:30:54 elmiko edleafe: good point
16:31:04 cdent we did manage to add support for openstack-api-version: compute x.y
16:31:17 cdent so we may not ever remove the old way, but we can add the new way
16:31:53 edleafe cdent: true, so maybe there's hope :)
16:36:16 elmiko bbl
16:53:22 mordred mugsie, sdague: the sub-elements patch has examples published herE: http://docs-draft.openstack.org/55/464255/5/check/gate-nova-api-ref-src/f02b170//api-ref/build/html/ - versions and list-sever-details are both good examples to look at for output
16:53:52 mordred I don't feel super strongly about this at all - it was more a thing I've hit up against before reading the docs so I thought I'd take a random stab at it
16:57:19 sdague mordred: ok looking
16:57:36 sdague mordred: have we gotten a read from horizon folks as to if they like this approach?
16:58:53 sdague I think it has definite advantages, we probably need a good glossary explaining how to read it (maybe if we had a footnote added to the bottom of every table automatically)
16:58:58 mordred sdague: I have not poked any of them but I can - what's the specific tie to horizon? (I may be missing context)
16:59:12 sdague just, they are folks that tend to read our api-ref
16:59:22 sdague honestly, I just want other readers
16:59:28 mordred ah- gotcha. yes- they would be great additional inputs
16:59:39 mugsie I agree with the problem statement - I am just not sold on the format
16:59:41 mugsie but
16:59:45 mugsie we could iterate that
16:59:48 sdague because I'm so steeped in this that I don't trust my judgement on better/worse
17:00:40 sdague if we had a couple of common consumers say "yes please", I'd be all for a "you betcha"
17:01:12 mugsie mordred: where did the '[]' come from - for me that looks a bit wierd
17:01:13 mordred I also am not sold on the format either- so feedback/suggestions from folks would be great
17:01:33 mordred mugsie: servers is an array - so servers.name looked weird to me
17:01:41 sdague mugsie: it is to distinguish array vs. object attr
17:01:45 sdague which makes sense
17:01:56 mordred yah. I also _think_ I got the idea from the GCE docs - but I might e lying about that
17:02:11 sdague so, because json requires a top level key, I do wonder if we can shorthand past the first key
17:02:30 mordred but it doesn't
17:02:41 mordred we actually do have APIs in openstack that do not return top level keys
17:02:50 sdague ... o really....
17:02:51 sdague where?
17:03:11 mordred yup. glance single version image discovery springs immediately to mind- but there are others - I could go look
17:03:29 mordred gah
17:03:35 mordred s/image discovery/version discovery/
17:04:33 mordred also I believe swift capabilities
17:16:26 openstackgerrit caoyuan proposed openstack/python-openstackclient master: Correct the "extra spec" command openstack https://review.openstack.org/465122
17:21:46 openstackgerrit Samuel de Medeiros Queiroz proposed openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword https://review.openstack.org/463432
19:58:00 chit Hi, could anybody give me a high-level overview of the openstackclient code base? As in, where the control flow starts, and what calls what first and when. Thanks :)
19:59:36 dtroyer chit: the basic structure is defined by cliff, the library that provides the app and command objects in use: http://git.openstack.org/cgit/openstack/cliff
20:00:14 dtroyer you will need python-openstackclient and osc-lib source to walk through the shell and ClientManager objects that do all of the cenral coordination
20:00:29 dtroyer specific commands are dispatched via setuptools' entry points
20:09:25 chit So when the client performs something like a "openstack server list", would the constructors defined in the cliff library get called? Would the App and Command objects get created from there?
20:13:38 dtroyer chit: yes they do
20:13:58 dtroyer command-wise, though, only for the command(s) being executed
20:14:40 openstackgerrit Merged openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword https://review.openstack.org/463432
23:14:30 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Keep a singleton to support multiple get_config calls https://review.openstack.org/465195
23:33:14 openstackgerrit Merged openstack/keystoneauth master: Add ADFSPassword to keystoneauth1 entry points https://review.openstack.org/463234
#openstack-sdks - 2017-05-17
00:26:22 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Convert image functional tests into JSON format https://review.openstack.org/465203
01:28:37 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Convert image functional tests into JSON format https://review.openstack.org/465203
01:30:45 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Convert volume type functional tests into JSON format https://review.openstack.org/465208
01:42:12 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Make block-device-mapping more stable and clear https://review.openstack.org/438141
01:44:29 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: [Compute]Make column content readable for both human and machine https://review.openstack.org/445794
01:51:10 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Convert volume functional tests into JSON format https://review.openstack.org/465208
01:51:40 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Create server with security group ID and name https://review.openstack.org/462076
01:52:05 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Convert image functional tests into JSON format https://review.openstack.org/465203

Earlier   Later