19:00:22 <briancurtin> #startmeeting python-openstacksdk
19:00:23 <openstack> Meeting started Tue Mar  4 19:00:22 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:26 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:01 <briancurtin> #link agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-03-04_1900_UTC
19:01:40 <briancurtin> Can everyone here for the Python OpenStack SDK meeting state their name and affiliation?
19:01:55 <jnoller> Jesse Noller, Rackspace
19:01:58 <mfer> Matt Farina, HP
19:02:04 <bknudson> Brant Knudson, IBM
19:02:06 <briancurtin> Brian Curtin, Rackspace
19:02:08 <wchrisj> Chris Johnson, HP
19:02:09 <edleafe> Ed Leafe, Rackspace
19:02:11 <jamielennox> Jamie Lennox, Red Hat
19:03:11 <jnoller> dtroyer: we're in the name & affiliation roll call
19:03:32 <dtroyer> ok…Dean Troyer, Nebula
19:04:06 <briancurtin> i think we're probably set to go, people may just roll in late
19:04:11 <briancurtin> # topic Feedback on the wiki / current state (open discussion)
19:04:24 <briancurtin> #topic Feedback on the wiki / current state (open discussion)
19:04:35 <jnoller> #link https://wiki.openstack.org/wiki/PythonOpenStackSDK
19:05:20 <briancurtin> fwiw, i have some wiki stuff to talk about with extensions but it falls explicitly under that topic. the wiki is mostly unchanged since the last meeting outside of that, though
19:06:10 <jnoller> Does anyone have anything to discuss - have people taken a look at the blueprints / etc
19:06:13 <jamielennox> has there been any change in the project since last meeting?
19:06:29 <jamielennox> i haven't seen anything for blueprint/wiki aspect
19:06:36 <bknudson> is there any code or a repo?
19:06:39 <jnoller> jamielennox: Brian and others have been working on blueprints primarily
19:07:04 <briancurtin> jamielennox: perhaps we should discuss your comment on the implement-services blueprint? "I'm still interested in the ability of taking the API version specific core of the various clients and keeping SDK focused on the problem of abstracting that information. It does not affect that we will need to implement bindings to the services though."
19:07:20 <edleafe> bknudson: no - we're still discussing design requirements/ideas
19:07:25 <briancurtin> jamielennox: other than that, there's some vendor/third-party extension stuff to discuss that we could jump into
19:08:05 <jnoller> Actually, could you clarify that jamielennox?
19:08:30 <jamielennox> briancurtin: sure, it's essentially the same concern i've had previously in the goal of the SDK
19:08:46 <jamielennox> is the goal to provide a replacement for all the clients
19:08:57 <jamielennox> or a more sane way to deal with them all and do cross api versions nicely
19:09:16 <bknudson> looks like a requirement of this project is to not use the existing clients.
19:09:17 <jamielennox> my concern with point a is the duplication of effort
19:09:51 <jamielennox> So the blueprint i put up was to start a discussion about how we do cross API versions nicely
19:09:59 <edleafe> jamielennox: The existing clients are not very consistent
19:10:19 <jamielennox> i'm particularly coming from keystone here where the change from v2 to v3 is a significant API break
19:10:28 <jamielennox> edleafe: i completely agree
19:10:31 <mfer> I'm not sure there is a way to take the existing client code and have it fit into the requirements
19:11:06 <jnoller> I would say that re-using code from them is good; but the individual clients that we expose as API endpoints to the users needs more consistency: I think the new keystone client is actually a good starting point as an effort for a common backend
19:11:09 <edleafe> mfer: Exactly. There are some good design pieces, but not whole clients
19:11:15 <jamielennox> i have been trying to do cross client work recently and i completely agree - but does that mean we start again or try to fix them
19:11:59 <bknudson> jamielennox: were you planning to have other clients import keystoneclient?
19:12:00 <jnoller> Well, there's the other effort under oslo working on code reuse / etc - but I think that we have to actually start from 0 and look at what works and doesn't work - e.g. the keystone changes
19:12:02 <mfer> if the existing clients can't meet the needs than I don't see another way than to re-implement it.
19:12:02 <jamielennox> this is a lot of what andrey is pushing with the common apiclient
19:12:05 <edleafe> jamielennox: in my experience, starting with a good overall design will make adding binding for each additional service that much easier
19:12:19 <dtroyer> I think starting fresh rather than trying to do it in-place is a win because we don't have to worry about backward-compatability
19:12:27 <jnoller> dtroyer++
19:12:29 <briancurtin> yep
19:12:31 <mfer> dtroyer++
19:12:31 <jamielennox> bknudson: not if the session code works out how i would like
19:12:43 <wchrisj> dtroyer++
19:12:57 <jamielennox> dtroyer: ok
19:13:24 <jnoller> but I think we *need* to look at what the clients do right jamielennox
19:13:31 <mfer> we aren't trying to build the next rev for the openstack devs. we're trying to build the first rev for application devs.
19:13:38 <jnoller> mfer: well put
19:14:04 <edleafe> mfer: exactly
19:14:06 <dtroyer> mfer: but if it happens to be too good for the openstack devs to pass up, well, win?
19:14:10 <jamielennox> mfer: yes, so long as that is not to the exclusion of the devs
19:14:18 <jamielennox> (not implying it will)
19:14:30 <jnoller> We have to bring both along for the ride;
19:14:37 <jnoller> but remember the key audience
19:14:49 <mfer> jamielennox i think it's more about keeping the target in focus so we shoot for a clear goal that try to be all things to all people
19:14:59 <bknudson> there might be something that devs would like. e.g. they're using it to test their REST API. We don't need to support that.
19:15:05 <edleafe> we are building a clean, usable python SDK for python developers
19:15:11 <briancurtin> for end-users
19:15:22 <jamielennox> ok - didn't mean to sidetrack this again
19:15:53 <jnoller> jamielennox: no man, good question
19:16:04 <bknudson> I think some people were thinking we'd have the API automatically generated.
19:16:12 <jamielennox> the blueprint i posted was particularly about how to deal with the cross API versions and distinguishing what is and is not available on a specific api
19:16:19 <bknudson> maybe from the schema for the services.
19:16:22 <jnoller> jamielennox: and I think its fair (and we have to check our assumptions)
19:16:26 <jamielennox> (i assume that's where the quote came from)
19:16:43 <bknudson> but I wouldn't expect that would lead to the user API we'd like.
19:16:47 <jnoller> bknudson: I don't think auto-generated code lends itself to sanity
19:17:13 <wchrisj> jnoller++
19:17:45 <dtroyer> plus, it'll be a while before that is even available to us for more than 1 or 2 APIs
19:18:15 <jnoller> Yeah, using jsonschema would be awesome, but I *personally* distrust exposing auto-generated code to end-users.
19:18:35 <dolphm> (jumping in late) everyone keeps talking about the "target audience" etc, but it's not clear what segment of developer/users that actually is
19:18:39 <mfer> jnoller is there much in the form of jsonschema right now?
19:18:58 <wchrisj> I like the idea of using that sort of tool to help us as devs keep things up to date tho...
19:19:07 <jnoller> dolphm: from https://wiki.openstack.org/wiki/PythonOpenStackSDK - "application developer consumers"
19:19:08 <dolphm> some APIs are aimed at deployers / cloud administrators - are we targeting them?
19:19:09 <bknudson> the nova v3 api has validation through a schema.
19:19:13 <briancurtin> mfer: marconi has some usage of jsonschema from what i remember
19:19:26 <edleafe> dolphm: python developers building apps that use OpenStack services
19:19:46 <mfer> I saw a small amount of json schema in glance. but, not a whole lot all around
19:20:02 <jnoller> dolphm: I think we discussed some of that last time: the main abstraction wouldn't leak those deployer / admin tools, but there's no reason why the underlying client code would not (essentially a leaky abstraction)
19:20:30 <jnoller> dolphm: Also, I think we totally have room for a OpenStackClient / OpenStackAdmin style set of objects
19:20:33 <bknudson> so I think this is where jamielennox's comment about duplication of effort comes in --
19:20:50 <bknudson> we're going to have the appllication developer API, but we'll still need the other python-* APIs around
19:21:02 <jamielennox> jnoller: i don't see why it can't include admin functionality. probably one of the main people who will want to script these services are the cloud admins
19:21:05 <jnoller> bknudson: Not if we implement those to
19:21:11 <edleafe> bknudson: not sure why that follows
19:21:12 <dolphm> so, the long term goal is to support every API exposed by every service, not just a specific subset
19:21:17 <jnoller> jamielennox: Yeah, I'm just saying name them explicitly
19:21:17 <dtroyer> If the SDK has basically two layers we can address both needs: the low-level that is API version-specific and an abstraction over that (like jamielennox talked about) to hide the messiness
19:21:28 <edleafe> you can build tools on the SDK that are targeted for different use cases
19:21:35 <jamielennox> dtroyer: ++
19:21:41 <edleafe> the SDK simply wraps the low-level API in a Pythonic way
19:21:42 <bknudson> so for example an application developer API isn't the cloud management API ...
19:21:50 <briancurtin> bknudson: eventually, those python-* APIs can use this SDK as a backend. over time, end-users could move off of those python-* APIs into using the highest level abstractions the SDK provides
19:21:50 <bknudson> and Horizon is going to use the management API
19:22:06 <jamielennox> briancurtin: that's... ambitious
19:22:24 <jnoller> dolphm: In the internals - yes, for example, openstacksdk.services.keystone could be rich and support all of the APIs; but developers would not start there, they'd use, say, openstacksdk.client which would expose a clean and consistent subset
19:22:24 <edleafe> clarification: when we say "APIs", are we talking about "CLIs"?
19:22:34 <dolphm> briancurtin: what's the benefit of that dependency relationship?
19:22:36 <bknudson> I'm willing to put up with the code duplication since it's different uses.
19:22:44 <dtroyer> edleafe: no
19:22:48 <dolphm> edleafe: i hope not
19:22:49 <briancurtin> edleafe: a CLI is an application of an API
19:23:02 <edleafe> That's my understanding
19:23:06 <jamielennox> CLIs should come nowhere near this project
19:23:07 <bknudson> but it also looks like, if we do have duplication, some of this could be shared... e.g., "Verified mocks/stubs for testing at all layers. "
19:23:11 <dolphm> jamielennox: ++
19:23:12 <wchrisj> The CLI would use the SDK we are discussing
19:23:14 <edleafe> But it sounds like the two are being confused
19:23:22 <dolphm> if this thing has a CLI beyond python -c then i'm going to cry
19:23:29 <wchrisj> no CLI here
19:23:34 <jnoller> jamielennox: That was in the spec / wiki page: ideally the python-* clients could leverage a single dependency (this SDK)
19:23:50 <dtroyer> But there is one next door that cares deeply about this project ;)
19:24:11 <edleafe> Then explain what the issue is with apps that would be used for deployment vs. other uses
19:24:24 <edleafe> The API is the API, and the SDK simply wraps that
19:24:27 <briancurtin> dolphm: to get to your earlier question about the benefit of the dependency, is that it gets each client away from writing their own HTTP stack, their own everything
19:24:33 <jamielennox> jnoller: i think the dependency there is a bit backwards - but it works if your goal is deprecation of the python-*clients
19:24:35 <edleafe> There isn't any other functionality being added, is there?
19:24:41 <jnoller> jamielennox: Mine is.
19:24:41 <dtroyer> edleafe: I think the distinction is client needs within OpenStack itself (auth_token for example) vs external
19:24:47 <mfer> Services expose APIs, the SDK wraps them, CLIs and other applications wrap the SDK
19:24:52 <jamielennox> jnoller: i think the compatibility will still kill it
19:25:11 <jnoller> jamielennox: Time will answer that; sort of like the V3 discussions
19:25:12 <edleafe> mfer: exactly. So what's the confusion about devops vs. app devs?
19:25:40 <edleafe> They would use tools built for their needs on top of the SDK
19:26:04 <mfer> edleafe if a dev ops person wants to write an application that helps with ops they can use the SDK. it's the development part rather than the ops part. Ops part uses tools build on top of the SDK
19:26:28 <edleafe> That's my view, too
19:26:31 <mfer> the dev in devlops is the target of the SDK not the ops part of devops
19:26:51 <dolphm> there also seems to be some confusion around the term "SDK" -- it's a "client library for openstack as a whole" first and foremost, as i understand it
19:27:03 <jnoller> dolphm / jamielennox  - is there an action item for us to to clarify this
19:27:17 <mfer> dolphm it's an SDK. A CLI or other application is a different project
19:27:20 <jnoller> An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:
19:27:20 <jnoller> Documentation aimed at users consuming the SDK and system.
19:27:20 <jnoller> Clear examples of usage, including functioning, executable examples.
19:27:20 <edleafe> dolphm: SDK == language binding + docs + examples, etc.
19:27:35 <dolphm> edleafe: agree
19:27:39 <dolphm> jnoller: i'm asking questions for my own benefit, mostly
19:27:50 <jamielennox> jnoller: i was just looking for are we looking to replace existing clients
19:27:54 <mfer> so, my burning question is... what do we want to get done by the next meeting?
19:27:58 <jnoller> OK
19:28:05 <jamielennox> indeed, moving on
19:28:12 <jnoller> mfer: We do have the vendor extensions thing brian drafted
19:28:21 * mfer wants code to be written and magic to be made
19:28:22 <briancurtin> shall we move on to that?
19:28:30 <jnoller> yes please
19:28:32 <briancurtin> #topic https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK/Extensions
19:28:56 <briancurtin> that's just a bunch of ideas and directions throw out on paper - not written to go any one way, just to put things on the table
19:29:16 <briancurtin> a lot of it is pulled from previous meeting and previous talks
19:29:19 <jnoller> Clarification: This intentionally avoids setup tools entrypoints
19:30:33 <jamielennox> ++ on explicit importing
19:30:59 <jamielennox> i think whether extensions are vendor or service orientated will depend on the structure we come up with for the core
19:31:08 <jnoller> Does anyone have strong feelings here: ideally vendor extensions go the way of the dodo however, since say rackspace and HP have CDN, we could collaborate on a openstack.extensions.cdn extension
19:31:10 <jamielennox> but both would be nice
19:31:15 <jnoller> yeah
19:31:56 <edleafe> I think there will always be vendor extensions, as much as we'd wish for them to not be needed
19:31:58 <jnoller> (also, love "CloudVendor Cloud" - modifying summit talk slides)
19:32:03 <Alex_Gaynor> I'm -1 on vendor extensions in the main repo.
19:32:04 <jamielennox> jnoller: -- on the setuptools thing though, i realize it's ugly but let's just wrap it behind stevedore and let the setuptools fixes come as they will
19:32:15 <wchrisj> Only concern on my part with external is possibility of degraded quality (inadequate test enforcement)
19:32:32 <jnoller> jamielennox: That prevents single binary builds, and consistently causes random installation problems
19:32:38 <dtroyer> do we have to call it 'vendor extensions?'  is there a functional disctinction from, say, an extension to support a not-yet-incubated API?
19:32:42 <Alex_Gaynor> If we were to have vendor extensions, how would we even decide what vendors?
19:32:55 <jnoller> Alex_Gaynor: Allow them to commit to the repo
19:32:57 <jamielennox> wchrisj: i think that's the cost you pay for being outside the core and it will hurt those vendors who develop externally
19:33:01 <briancurtin> Alex_Gaynor: whichever vendors want to provide their extensions
19:33:02 <dolphm> i'd rather not have vendor-specific code in-tree, period
19:33:05 <Alex_Gaynor> jnoller: who, anybody?
19:33:22 <Alex_Gaynor> If I run a server in my apartment am I allowed to put my vendor extensions in here?
19:33:28 <jnoller> Alex_Gaynor: If there is an external vendor thing, for say rackspace, I expect a PR from rackspace exposing it
19:33:37 <mfer> when i think of this I'm thinking of the end users again. The app developer may want to write an app to connect to an IBM private cloud, an HP managed cloud, and a Rackspace public cloud. Now we want to enable them to do that with as little pain as possible
19:33:39 <Alex_Gaynor> What's the procedure for testing these things in the gate?
19:33:49 <jamielennox> jnoller: is single binary builds a concern?
19:33:53 <briancurtin> Alex_Gaynor: that's where the internal thing gets complicated, in that there probably has to be some graduation process, third-party testing, etc
19:33:54 <jnoller> jamielennox: Yes
19:33:57 <briancurtin> absolutely
19:34:22 <dtroyer> jamielennox: that's a big reason why entrypoints need to go away
19:34:51 <briancurtin> mfer: that problem is important, is somewhat addressed by both where the code lives, and how it's distributed (and maybe a combination of both)
19:34:58 <jnoller> relying on setuptools to manage extensions is not a win unless you can guarantee the installation environment
19:35:09 <jamielennox> is this a windows thing? (out of interest - not because of redhat)
19:35:17 <jnoller> can we go back to something dtroyer said
19:35:26 <jnoller> jamielennox: Windows, OSX and flavors of linux
19:35:32 <dtroyer> jamielennox: windoes is the best (worst) example, but not exclusive
19:35:39 <mfer> briancurtin not exactly. that app developer writing the guts of their code may not know who they are dealing with at that point.
19:35:41 <jnoller> jamielennox: system python is ... not always awesome
19:35:42 <dhellmann> if we want to replace setuptools, we can do that in the stevedore layer for portability
19:36:10 <jnoller> quoting dtroyer: "<dtroyer>	 do we have to call it 'vendor extensions?'  is there a functional disctinction from, say, an extension to support a not-yet-incubated API?"
19:36:29 <jnoller> I think that's an interesting point and one we haven't touched on
19:36:35 <jnoller> Let's examine solum support for example
19:36:38 <briancurtin> mfer: that problem is what i had in mind with the "kitchen sink" distro, where you get 'em all
19:36:51 <jnoller> I think it's perfectly valid for it to be *in the tree* and shipped, but labeled
19:36:52 <dtroyer> briancurtin: but that's a packaging problem
19:36:58 <mfer> briancurtin it's more than including all of them. it's how you work with services based on them
19:37:24 <jnoller> dtroyer: heh, it's a packaging problem, and python packaging is part of the problem, ask dstufft :)
19:37:47 <dolphm> jnoller: labeled how?
19:38:02 <jamielennox> jnoller: having all this stuff 'in tree' is going to be a nightmare
19:38:19 <dolphm> jamielennox: ++
19:38:26 <jnoller> dolphm: Suggestions? We could just say "external" or something akin to that
19:38:31 <jnoller> jamielennox: Why?
19:39:02 <jnoller> Look at (for example) Fog, JClouds, libcloud, and others
19:39:04 <dolphm> unless you have a really strong distinction between stable SDK features and experimental-this-may-change-dramatically-in-the-next-12-minutes you're just going to create the same maintenance nightmare presented by every other client
19:39:12 <jamielennox> we already will have 9ish core services, allow X many incubating services, and then we try to put extensions in that can cross between everything
19:39:38 <jnoller> We have close to 25 total services
19:39:41 <jamielennox> even just for review load
19:39:54 <Alex_Gaynor> Is this a question we can defer until after we've written more of the core bits?
19:40:04 <jnoller> Alex_Gaynor: I think that's fair
19:40:05 <dolphm> Alex_Gaynor: i don't think so - it's a question of "what is the core bits"
19:40:14 <jnoller> oh no
19:40:18 <jamielennox> Alex_Gaynor: i think it can be simultaneous
19:40:22 <dolphm> jnoller: not *that* "core"
19:40:23 <Alex_Gaynor> dolphm: core openstack projects for starters? And we can consider branching out?
19:40:29 <jnoller> dolphm: heh :)
19:40:39 <Alex_Gaynor> keystone, nova, swift, cinder, glance; that should keep us busy for a little while :-)
19:40:43 <dolphm> Alex_Gaynor: i still think that's too vague/broad/ambitious/unrealistic
19:40:45 <jnoller> Alex_Gaynor dolphm: I would say current integrated
19:41:12 <jnoller> dolphm: Current integrated is basically the MVP for the SDK
19:41:24 <dolphm> Alex_Gaynor: what features of keystone, nova, swift, cinder and glance? which release of those services?
19:41:24 <briancurtin> there's a BP for this (mostly empty so far) https://blueprints.launchpad.net/unifiedsdk/+spec/define-supported-services
19:41:31 <dtroyer> There is a service hierarchy of dependencies that we can use to decide order
19:41:53 <dtroyer> everything needs auth, so Identity is first
19:42:02 <dtroyer> etc
19:42:13 <wchrisj> I agree Identity is first
19:42:19 <bknudson> I'm wondering what libraries are available that we should be making use of?
19:42:21 <jnoller> Yeah
19:42:31 <bknudson> e.g., we've got requests-based code in keystoneclient
19:42:31 <jnoller> bknudson: Example?
19:42:35 <jamielennox> bknudson: for what
19:42:37 <dtroyer> Compute, Volume, Image are the next most-depended on services, Object-Store maybe too
19:42:50 <dolphm> dtroyer: but no one needs *all* of keystone
19:43:08 <dtroyer> dolphm: true, I haven't broken them down past that yet
19:43:15 <bknudson> I'm happy with requests, but maybe there's some reason we should stay away from it and use something else?
19:43:22 <jamielennox> right, auth is first, not necessarily identity
19:43:36 <dolphm> dtroyer: i'd like to have a philosophical goal to start with, to make it easier to say "no" to feature X being exposed in an SDK
19:43:40 <jnoller> Identity; Compute, Volume, Image for starters; and of course the core HTTP client (as bknudson says) - fwiw, Alex_Gaynor has an example construct that abstracts the http client away
19:43:41 <briancurtin> dolphm: an end-user may not, but an admin or someone else may. that goes back to providing light abstractions for someone building an app to use openstack versus someone operating an openstack cloud
19:43:56 <dolphm> briancurtin: that's why i asked if we were targeting end users or "admins"
19:44:21 <Alex_Gaynor> end users.
19:44:33 <bknudson> what would an application need to do with keystone?
19:44:36 <bknudson> define users?
19:44:36 <briancurtin> dolphm: i think the ultimate success is if this is useable by end-users. however, along the way, there's no reason this can't be designed so that it's fully usable for admins
19:44:39 <jamielennox> bknudson: requests is good, i haven't really come across anything else i'd say really needs to be there
19:44:39 <dolphm> Alex_Gaynor: so, "create domain" would never be exposed in the SDK, correct?
19:45:16 <dolphm> "create identity is currently a cloud-admin feature, not something any end user would need to use
19:45:21 <bknudson> maybe we could come up with a scenario that we can aim towards.
19:45:24 <dolphm> "create identity domain" *
19:45:27 <jamielennox> dolphm, Alex_Gaynor: i don't think 'never be exposed' is an option for anything - as soon as something is not available then we cannot deprecate the python-*client that does implement it
19:45:30 <Alex_Gaynor> dolphm: I don't know if I'd necessarily object to having it, but definitely not a priority, and probably documented somewhere special.
19:45:56 <jamielennox> whether it's wrapped in a nice cross-API layer is different
19:45:58 <mfer> so, i see we're about 15 minutes to the end of this meeting and it would be great if we had some actionable tasks to do before the next meeting. what can we do that will get us to code?
19:46:02 <jnoller> the internal openstack.services.keystone would expose that, but not the high level
19:46:10 <dolphm> Alex_Gaynor: so draw the line between "special" and "not special" for me? and why can't we say "no" to "special" ?
19:46:14 <edleafe> If it's in the API, it should be accessible in the SDK. Just document the hell out of it.
19:46:17 <wchrisj> For the first cut, why cant we just take the Identity API and implement based on that?
19:46:30 <jnoller> wchrisj: +1
19:46:37 <Alex_Gaynor> dolphm: things a person using a cloud would want vs. things a person operating a cloud would want
19:46:38 <bknudson> you mean python-keystoneclient?
19:46:49 <jnoller> Alex_Gaynor: Got a link to your example internal structure
19:47:11 <Alex_Gaynor> jnoller: https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/client.py
19:47:12 <mfer> so, before next week can someone take a shot at identity v2?
19:47:27 <bknudson> identity v2 is deprecated.
19:47:36 <jamielennox> i would like to be involved in that if we are looking at identity
19:47:38 <mfer> and yet a load of people are using it
19:48:18 <mfer> i suggested v2 because it's more widely available in practice. i'm fine with v3 but we should likely support both at some point
19:48:21 <bknudson> jamielennox: can you link to your auth plugins?
19:48:26 <jnoller> Is this structure that Alex_Gaynor laid out a "good enough" starting point for us to build out the basics and get it functioning?
19:48:40 <jamielennox> so i've been talking with dtroyer recently about the current managers approach, do we want to keep that design? eg identity.users.list()
19:48:45 <jnoller> Alex_Gaynor might want to chime in why its done that way
19:48:50 <Alex_Gaynor> Please note that this is *far* less concerned with the public API, and more concerned with the internals.
19:49:00 <Alex_Gaynor> identity.uysers.lists() vs. identity.list_users() is of no concern to me :-)
19:49:07 <jamielennox> https://github.com/openstack/python-keystoneclient/tree/master/keystoneclient/auth
19:49:13 <briancurtin> #topic API status
19:49:33 <Alex_Gaynor> The key idea is clean seperation between data and executing HTTP requests.
19:50:03 <edleafe> Alex_Gaynor: And that design can be used with any SDK design
19:50:13 <dolphm> jnoller: just glancing at the "strawman," it makes a ton of undocumented assumptions
19:50:14 <Alex_Gaynor> Indeed
19:50:32 <jnoller> dolphm: Which one
19:50:36 <dolphm> https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/client.py
19:50:40 <jnoller> thanks'
19:51:38 <edleafe> dolphm: that isn't really an API strawman; the one I outlined in https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman/pystack is a working design
19:51:51 <jnoller> For a basic start on the *public* api, we have two rough drafts: https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/README.rst
19:51:58 <edleafe> fwiw, Alex's code could work well in mine
19:53:20 <dolphm> why is any of this in the tree?
19:53:25 <jnoller> I'd say let's build out from Alex's core, and then get agreeance on the public API - I definitely prefer the "client = OpenStackClient(KeystoneAuth('http://localhost:8000/', 'alex', '****'))" syntax
19:53:57 <briancurtin> i believe dolphm did mention previously to back them out and then run through gerrit reviews (or something along those lines)
19:54:06 <dolphm> if the goal is a solid UX, committing "ideas" is a rough way to start
19:54:35 <jnoller> dolphm: Completely fair: This was my first stab at stack forging - so that's my bad.
19:54:47 <jnoller> dolphm: Also, there were not enough eyeballs (again, my fault)
19:55:14 <mfer> jnoller given what we know and the api strawman... is it time for someone to roll the initial identity client code and get it up for review?
19:55:28 <jnoller> mfer: yeah I was typing
19:56:00 <jnoller> So goals by next meeting: 1: Back out the straw man, 2: Get the core http stuff done enough to begin work on the identity work
19:56:08 <dolphm> 1: https://review.openstack.org/#/c/75362/
19:56:10 <jnoller> 3: Get rough identity client
19:56:38 <wchrisj> Excellent
19:56:41 <jnoller> Ok so 1 is done
19:56:42 <briancurtin> #action https://review.openstack.org/#/c/75362/
19:56:43 <bknudson> one of the things that we might want to decide is overall -- do we go with an async implementation (with callbacks) or a simpler synchronous one.
19:57:02 <jnoller> bknudson: That is a question Alex_Gaynor's proposal was trying to avoid
19:57:06 <briancurtin> #action core HTTP layer to build on
19:57:07 <wchrisj> Even if there is a lot of churn/iterating at first, code talks.
19:57:12 <briancurtin> #action rough identity client
19:57:18 <Alex_Gaynor> jnoller: not so much avoid, as allow us to answer multiple ways
19:57:24 <jnoller> Alex_Gaynor: yes
19:57:41 <Alex_Gaynor> bknudson: I think the inital API we should expose shoudl be synchrnous, but the internals should make it very easy to do an async (twisted, asyncio, etc.) one without rewriting EVERTYHIGN
19:57:46 <jnoller> I apologize all, I have a hard stop now: mfer those tasks look good?
19:58:06 <bknudson> Alex_Gaynor: ok, will be interesting to see examples.
19:58:08 <mfer> jnoller sounds good to me
19:58:19 <jnoller> thanks all - brian you got this :)
19:58:55 <briancurtin> 2 minutes on the clock...anything else to cover? any other action points we want to see?
19:59:21 <Alex_Gaynor> I think I might have a burrito for lunch.
19:59:30 <jamielennox> mfer: so are you taking those 3 jobs?
19:59:36 <dolphm> jnoller: the gate also appears to be already wedged, as there are no newlines in the requirements files
19:59:48 <dolphm> https://review.openstack.org/#/c/75852/
19:59:54 <jamielennox> as i have re-written essentially the first 2 recently (so i have an interest)
20:00:36 <mfer> jamielennox ha... nope. i just want to make sure they are there. for us wchrisj is going to be doing more of the coding
20:00:37 <dtroyer> jamielennox: as long as you stop stuffing things into Session  ;)
20:00:44 <wchrisj> I'd be glad to help get this done
20:01:03 <jamielennox> dtroyer: oh, there's more
20:01:19 <dtroyer> rename it Client then
20:01:20 <edleafe> I'm looking to help with the code, too
20:01:29 <briancurtin> should we take this back to #openstack-sdks?
20:01:42 <briancurtin> #endmeeting