19:00:39 <briancurtin> #startmeeting python-openstacksdk
19:00:40 <openstack> Meeting started Tue Mar 18 19:00:39 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:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:44 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:12 <briancurtin> #link https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK <- agenda
19:01:54 <briancurtin> May as well start with roll call and let everyone file in. Can everyone here for the python-openstacksdk meeting state their name and affiliation?
19:02:02 <edleafe> Ed Leafe, Rackspace
19:02:09 <wchrisj_> Chris Johnson, HP
19:02:20 <dtroyer> Dean TRoyer, Nebula
19:02:21 <Alex_Gaynor> Alex Gaynor (affiliations: Rackspace, many many others, avialable upon request, lol)
19:02:24 <bknudson> Brant Knudson, IBM
19:02:26 <briancurtin> Brian Curtin, Rackspace
19:02:28 <jamielennox> Jamie Lennox, Red Hat
19:03:50 <briancurtin> so i guess the first thing is Alex_Gaynor's review
19:03:53 <mfer> Matt Farina, HP
19:03:53 <briancurtin> #topic https://review.openstack.org/#/c/79435/
19:04:43 <Alex_Gaynor> Want me to talk about teh current status of it?
19:04:55 <briancurtin> Alex_Gaynor: sure, go ahead
19:05:10 <briancurtin> i guess the ultimate goal here would be to figure out what the next steps are
19:05:23 <Alex_Gaynor> So, I think the code is basically don-ish, which is to say I have no more TODOs, and I think I've responde to every review item. It's blocked on requirements integration with the CI stuff.
19:05:34 <Alex_Gaynor> I'm working on getting that unblocked today with the infra/config repos/folks.
19:06:30 <briancurtin> i agree that it seems to be done-ish. i got beat to a lot of my comments, so i haven't had any specific input on the reviews, but will give it another look
19:06:39 <bknudson> endpoints is going to have a function for every type of openstack request?
19:06:46 <bknudson> actually a class
19:07:06 <Alex_Gaynor> I think we may eventually find patterns to make that even simpler, but for now, yeah
19:07:49 <bknudson> does this require a versioned endpoint? i.e., http://localhost:5000/v2.0 ?
19:08:15 <edleafe> So are we planning on having permutations for every combination of auth? Methods like 'CreateIdentityV2UsernamePasswordTokenRequest' seem like they would lead to copy/paste hell
19:09:07 <jamielennox> given the early stage we are currently at i'm fine with merging reviews like this until we get to the point we figure out what we need to improve on, there are no compatability issues to deal with yet
19:10:02 <wchrisj_> Alex_Graynor: where does discovery fit into this approach (endpoints, versioning, etc.)?
19:10:15 <wchrisj_> Alex_Gaynor: ^^
19:10:27 <Alex_Gaynor> You're talking about integration with the srvice catalog, or discovery of the properties of teh auth endpiont?
19:10:44 <wchrisj_> including api version, yes.
19:11:06 <wchrisj_> that would cut down on those permutations dramatically
19:11:15 <Alex_Gaynor> I'm not sure what the best pattern for that is, I think it's by composing what's in that PR though.
19:11:57 <wchrisj_> Have you looked at what jamielennox: has done around that?
19:12:29 <Alex_Gaynor> I looked through some of the keystoneclient stuff, yes.
19:12:58 <jamielennox> (there is a review up now to make keystoneclient discovery a bit more sane and useful)
19:13:03 <briancurtin> edleafe: can we just have IdentityV2 and have it accept user, pass, token, fancy handshake, whatever, and construct an appropriate request with what's given?
19:13:33 <edleafe> briancurtin: I would certainly prefer that approach
19:13:50 <Alex_Gaynor> I think it makes sense to compose that on top of what's there, rather than putting it all into one class.
19:13:54 <jamielennox> briancurtin: that can work for v2 because it's largely frozen but it won't extend to v3
19:14:31 <wchrisj_> I'm definitely arguing against putting it all on one class - especially across versions (Identity v2 vs v3), etc.
19:14:35 <briancurtin> Alex_Gaynor: true
19:14:49 <briancurtin> and jamielennox thanks for the insight
19:15:22 <wchrisj_> ... actually not arguing ;-)
19:16:49 <bknudson> we'll need a CreateIdentityV2UsernamePasswordScopedTokenRequest, too
19:16:58 <bknudson> to get a token scoped to a project
19:17:36 <jamielennox> bknudson: that can't be a parameter?
19:17:49 <bknudson> jamielennox: it could be
19:18:24 <bknudson> actually, I'd expect this unscoped token request wouldn't include a catalog?
19:18:32 <mfer> if the design ends up with methods like that we might want to re-think the approach for developer experience
19:18:40 <mfer> i can't imagine using a method like that
19:18:58 <bknudson> mfer: what's the best method you can imagine?
19:19:20 <briancurtin> mfer: well i think you'd use a higher-level approach to it, like the above mentioned IdentityV2 that takes a bunch of parameters (or something like that)
19:19:38 <edleafe> Or a config setting
19:20:00 <edleafe> A user isn't going to be switching between auth methods all that often
19:20:05 <mfer> i'd likely have an identityv2 object. then i'd auth ot using a username and password.
19:20:20 <mfer> the goal is to create an sdk for application developers. not to reflect what the API does
19:20:30 <edleafe> mfer +1
19:20:56 <briancurtin> as long as calling IdentityV2(username="briancurtin", password="lol") gets me auth'ed properly, i'm good
19:21:12 <Alex_Gaynor> you probably need an auth_url
19:21:23 <Alex_Gaynor> but yeah, IdentityV2 is a trivial composition
19:21:36 <mfer> you might want something like IdentityV2(endpoint)
19:21:41 <mfer> then from that object you auth
19:21:49 <edleafe> Generally things like auth_url, identity version/type, etc., are best left for config settings
19:22:01 <mfer> authenticate(username="briancurtin", password="lol")
19:22:11 <edleafe> The SDK should figure out how to auth based on how it's configured
19:22:11 <Alex_Gaynor> Sorry, what config are you talking abotu ed?
19:22:21 <jamielennox> edleafe: mixing config files and libraries is tricky - you will still need to expose everything via regular optoins
19:22:21 <mfer> edleafe this isn't an app. config should be managed by the app and passed in
19:22:36 <briancurtin> yep
19:22:44 <edleafe> Alex_Gaynor: env vars, for one
19:23:03 <bknudson> maybe you config the library -- openstack.config(auth_endpoint='http://localhost:35357', ...)
19:23:07 <edleafe> jamielennox: everything should be passable, but default to config if not otherwise specified
19:23:15 <jamielennox> edleafe: no, you are definetly mixing the responsibilities of a library vs the application
19:23:30 <mfer> edleafe the SDK should not look for env variables. that makes too many assumptions about the app using it. this is a library not an application
19:24:08 <edleafe> that's just one option
19:24:27 <bknudson> then token, service_catalog = openstack.authenticate(username='user1', password='user1pwd')
19:24:30 <briancurtin> mfer: quick jump-back, but yes on authenticate(...) as a high-level/end-user approach to be built on top of this IdentityV2BlahBlahBlah
19:24:42 <edleafe> there are many ways to set a consistent set of settings
19:25:09 <mfer> edleafe across every possible application using an SDK (most of which you can't imagine) on every platform python runs?
19:25:26 <mfer> edleafe this is seaparation of concerns. app config is not hte concern of the sdk
19:25:46 <jamielennox> edleafe: it's always possible to do context like objects that can be loaded in various ways - have to see what the api looks like to see how they would work
19:26:21 <edleafe> jamielennox: yes. The point is that we should make it simple for the developer
19:27:12 <briancurtin> simple for the developer is "pass a URL in"
19:27:20 <wchrisj_> agreed
19:27:45 <mfer> edleafe simple for a developer to do what? for example, one use case is to authenticate to two different openstack services and copy objects from one to another.
19:27:53 <briancurtin> if we get into config files, config files not existing, confing files in the wrong place, wrong line endings, wrong encoding, wrong configuration, it's not going to be great
19:27:54 <wchrisj_> use case: web app developer
19:28:17 <edleafe> mfer: heh, I do that all the time now  ;-)
19:28:37 <edleafe> but yeah, there will be places where it won't work
19:29:02 <mfer> this is an SDK/library and not an application. as it was said earlier... separation of concerns
19:29:04 <edleafe> I'm thinking about the 80-90% of use cases where it will and we will be making the developer's life simpler
19:29:11 <mfer> storing the config is not the concern of this
19:29:34 <jamielennox> there is advantage to providing standard ways of loading things, ie read this oslo.config file and load up the appropriate auth plugin - however that's a helper function and a  later issue
19:30:08 <mfer> your low level functionality shouldn't assume that
19:30:15 <mfer> that's helper stuff
19:30:21 <jamielennox> mfer: right
19:30:30 <edleafe> I'm not trying to settle how configs might be persisted and read in - just making the point that requiring devs to call methods like 'CreateIdentityV2UsernamePasswordTokenRequest()' is not ideal
19:30:44 <briancurtin> they're not going to have to
19:30:50 <jamielennox> edleafe: i understand that to be an endpoint.py thing and not exposed to the user
19:30:52 <mfer> it's a poor developer experience
19:31:36 <bknudson> seems like we don't need to write CreateIdentityV2UsernamePasswordTokenRequest first... let's write/mock the ideal interface.
19:31:39 <edleafe> jamielennox: then requiring devs to know to create an instance of 'IdentityV2UsernamePasswordAuth' is equally unfriendly
19:31:55 <briancurtin> they're not going to have to
19:32:36 <edleafe> briancurtin: what will they be doing, then?
19:32:48 <jamielennox> edleafe: depends how you cut it up that equivalent in keystoenclient is keystoneclient.auth.identity.v2.Password - just as long a name but importable in a useful way
19:33:08 <briancurtin> edleafe: openstack.authenticate(username="edleafe", password="lol")
19:33:33 <edleafe> briancurtin: then I missed how that call maps to that class
19:33:49 <briancurtin> something like that. a higher-level end-user abstraction that allows them to give the details that they have, which will construct the request that they need
19:34:20 <briancurtin> edleafe: well if you call openstack.authenticate(smokesignal="lkajsldfkjasldkfj"), it'll create an auth object based on smoke signals
19:34:59 <jamielennox> briancurtin: this will quickly become a problem if we are basing authentication upon which parameters are required
19:35:10 <bknudson> we'll need a factory function based on the arguments... username="edleafe", password="lol" -> IdentityV2UsernamePassword, smokesignal="lkajsldfkjasldkfj" -> IdentityV2SmokeSignal
19:36:42 <wchrisj_> as far as I know, there are only two ways to authenticate - username/password, with an optional tenant, and re-authing with a token
19:36:47 <wchrisj_> yes/no?
19:37:00 <edleafe> briancurtin: I was just commenting on the code that has been submitted. I didn't see anything about the sort of interface you're talking about
19:37:11 <briancurtin> that is what we have been talking about
19:37:14 <jamielennox> bknudson: relying on parameters is still a bad way to go -  if you are passing the params you know what you want anyway so i think the plugin approach is better
19:37:33 <jamielennox> wchrisj_: for v2 yes. for v3 that + oauth, kerberos soon and a bunch more to come
19:38:24 <wchrisj_> So for v2, I'd suggest we do the simplest thing that works
19:38:43 <wchrisj_> and lets learn from that when we build Identity v3
19:39:04 <bknudson> v3 has username and password, too
19:39:10 <wchrisj_> yep
19:39:54 <Alex_Gaynor> There's also proprietary extension nonsense, which should be usable, even if they aren't included in openstacksdk
19:40:41 <wchrisj_> does the proprietary extension nonsense have anything to do with auth?
19:40:58 <jamielennox> Alex_Gaynor: right i see at least the combination of username+password parameters could fit multiple plugins in future
19:41:00 <edleafe> wchrisj_: yes, since Rackspace still uses a proprietary auth
19:41:38 <jamielennox> and if you need to specify my_proprietary_username then you may as well call the plugin because you know what you want
19:41:47 <wchrisj_> isn't that Rackspace auth specific to 1.0 endpoints?
19:42:11 <dolphm> the identity service is basically an abstraction layer over existing, proprietary auth systems -- but the way users expect to authenticate varies wildly from deployment to deployment
19:42:55 <dolphm> so the UX needs to be entirely tailorable to any given deployment ... i don't think openstacksdk should tackle much more than the base case (username + password) and pluggability
19:43:13 <wchrisj_> dolphm: +1
19:43:17 <dtroyer> dolphm: +1
19:43:54 <dolphm> even token-based auth strikes me as out of scope for openstacksdk
19:44:41 <dtroyer> dolphm: at the high-level api, agreed…at the low-level, there needs to be a way to inject it
19:45:00 <dolphm> dtroyer: right, i'm more concerned about what is exposed to end users
19:45:24 <dolphm> dtroyer: it'll have to handle token refreshing, rescoping, etc so it's got to be available somewhere
19:46:21 <dtroyer> I'd love to focus on getting the low-level stuff fleshed out so we can start doing something…mixing discussions about high and low isn't being very productive so far
19:46:59 <briancurtin> not to totally end this current auth topic, but with 14 minutes left, any thoughts on the next steps after this current review is approved?
19:47:07 <dolphm> dtroyer: i don't want to commit to any high level stuff at this point :)
19:47:12 <bknudson> there's a couple of approaches -- focus on the low level and work your way up, for focus on the high-level and work your way down
19:47:40 <bknudson> I'd prefer to focus on the high level, since those are our use cases.
19:47:43 <briancurtin> #topic next steps and approaches
19:47:45 <Alex_Gaynor> briancurtin: I think the next step is expose an actual Client object
19:48:08 <dtroyer> bknudson: yup…but it's hard to road-test the high-level  without the low-level
19:48:46 <edleafe> Alex_Gaynor:  but we can'
19:48:50 <edleafe> can
19:48:50 <bknudson> dtroyer: it'll require implementing something ugly, but we can make direct requests and then flesh out the low level from there... keeping the high-level working thorough unit tests
19:48:55 <edleafe> tarrgggh
19:49:06 <edleafe> we can't call it 'client' - see: https://etherpad.openstack.org/p/sdk-glossary
19:49:19 <Alex_Gaynor> Connection, whatever.
19:49:37 <dtroyer> bknudson: then maybe we should just use keystoneclient as a stand-in low level rather than invent yet something else?
19:50:58 <bknudson> dtroyer: as long as it doesn't tie us into any high-level decisions then I'm fine with that. But http clients are not difficult to write.
19:51:22 <wchrisj_> This sounds a lot like what jamielennox: has suggested around the term Session
19:51:38 <bknudson> I'd like to see a definition of Session
19:51:47 <wchrisj_> or context
19:52:07 <bknudson> would a session be used by a single connection to a cloud? (i.e., one session - one cloud)
19:52:31 <briancurtin> bknudson: to kick things off "(proposed) a wrapper around requests.Session that adds OpenStack-specific things like logging and auth-header injections and re-authentication on token expiration" (not my words, from the etherpad)
19:52:37 <dtroyer> bknudson: yes, including specific user creds
19:53:46 <jamielennox> bknudson: yes, one session = one cloud using one auth
19:53:52 <edleafe> I've used 'context' to be a specific authed user for a service. From there, you can access clients/whatever for each service
19:54:21 <wchrisj_> See "context" definition in etherpad
19:54:31 <bknudson> briancurtin: that definition sounds good to me.
19:54:53 <dtroyer> context is what you would have multiple instance of to talk to multiple clouds, or as multiple users, at the same time
19:55:08 <edleafe> dtroyer: yes
19:57:28 <briancurtin> 3 min left, anything else to squeeze in?
19:59:04 <briancurtin> #endmeeting