19:01:40 <jnoller> #startmeeting Python-Openstacksdk
19:01:41 <openstack> Meeting started Wed Feb 19 19:01:40 2014 UTC and is due to finish in 60 minutes.  The chair is jnoller. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:44 <openstack> The meeting name has been set to 'python_openstacksdk'
19:02:03 <jnoller> Background: https://wiki.openstack.org/wiki/PythonOpenStackSDK
19:02:12 <jnoller> Current Agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK
19:02:13 <dhellmann> #link https://wiki.openstack.org/wiki/PythonOpenStackSDK
19:02:32 <jnoller> (thank you: I couldn't find the bot commands)
19:03:52 <jnoller> First Item, if you are here for the python-openstackSDK discussion, please state your name, and affiliation if any.
19:03:57 <jnoller> Jesse Noller, Rackspace
19:03:59 <dhellmann> o/ dreamhost
19:04:03 <dtroyer> Dean Troyer, Nebula
19:04:05 <briancurtin> Brian Curtin, Rackspace
19:04:06 <rgbkrk> Kyle Kelley, Rackspace
19:04:11 <bknudson> Brant Knudson, IBM
19:04:16 <wchrisj> Chris Johnson, HP
19:04:16 <Alex_Gaynor> Alex Gaynor, Rackspace (many other affiliations you may or may not care about :P)
19:04:18 <edleafe> Ed Leafe, Rackspace
19:04:44 <jamielennox> Jamie Lennox, Red Hat
19:04:56 <lbragstad> Lance Bragstad, IBM
19:04:58 <dhellmann> Doug Hellmann, DreamHost
19:05:19 <dolphm> o/, i just lurk
19:05:21 <markmcclain> Mark McClain, Yahoo
19:06:13 <jnoller> Okie doke
19:06:29 <redrobot> Douglas Mendizabal, Rackspace (mostly lurking as well)
19:06:36 <jnoller> Next Item is this: Feedback on the wiki / current state (open discussion)
19:06:44 <smashwilson> Ash Wilson, Rackspace (mostly here to lurk)
19:06:53 <dhellmann> #topic Feedback on the wiki / current state (open discussion)
19:06:56 <jnoller> So, does anyone want a brief summary / background of the problem we're trying to solve for
19:07:15 <jnoller> #topic Feedback on the wiki / current state (open discussion)
19:07:48 <dhellmann> I think I follow the idea, but I would like to make sure I understand the requirements as listed
19:07:51 <rgbkrk> There is a disconnect between users of openstack and developers/operators of openstack, and we need a unified, clean SDK that unites OpenStack.
19:08:04 <dhellmann> Specifically, the "Jargon free" statement.
19:08:17 <jnoller> In summary: This project aims to create a unified and clear software development toolkit that is clear, consistent and of high quality for developer consumers of openstack clouds.
19:08:40 <Alex_Gaynor> dhellmann: So, a big problem for consumers of OpenStack clouds is they don't know what a "Swift" or a "Glance" is. They know what "Object storage" or "Image storage" is though.
19:08:40 <jnoller> dhellmann: What's the question you had?
19:08:48 <dhellmann> In the CLI, we've avoided using the service names at all. Do we think the SDK will require using service names at all?
19:09:15 <dhellmann> For example, one doesn't say "openstack neutron do something for me" one says "openstack object action"
19:09:18 <edleafe> dhellmann: in the CLI the service name is the command. In an SDK it would be akin to a module name
19:09:30 <Alex_Gaynor> I don't necessarily think we'll need to, but if we do prefer "Compute" to "Nova".
19:09:35 <dtroyer> dhellmann: I've interpreted this as being the same thing we've done in OSC… no project names
19:09:36 <dhellmann> edleafe: right, but does the module need to be "compute" or would it be "server"?
19:09:47 <Alex_Gaynor> compute or server seem equally fine
19:09:50 <jnoller> I think using the service names (e.g.: swift vs. storage) should be aliased/hidden from end-users. When you want storage, you want storage.
19:09:53 <bknudson> dhellmann: what if the same object + action exists on 2 different services? (e.g., nova network and neutron
19:09:55 <dtroyer> there's a difference between objects and API names
19:10:04 <edleafe> dhellmann: it could be either, but certainly not 'nova'
19:10:12 <dhellmann> yeah, I agree, we should not use code names
19:10:16 <jnoller> Id look at it as namespacing of the clients
19:10:31 <jnoller> from openstack.services.compute import Blah for example
19:10:33 <dhellmann> I'm trying to suggest that we talk about the actions the cloud can take and the objects, rather than any implementation details of those services
19:10:46 <Alex_Gaynor> ==dhellmann
19:10:47 <dhellmann> so from openstack.server import something
19:11:03 <jamielennox> jnoller: i've come around a little on the all-in-one approach, but is that that much better than from keystoneclient import ?
19:11:04 <jnoller> #idea I'm trying to suggest that we talk about the actions the cloud can take and the objects, rather than any implementation details of those services dhellmann
19:11:09 <edleafe> dhellmann: iow, create_server() rather than server.create() ?
19:11:13 <dhellmann> in the case where an action can be handled by more than one service, the client needs to figure out which to use
19:11:30 <dhellmann> if neutron is in the service catalog, use that, otherwise, use nova's api
19:11:33 <dolphm> jamielennox: import keystoneclient as identityclient  # namespace problem solved ;)
19:11:34 <jnoller> jamielennox: Yes: it is as its consistent namespacing and doesn't rely on the fragility of python's packaging system
19:11:43 <dhellmann> edleafe:  no, server.create() is great, but no "compute" module in the public API
19:11:47 <jamielennox> dolphm: ++
19:12:07 <Alex_Gaynor> The issue here is not namespacing, it's that no actual user knows or cares what keystone is.
19:12:13 <jnoller> +1
19:12:15 <briancurtin> yes
19:12:17 <dhellmann> Alex_Gaynor: +1
19:12:20 <mfer> +1
19:12:23 <jnoller> and they don't want to install it
19:12:24 <dhellmann> but they also don't know what "identity" is
19:12:27 <jamielennox> jnoller: i agree that the clients need cleaning up and some consistency, i'm not sure we should work around pypis faults
19:12:29 <dhellmann> they know "I want to login"
19:12:31 <edleafe> dhellmann: so no outside knowledge of endpoints?
19:12:44 <dhellmann> edleafe: if we can avoid it, yes
19:12:47 <dolphm> Alex_Gaynor: right, i don't care either; i'm all on board with presenting high level operations to end users
19:12:52 <edleafe> ok, got it
19:13:06 <dhellmann> edleafe: maybe an API for saying "I want to talk to a specific region, give me a handle to that region"
19:13:06 <dolphm> edleafe: ++
19:13:14 <edleafe> so no separate clients at all
19:13:19 <dhellmann> edleafe: right
19:13:21 <jnoller> jamielennox: We've gotten this complaint from *most* users trying to use openstack clouds, big and small. They do not want to developer against 22 packages with varying dependencies and namespaces and client names / behaviors.
19:13:28 <edleafe> just a single client that should know how to do what you want
19:13:38 <dhellmann> edleafe: right
19:13:39 <chris_johnson> +1
19:13:46 <dhellmann> that does raise the question of where to stop, though
19:13:50 <Alex_Gaynor> ==edleafe; and maybe it doesn't have every single method on it, you can get child clients or something, but one entry point
19:13:57 <dhellmann> for example, not all projects are integrated -- do they belong in the sdk or not?
19:14:04 <jamielennox> dhellmann: ++
19:14:16 <Alex_Gaynor> I think "integrated projects" is a reasonable initial criterion.
19:14:17 <jamielennox> jnoller: i don't disagree with the umbrella project
19:14:19 <jnoller> dhellmann: For non integrated projects the plugin system needs to work for it
19:14:25 <dhellmann> but I think starting out with the integrated projects will give us plenty to do, so we can answer that question later
19:14:31 <edleafe> what about multiple region support?
19:14:32 <Alex_Gaynor> ==dhellmann
19:14:38 <jamielennox> jnoller: so back to core and non-core plugins?
19:14:43 <dhellmann> jnoller: there's a specific prohibition against an extension system in the requirements
19:14:56 <dhellmann> jamielennox: I think of it as a matter of priority
19:15:00 <jnoller> dhellmann: No, there's a restriction against using setuptools
19:15:02 <jamielennox> edleafe: i'm sure that will be handled
19:15:32 <dolphm> i read the wiki page as "pluggability is mandatory"
19:15:33 <briancurtin> dhellmann: that was my intention (re: priority, core/non-core)
19:15:34 <dhellmann> jnoller: that's a conversation for the mailing list then
19:15:59 <jnoller> Specifically using setup tools as the plugin / extension mechanism causes daily support pain, installation problems and other things I think we can easily avoid
19:16:27 <bknudson> is the goal to eventually get rid of the python-*clients ?
19:16:27 <dhellmann> jnoller: I'd like to hear more about the details of those issues on the ML
19:16:38 <bknudson> I don't want to support 2 versions of python-keystoneclient
19:16:40 <Alex_Gaynor> bknudson: I think it should be.
19:16:41 <jamielennox> jnoller: it is also better than writing another one
19:16:45 <dhellmann> jnoller: I don't want to derail the entire meeting with the technical issues
19:16:56 <bknudson> then I think a requirement is that it has to implement everything the *clients do.
19:17:04 <briancurtin> bknudson: i don't know over what timespan, but yes
19:17:07 <jnoller> bknudson: I would like the python-* clients to eventually use this as their backend if they wish to keep them around
19:17:18 <edleafe> bknudson: the idea is to separate the python module from the CLI
19:17:21 <dhellmann> I also think we need to be careful with the next requirement, of allowing anyone to drop in extensions
19:17:29 <edleafe> the CLIs could then use the python module
19:17:32 <dolphm> briancurtin: it's taken 1.5 years to get any sort of adoption around python-openstackclient, so i wouldn't expect anything very quickly
19:17:40 <dhellmann> we are, as a community, working to a goal of interoperability
19:17:42 <edleafe> developers won't need to import all the CLI stuff for their apps
19:17:57 <dhellmann> vendor and cloud-specific extensions seem to be going in the opposite direction
19:17:58 <rdodev> belated intro (sorry!) Ruben Orduz, Rackspace
19:17:59 <dolphm> edleafe: that's already being solved with python-openstackclient
19:18:00 <jnoller> dolphm: Do you mean internal adoption or user adoption
19:18:07 <jamielennox> edleafe: we are working towards that already
19:18:10 <dolphm> jnoller: user
19:18:52 <dhellmann> so I think we should encourage those extensions to be implemented as wrappers, to make it clear they are not part of the client itself
19:19:01 <jnoller> dolphm: I'd say adoption is a matter of the vendors making it the recommended path for developers and users
19:19:09 <edleafe> jamielennox: but each python-*client re-implements a lot of stuff
19:19:17 <jamielennox> edleafe: preaching to the choir
19:19:39 <edleafe> jamielennox: understood. Just 'splaining for everyone else
19:19:51 <jnoller> dhellmann: Vendor extensions - specifically differences in say, auth, are probably never going away
19:20:06 <dhellmann> auth may be a separate question, I see utility in that
19:20:23 <jnoller> dhellmann: the SDK abstracts those differences so that END USERS get the experience of interop
19:20:23 <dhellmann> but APIs that are not part of OpenStack for other purposes shouldn't blend in with the client library
19:20:30 <bknudson> an auth plugin doesn't have to extend the api if you can pass it in.
19:20:32 <jnoller> while vendors can fulfill business needs
19:20:54 <dhellmann> bknudson: sure, auth may be an exception
19:21:02 <jnoller> There's also the concrete example: CDNs
19:21:23 <edleafe> jnoller: exactly
19:21:40 <dhellmann> is CDN a feature of openstack?
19:21:56 <jnoller> the two major openstack public clouds have CDN support. From a consumer level - I don't care about the implementation of the API, nor do I care about who the host is. I just want to have my "openstack thingie work with the CDN capability if it is on"
19:22:05 <bknudson> how do you verify mocks/stubs? (other than disable as a mock)
19:22:11 <edleafe> dhellmann: no, but it's a feature that many business want/need
19:22:30 <dhellmann> well, that's fine -- as openstack developers we should focus on the features of openstack, though
19:22:40 <Alex_Gaynor> You don't verify a mock/stub, you verify a fake!
19:22:45 <edleafe> dhellmann: the OpenStack SDK will not support it.
19:22:49 <Alex_Gaynor> http://martinfowler.com/articles/mocksArentStubs.html
19:22:56 <edleafe> But vendor subclasses might
19:22:57 <dhellmann> edleafe: what I want to avoid is "from openstack import cdn"
19:23:03 <jamielennox> jnoller: right, but on the other hand as a developer i do care about the api. You need to provide that as well
19:23:08 <dhellmann> because if CDN isn't a feature of openstack, it shouldn't look like it is from the API
19:23:11 <bknudson> Alex_Gaynor: OK OK! how do you verify a fake, other than not fake?
19:23:26 <jnoller> dhellmann: I completely agree! Vendor extensions need to come from and be maintained by the vendors, but we should not exclude the potential for them in the design
19:23:34 <mfer> edleafe and the end of the day, the goal is to support end user developers, right? to make it easy for their real world and practical development
19:23:35 <jnoller> jamielennox: Which API
19:23:42 <Alex_Gaynor> bknudson: you test it like any other code! In this context a fake ObjectStroage client would just put files in a dic, instead of doing HTTP requests
19:23:42 <edleafe> dhellmann: right, but the SDK should be extensible
19:23:52 <dhellmann> jnoller: as long as it is not possible for users to be confused when using it, hence the suggestion to use a vendor-specific wrapper
19:23:54 <jamielennox> jnoller: identity.v3.user.create()
19:24:17 <dhellmann> from vendor import wrapper; from openstack import client; from provider import auth; c = wrapper(client(auth()))
19:24:18 <jamielennox> jnoller: we are a long way off overarching things like CDN
19:24:32 <jnoller> dhellmann: vendor specific wrappers become vendor specific forks
19:24:35 <dolphm> jamielennox: openstack.create_user()
19:24:38 <bknudson> seems like a vendor could just provide their own api... why does it need to be in openstack api?
19:24:41 <edleafe> dhellmann: I've done just that to add Rackspace CDN stuff to my base OpenStack object storage client
19:24:46 <dhellmann> jnoller: I have no interest in supporting vendor-specific APIs in the shared client
19:24:47 <mfer> a wrapper is just one way to implement extensions
19:24:48 <jamielennox> dolphm: that namespace is going to get very busy
19:25:00 <bknudson> jamielennox: openstack.user.create()
19:25:02 <jamielennox> dolphm: also there are times i care about v2 vs v3
19:25:02 <edleafe> bknudson: because apps written to a vendor API would not be portable
19:25:08 <dhellmann> mfer: the difference is no user would be confused that the wrapper is part of the client itself
19:25:10 <briancurtin> bingo
19:25:12 <dolphm> jamielennox: you shouldn't
19:25:16 <dolphm> jamielennox: as an end user
19:25:31 <dhellmann> mfer: and it leaves open the ability of openstack to choose a different API without confusing the user, depending on which plugins are installed in their SDK
19:25:34 <glyph> bknudson, Alex_Gaynor: A good way to think about "verified fakes" is to think about "fake" as meaning "introspectable, in-memory implementation" rather than "not real implementation"
19:25:41 <jamielennox> dolphm: if this is going to replace the various -clients then it will probably need to
19:25:58 <mfer> dhellmann and what about developers who write apps against multiple openstack installs. those with and without extensions
19:26:06 <dolphm> jamielennox: it needs to care about API versions, sure. but end users should not
19:26:14 <mfer> real world practicality for end users is of interest to me
19:26:15 <glyph> bknudson: one of the best examples of "verified fake" as a pattern is SQLite's ":memory:" database connection type; it's tested just as well as the one that writes to files.
19:26:31 <dhellmann> mfer: how would a wrapper be any different than a plugin? if both clouds don't support the feature in the same way, the code isn't going to be portable
19:26:49 <jamielennox> dolphm: the way i see it is you still need support in there somewhere for each api version, which is wrapped in an api agnostic one
19:27:00 <dhellmann> if rackspace and hp can agree on a cdn API, then they can share a wrapper library
19:27:00 <dolphm> jamielennox: right
19:27:10 <dolphm> dhellmann: ++
19:27:21 <dhellmann> otherwise their shared users aren't going to have the same experience anyway, and we shouldn't make it appear that it is openstack's fault
19:27:50 <jnoller> dolphm jamielennox the abstraction *most* users would use != remove the ability for advanced users to do: from openstack.services.auth import v2client and manipulate things directly. We won't actively expose those interfaces in the high level abstractions, but the lower levels will exist. The best abstraction is leaky
19:27:53 <rgbkrk> dhellmann ++
19:27:57 <mfer> dhellmann there are ways to have a plugin work well and then have that cleanly work in applications. i know because i've done it
19:28:06 <edleafe> dhellmann: that's why specific vendor imports are preferable over setuptools entry points
19:28:11 <jnoller> dhellmann: the high level abstraction would be.
19:28:24 <jamielennox> jnoller: ++
19:28:32 <rgbkrk> jnoller++
19:28:33 <dhellmann> jnoller: if this is going to be an openstack sdk, it should be an openstack sdk and not an HP & Rackspace sdk
19:28:54 <dhellmann> I just want users to be clear about what is and is not part of openstack as a whole
19:29:09 <jnoller> dhellmann: I'm advocating for Openstack first, but vendor extensions are something which affect users day to day
19:29:21 <edleafe> dhellmann: I don't imagine that the vendor-specific stuff would live in this project
19:29:22 <jnoller> dhellmann: we should *plan* for it, and architect for it
19:29:23 <mfer> dhellmann note, it's not just HP and Rackspace doing extensions. I'm aware of others
19:29:42 <dhellmann> mfer: sure, that's just the example that was raise
19:29:52 <dhellmann> it's likely Dreamhost will offer extra services, too
19:29:55 <mfer> architect to enable users to use extensions
19:30:11 <dhellmann> architect to ensure users know when they are using an extension, and when not
19:30:13 <mfer> I hope a goal is to endable end user developers to be successful
19:30:24 <mfer> dhellmann yes.
19:30:35 <jnoller> Vendor extensions should be maintained by the vendors: but we need to have a guide and set of common abstractions to show them what to check in, where, how to plugin, where and how to cooperate on high level abstractions.
19:30:37 <edleafe> in this discussion, user == developer
19:30:53 <dhellmann> edleafe: yes
19:30:55 <jnoller> "architect to ensure users know when they are using an extension, and when not" +1000000000 dhellmann
19:31:16 <mfer> imagine 3 vendors do extensions in a different manner. if you plan for it they can all do it the same way. one way is better for users
19:31:21 <jnoller> It should be clear. Let's call it "extension" ;)
19:31:32 <edleafe> that's why importing a vendor module for an extension is preferred over setuptools-type extensions
19:31:47 <dhellmann> edleafe: I'm not sure what that looks like in practice
19:32:08 <jnoller> Ok
19:32:22 <mfer> import a vendor module that does all the things... or register a vendor extension with the openstack module?
19:32:48 <Alex_Gaynor> people importing modules is clearly preferably to mutating global state
19:33:03 <edleafe> dhellmann: ok, the identity example I have would be something like: from rs_identity import RackspaceIdentity
19:33:04 <jnoller> So can I call time out for a second and say it's clear we need to flesh out a wiki page about vendor extension requirements / standards and how they would live / register into the namespace of say, openstack.extensions.*
19:33:22 <edleafe> It's clear that you're not using standard OpenStack identity
19:33:24 <dhellmann> edleafe: ok, sure, that's similar to the generic example I mentioned earlier
19:33:29 <edleafe> yep
19:33:30 <jnoller> That's a concrete action item for a wiki page / blue print
19:33:31 <dhellmann> and that's what I want
19:33:40 <briancurtin> jnoller noted
19:33:48 <jnoller> briancurtin: thanks!
19:34:31 <edleafe> dhellmann: and the Rackspace class follows the same structure (methods/atts) as the base OpenStack class
19:34:51 <dhellmann> edleafe: makes sense
19:35:07 <jnoller> #action it's clear we need to flesh out a wiki page about vendor extension requirements / standards and how they would live / register into the namespace of say, openstack.extensions.*
19:35:46 <Alex_Gaynor> Err, why would they live in the openstack namespace at all?
19:35:49 <jnoller> #action briancurtin wiki page outlining vendor extension plugins/namespacing/loading and abstractions
19:35:50 <dhellmann> are there any pages other than https://wiki.openstack.org/wiki/PythonOpenStackSDK that are relevant?
19:36:01 <dhellmann> I want to make sure I've read everything I should...
19:36:05 <edleafe> Alex_Gaynor: +1
19:36:11 <dhellmann> it wasn't clear if https://wiki.openstack.org/wiki/SDK-Development was part of this?
19:36:17 <jnoller> It is
19:36:17 <dhellmann> or https://wiki.openstack.org/wiki/SDKs as well
19:36:20 <dhellmann> ok
19:36:32 <jnoller> dhellmann: I meant to #link to https://wiki.openstack.org/wiki/SDK-Development
19:36:34 <dhellmann> so one point of feedback is to collect all of those under a namespace
19:36:47 <dhellmann> it's possible to have slashes in the URLs, for example, so we could have everything live under that SDK page
19:36:56 <jnoller> naming things is hard
19:37:03 <dhellmann> also, making sure the top level page links to the others would help with discoverability
19:37:19 <jnoller> Who wants to fix the wiki namespacing :)
19:37:20 <briancurtin> i can do some rearranging
19:37:23 <dhellmann> searching brought up those few pages, so that worked, but obviously I wasn't sure they were all together
19:37:31 <dhellmann> the wiki is full of old project notes :-)
19:37:34 <jnoller> #action briancurtin fix wiki namespaces / cleaning things up
19:37:40 <dhellmann> briancurtin: cool, thanks
19:37:43 <jnoller> Ok
19:38:07 <jnoller> #topic State of blueprints / API strawman
19:38:35 <briancurtin> as for blueprints, these are super high level and contain some thoughts, but no issues have been filed, and we haven't gone that deep yet: https://blueprints.launchpad.net/unifiedsdk
19:38:57 <briancurtin> (first time writing blue prints, comments/criticism more than welcome)
19:39:12 <jnoller> Yes, we've all held off on deep blue prints until we could discuss this as a community
19:39:23 <jnoller> Same with so much code
19:39:26 * dhellmann brings up one more pedantic point
19:39:37 <dtroyer> I did throw some stuff into https://blueprints.launchpad.net/unifiedsdk/+spec/rest-client that reflects some of the work already underway elsewhere
19:39:40 <dhellmann> should that be "openstack-sdk" or something? launchpad is used for lots of non-openstack projects
19:39:55 <dhellmann> although I guess there could be a trademark issue
19:39:59 <jnoller> dhellmann: yeah, the name changed *after* I made the launchpad
19:40:04 <dhellmann> that's why we have code names for the other projects
19:40:10 <dhellmann> jnoller: ok
19:40:16 <mfer> i'd like it to be openstack-sdk-python ... a reusable pattern with the language on the end
19:40:18 <dhellmann> it's fine as it is, we can fix it when we incubate
19:40:21 <mfer> this is what developers are used to
19:40:22 <jnoller> #action jollier rename launchpad project
19:40:47 <dhellmann> we should also talk about who is on the drivers team, and eventually the core review team
19:40:55 <jnoller> mfer: Which developers? Python devs for AWS use boto
19:41:15 <jnoller> mfer: how widespread is that naming pattern?
19:41:56 <dhellmann> jnoller: could you also change the python-osdk-team to allow people to request membership?
19:42:12 <dhellmann> I think that's called a "moderated team"
19:42:19 <jnoller> dhellmann: can you show me how offline? I deleted the team the last time I tried ;)
19:42:26 <dhellmann> haha, I'll try
19:42:35 <jnoller> Ok
19:42:42 <mfer> aws and azure use it. google calls it a google cloud sdk but doesn't have multiple languages
19:43:26 <jnoller> aws is inconsistent on the names though, I double checked they vary - but we should have a cross-language standard for naming
19:43:31 <dhellmann> so aside from those nits, I think there is a lot of good info in the wiki and clearly a lot of thought has gone into this
19:43:41 <jnoller> dhellmann: thanks!
19:43:44 <jnoller> ok
19:44:08 <briancurtin> dhellmann: as for blueprints, do you have any thought as to direction to take them or do they look ok for the current time/state of the project?
19:44:27 <briancurtin> i can't tell if they're light or just right for where we're at
19:44:35 <dhellmann> briancurtin: I didn't find the launchpad project until you linked it above, so I haven't had a chance to review those yet
19:44:40 <dhellmann> I will, before our next meeting
19:44:43 <jnoller> before everything goes crazy: please let me know if you want to work on blueprints. I'd like to get a sniff-test for two proposed end-user APIs
19:44:45 <dolphm> briancurtin: they need content :)
19:44:58 <jnoller> if you all look at:
19:44:58 <jnoller> https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman
19:45:02 <jnoller> #link https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman
19:45:22 <jnoller> We'll start with the API / structure Alex proposed: Alex_Gaynor you're up
19:46:16 <Alex_Gaynor> So, I have somewhat limited opinions on the overall public API, but I want to discuss two particular points with respect to implementation strategy:
19:46:16 <Alex_Gaynor> * Doing all auth using the API hooks in the HTTP layer
19:46:16 <Alex_Gaynor> * Seperating compute from IO
19:46:21 <Alex_Gaynor> What do these mean and why?
19:46:39 <Alex_Gaynor> The first means we can truly write these as "Just HTTP requests", which gives clean seperation.
19:46:46 <rgbkrk> What holds us back from doing direct auth or simplifying auth? I feel like this is the major hangup everytime someone ends up on a support call.
19:47:05 <Alex_Gaynor> The latter makes this far easier to test, and makes it more reusable if you change the HTTP layer.
19:47:12 <dhellmann> I don't understand the issue with auth?
19:47:12 <rgbkrk> Are we really supporting swauth here?
19:47:13 <dolphm> briancurtin: it'd be nice if these "API mockups" were actually in review as WIP for final docs
19:47:21 <bknudson> jamielennox has been doing a lot of work on auth plugins in keystoneclient.
19:47:30 <Alex_Gaynor> You can see if you look in client.py that there's a seperation between the representation of HTTP requests and their execution.
19:47:34 <jamielennox> right, i would realllly like you to look through all the plugin stuff we have
19:47:52 <dolphm> jamielennox: ++
19:48:33 <briancurtin> dolphm: good idea
19:48:47 <bknudson> so if there's a difference between v2 and v3 compute API -- how does the python API handle that?
19:48:51 <rgbkrk> Would the point here in having multiple auths be where the extensions come in to make it simpler for each provider?
19:49:03 <bknudson> e.g., maybe compute v3 gives you a task handle for a boot request
19:49:16 <dhellmann> Alex_Gaynor: that seems like a good idea on the face of it, but I wonder if some request types (uploading to glance and swift) might need tighter interaction with the execution?
19:49:42 <bknudson> these are things that it would be nice if the API could hide, but not sure if that's possible.
19:49:44 <dolphm> bknudson: that would be a backwards compatible addition to the python sdk if a v3 compute endpoint was available
19:49:49 <dhellmann> Alex_Gaynor: that may just be a matter of ensuring the  request class has a rich enough API, though
19:50:25 <Alex_Gaynor> dhellmann: Upload seems straightforward, the abstract definition of a request just needs to include a file-like/iterable/etc.
19:50:45 <Alex_Gaynor> for body that is
19:51:03 <dhellmann> dolphm: so if the way the caller interacts with the API is completely different, it should be a separate API in the client?
19:51:23 <jnoller> So yeah, let's focus on Alex's mock first and his points (readme.rst "import io" example) and https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/client.py
19:51:23 <dhellmann> Alex_Gaynor: yeah, I think that works, I just wanted to point out that not all request types are equal
19:51:54 <dhellmann> we've already talked about whether it should be client.compute.list_images() or client.images.list()
19:52:08 <Alex_Gaynor> I don't really care which we pick between those two :-)
19:52:23 <dolphm> Alex_Gaynor: they're quite different!
19:52:26 <dhellmann> I obviously prefer the latter
19:52:31 <dolphm> dhellmann: ++
19:52:34 <bknudson> Let's got with the latter
19:52:35 <chris_johnson> ++
19:52:43 <rgbkrk> dhellmann++
19:52:47 <dolphm> i just don't want 'compute' in there
19:52:55 <bknudson> but why have compute? aren't images in the image source?
19:53:03 <bknudson> images.list()
19:53:06 <dhellmann> it makes naming things a little challenging, but we can look at what the cli did for some of the object names (it would be nice to be consistent where that makes sense)
19:53:06 <dolphm> client.list_images() vs client.images.list()  are both identical to me
19:53:16 <edleafe> dolphm: aren't there cinder images as well?
19:53:30 <glyph> dhellmann: I'm very much on board with Alex_Gaynor's recommendation about separating request representation from I/O; basically that's the reason I'm here :-).  All request types may not be equal, but all requests are requests and as "request" is a noun, should have an associated type :)
19:53:31 <dhellmann> dolphm: the difference will come out in how the docs read
19:53:43 <dhellmann> if it is client.list_images() then we have a HUGE flat API
19:53:55 <dolphm> dhellmann: e.g. openstack --help
19:53:55 <rgbkrk> yuck
19:53:55 <dhellmann> if it is client.images.list() then we have some namespacing, and all of the image-related methods are together in the docs
19:54:15 <jnoller> Yeah, I'd really prefer NOT to have ONE GIANT NAMESPACE
19:54:20 <jnoller> it's confusing as all get-out
19:54:29 <dhellmann> dolphm: right, it's the same reason I suggested "object verb" for the CLI instead of "verb object"
19:54:30 <jamielennox> dhellmann: as mentioned though there is some contention around words like images
19:54:35 <rgbkrk> Assuming there's only one context for images, ever.
19:54:44 <dolphm> fwiw openstack --help: http://pasteraw.com/t01pe2jm4rqzlwvlqrelulrzfswr2ik
19:54:45 <dhellmann> jamielennox: images are a glance thing, where is the contention?
19:55:17 <rgbkrk> They make sense to someone used to working with raw disk dumps as images, less to someone is more of a web dev
19:55:17 <edleafe> dhellmann: cinder uses images, too
19:55:28 <rgbkrk> as far as nomenclature is concerned
19:55:44 <dhellmann> rgbkrk: we're not going to get away from terminology overload
19:55:52 <jnoller> this is why I think we need the official service names contain the caller methods
19:55:57 <glyph> dhellmann: IMHO, client.list_images and client.images.list are _both_ wrong :)
19:56:01 <dhellmann> edleafe: the cinder-implemented operations for images would need to be named differently, I guess
19:56:07 <dhellmann> glyph: alternate?
19:56:11 <dolphm> jnoller: like .identity. ?
19:56:18 <edleafe> dhellmann: sure - just pointing out name overloading
19:56:21 <jnoller> services.blockstorage.list_block() gives me context as a developer
19:56:23 <rgbkrk> That was my thought on what the contention is, from supporting web devs using our services.
19:56:31 <glyph> dhellmann: As a very basic straw man, ImagesClient(client).list_images()
19:56:32 <dolphm> glyph: what's your alternative suggestion?
19:56:37 * dolphm spoke too soon
19:56:55 <edleafe> which is why I don't think we'll get 100% away from services in the namespace.
19:56:56 <dhellmann> glyph: I don't see how that's substantially different, except that in my example the main client may implicitly create an ImagesClient
19:56:57 <jamielennox> glyph: hey i'm writing that design in keystoneclient now
19:57:19 <dolphm> glyph: yeah, that's not so different than what we're providing today with the existing libraries
19:57:22 <dhellmann> edleafe: what operations does cinder support on images?
19:57:25 <dolphm> jamielennox: ++
19:57:28 <chris_johnson> dhellmann: Implicit in the approach of client.images.list() is the idea of having a collection named images that has operations on it - more OO. It's a good thing IMO
19:57:29 <jnoller> dhellmann: YES the main client could implicitly interrogate the service catalog and create the sub clients
19:57:59 <edleafe> dhellmann: create, delete, and use as base for a new volume
19:58:01 <jamielennox> jnoller: that's getting awfully automagical
19:58:08 <dhellmann> jnoller: it could, or it could just create them when the code calls for it
19:58:31 <dolphm> jamielennox: is that not exactly what you're providing the tooling for?
19:58:35 <jnoller> jamielennox: Users don't care about authentication or service catalogs. They want to "make server start from my application"
19:58:40 <dtroyer> sounds like a ClientManager to me…we're already doing that
19:58:43 <dhellmann> edleafe: maybe those are "volume images"
19:58:46 <dhellmann> dtroyer: right
19:58:52 <jnoller> ok
19:58:56 <dhellmann> edleafe: i.e., different object type
19:58:58 <jnoller> we're just about out of time
19:59:01 <jnoller> question
19:59:02 <dhellmann> but we can work out those details with more thought
19:59:03 <jamielennox> dolphm: i don't like the idea of attributes sometimes available and sometimes not
19:59:21 <jamielennox> i would much prefer the error after i've called something
19:59:25 <edleafe> dhellmann: yep, in my strawman it's volume.create_image()
19:59:28 <dhellmann> jamielennox: +1 - make the object on demand, and let the api call fail if the service isn't there
19:59:33 <jnoller> which of the HIGH level APIs on https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/README.rst makes more logical sense to you
19:59:38 <jnoller> there's two there.
19:59:39 <dhellmann> edleafe: volume_images.create()
20:00:07 <edleafe> dhellmann: no, since you're acting on the volume
20:00:16 <edleafe> creating an image of that volume
20:00:16 <rgbkrk> the first
20:00:24 <jamielennox> jnoller: the second one bundles the auth with the transport layer - don't do that
20:00:32 <dhellmann> edleafe: ah, didn't get that
20:00:36 <dolphm> jnoller: an hour is up
20:00:37 <glyph> dhellmann: The difference is that in your example the main client needs to know how to implicitly create ImagesClient, there needs to be a registry somewhere, and that configurable run-time registry can change what attributes are on your object, and hence what API contract you can expect, making the behavior of subsequent executions of the same code unpredictable in the face of intermittent outages
20:00:41 <jnoller> #action jollier "note make the object on demand, and let the api call fail if the service isn't there"
20:00:54 <dhellmann> jnoller or Alex_Gaynor : could you describe the difference
20:00:59 <rgbkrk> I don't like the list_image
20:01:11 <dtroyer> glyph: welcome to OpenStack versioned APIs
20:01:19 <rgbkrk> whoops
20:01:25 <dhellmann> glyph: well, that gets back to the original question of what should be included, only OpenStack features or any plugins
20:01:40 <jamielennox> jnoller: on an administrative note can we make these meetings one day before - it's probably the difference in me being able to attend
20:01:41 <dhellmann> glyph: because if it's only OpenStack features, then the main client can just import the classes it needs without a registry
20:02:09 <jnoller> jamielennox: I made it a week? before
20:02:12 <dhellmann> dtroyer: good point, I don't see versioning exposed anywhere, should it be?
20:02:19 <Alex_Gaynor> I think glyph's point is that if people create ImageClient themselves, it obviates the need for a distiction
20:02:20 <edleafe> we're over time and haven't really discussed the different approaches, or how they can be combined. How about review between now and next week?
20:02:26 <jamielennox> jnoller: i meant the start time - 24 hours
20:02:28 <Alex_Gaynor> there's simply stuff you import from openstack and stuff you import from somewhere else
20:02:29 <dtroyer> dhellmann: once we know how to do it, yes
20:02:39 <edleafe> And then discuss next meeting?
20:02:40 <jamielennox> that buts it up against keystone
20:02:49 <rgbkrk> The only annoyance about failing if a service isn't there is that you have to try each operation to see what your provider supports (in case their docs don't list it somehow).
20:02:54 <dhellmann> edleafe: good idea
20:02:55 <jnoller> jamielennox: yeah, this was based on the doodle: I'm email a new one and we'll pick an official cadence/time
20:03:31 <jnoller> Yeah, we're over time: what's the best way to flesh out the API and get reviews on them: check them in, or blueprint, or wiki?
20:03:49 <dhellmann> I'd like to see a blueprint and a ML discussion
20:03:53 <dhellmann> do we have a git repo?
20:04:01 <jnoller> yeah, I linked to it
20:04:07 <jnoller> https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman
20:04:07 <dhellmann> ok, I'll read the logs
20:04:08 <briancurtin> https://github.com/stackforge/python-openstacksdk
20:04:08 <jamielennox> jnoller: i'd prefer some wiki or blueprints before we write any code - testing or not
20:04:16 <dhellmann> oh, that one, ok
20:04:22 <dhellmann> I didn't even read the URL, I just clicked it
20:04:25 * dhellmann is too trusting
20:04:57 <jnoller> jamielennox: have a link to a BP that walks through a high level API and then underlying architecture?
20:05:12 <jnoller> jamielennox: It's helps us newbs do some big design up front ;)
20:05:35 <jamielennox> jnoller: not sure it exists - but this is fairly ambitious so we might need a first
20:05:59 <jnoller> #action Alex_Gaynor Flesh out your underlying http transport separation example documented on the wiki / blueprints
20:06:11 <jamielennox> let's move back to -sdks at least
20:06:22 <jnoller> Ok
20:07:03 <jnoller> Thank you everyone, I mean it - it's really helpful to hear from everyone. We want to do this for the benefit of openstack** so it's good to have all these perspectives!
20:07:09 <dhellmann> ++
20:07:26 <chris_johnson> Thanks jnoller:
20:07:31 <jnoller> #endmeeting