19:01:40 #startmeeting Python-Openstacksdk 19:01:41 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:44 The meeting name has been set to 'python_openstacksdk' 19:02:03 Background: https://wiki.openstack.org/wiki/PythonOpenStackSDK 19:02:12 Current Agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK 19:02:13 #link https://wiki.openstack.org/wiki/PythonOpenStackSDK 19:02:32 (thank you: I couldn't find the bot commands) 19:03:52 First Item, if you are here for the python-openstackSDK discussion, please state your name, and affiliation if any. 19:03:57 Jesse Noller, Rackspace 19:03:59 o/ dreamhost 19:04:03 Dean Troyer, Nebula 19:04:05 Brian Curtin, Rackspace 19:04:06 Kyle Kelley, Rackspace 19:04:11 Brant Knudson, IBM 19:04:16 Chris Johnson, HP 19:04:16 Alex Gaynor, Rackspace (many other affiliations you may or may not care about :P) 19:04:18 Ed Leafe, Rackspace 19:04:44 Jamie Lennox, Red Hat 19:04:56 Lance Bragstad, IBM 19:04:58 Doug Hellmann, DreamHost 19:05:19 o/, i just lurk 19:05:21 Mark McClain, Yahoo 19:06:13 Okie doke 19:06:29 Douglas Mendizabal, Rackspace (mostly lurking as well) 19:06:36 Next Item is this: Feedback on the wiki / current state (open discussion) 19:06:44 Ash Wilson, Rackspace (mostly here to lurk) 19:06:53 #topic Feedback on the wiki / current state (open discussion) 19:06:56 So, does anyone want a brief summary / background of the problem we're trying to solve for 19:07:15 #topic Feedback on the wiki / current state (open discussion) 19:07:48 I think I follow the idea, but I would like to make sure I understand the requirements as listed 19:07:51 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 Specifically, the "Jargon free" statement. 19:08:17 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 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 dhellmann: What's the question you had? 19:08:48 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 For example, one doesn't say "openstack neutron do something for me" one says "openstack object action" 19:09:18 dhellmann: in the CLI the service name is the command. In an SDK it would be akin to a module name 19:09:30 I don't necessarily think we'll need to, but if we do prefer "Compute" to "Nova". 19:09:35 dhellmann: I've interpreted this as being the same thing we've done in OSC… no project names 19:09:36 edleafe: right, but does the module need to be "compute" or would it be "server"? 19:09:47 compute or server seem equally fine 19:09:50 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 dhellmann: what if the same object + action exists on 2 different services? (e.g., nova network and neutron 19:09:55 there's a difference between objects and API names 19:10:04 dhellmann: it could be either, but certainly not 'nova' 19:10:12 yeah, I agree, we should not use code names 19:10:16 Id look at it as namespacing of the clients 19:10:31 from openstack.services.compute import Blah for example 19:10:33 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 ==dhellmann 19:10:47 so from openstack.server import something 19:11:03 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 #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 dhellmann: iow, create_server() rather than server.create() ? 19:11:13 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 if neutron is in the service catalog, use that, otherwise, use nova's api 19:11:33 jamielennox: import keystoneclient as identityclient # namespace problem solved ;) 19:11:34 jamielennox: Yes: it is as its consistent namespacing and doesn't rely on the fragility of python's packaging system 19:11:43 edleafe: no, server.create() is great, but no "compute" module in the public API 19:11:47 dolphm: ++ 19:12:07 The issue here is not namespacing, it's that no actual user knows or cares what keystone is. 19:12:13 +1 19:12:15 yes 19:12:17 Alex_Gaynor: +1 19:12:20 +1 19:12:23 and they don't want to install it 19:12:24 but they also don't know what "identity" is 19:12:27 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 they know "I want to login" 19:12:31 dhellmann: so no outside knowledge of endpoints? 19:12:44 edleafe: if we can avoid it, yes 19:12:47 Alex_Gaynor: right, i don't care either; i'm all on board with presenting high level operations to end users 19:12:52 ok, got it 19:13:06 edleafe: maybe an API for saying "I want to talk to a specific region, give me a handle to that region" 19:13:06 edleafe: ++ 19:13:14 so no separate clients at all 19:13:19 edleafe: right 19:13:21 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 just a single client that should know how to do what you want 19:13:38 edleafe: right 19:13:39 +1 19:13:46 that does raise the question of where to stop, though 19:13:50 ==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 for example, not all projects are integrated -- do they belong in the sdk or not? 19:14:04 dhellmann: ++ 19:14:16 I think "integrated projects" is a reasonable initial criterion. 19:14:17 jnoller: i don't disagree with the umbrella project 19:14:19 dhellmann: For non integrated projects the plugin system needs to work for it 19:14:25 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 what about multiple region support? 19:14:32 ==dhellmann 19:14:38 jnoller: so back to core and non-core plugins? 19:14:43 jnoller: there's a specific prohibition against an extension system in the requirements 19:14:56 jamielennox: I think of it as a matter of priority 19:15:00 dhellmann: No, there's a restriction against using setuptools 19:15:02 edleafe: i'm sure that will be handled 19:15:32 i read the wiki page as "pluggability is mandatory" 19:15:33 dhellmann: that was my intention (re: priority, core/non-core) 19:15:34 jnoller: that's a conversation for the mailing list then 19:15:59 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 is the goal to eventually get rid of the python-*clients ? 19:16:27 jnoller: I'd like to hear more about the details of those issues on the ML 19:16:38 I don't want to support 2 versions of python-keystoneclient 19:16:40 bknudson: I think it should be. 19:16:41 jnoller: it is also better than writing another one 19:16:45 jnoller: I don't want to derail the entire meeting with the technical issues 19:16:56 then I think a requirement is that it has to implement everything the *clients do. 19:17:04 bknudson: i don't know over what timespan, but yes 19:17:07 bknudson: I would like the python-* clients to eventually use this as their backend if they wish to keep them around 19:17:18 bknudson: the idea is to separate the python module from the CLI 19:17:21 I also think we need to be careful with the next requirement, of allowing anyone to drop in extensions 19:17:29 the CLIs could then use the python module 19:17:32 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 we are, as a community, working to a goal of interoperability 19:17:42 developers won't need to import all the CLI stuff for their apps 19:17:57 vendor and cloud-specific extensions seem to be going in the opposite direction 19:17:58 belated intro (sorry!) Ruben Orduz, Rackspace 19:17:59 edleafe: that's already being solved with python-openstackclient 19:18:00 dolphm: Do you mean internal adoption or user adoption 19:18:07 edleafe: we are working towards that already 19:18:10 jnoller: user 19:18:52 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 dolphm: I'd say adoption is a matter of the vendors making it the recommended path for developers and users 19:19:09 jamielennox: but each python-*client re-implements a lot of stuff 19:19:17 edleafe: preaching to the choir 19:19:39 jamielennox: understood. Just 'splaining for everyone else 19:19:51 dhellmann: Vendor extensions - specifically differences in say, auth, are probably never going away 19:20:06 auth may be a separate question, I see utility in that 19:20:23 dhellmann: the SDK abstracts those differences so that END USERS get the experience of interop 19:20:23 but APIs that are not part of OpenStack for other purposes shouldn't blend in with the client library 19:20:30 an auth plugin doesn't have to extend the api if you can pass it in. 19:20:32 while vendors can fulfill business needs 19:20:54 bknudson: sure, auth may be an exception 19:21:02 There's also the concrete example: CDNs 19:21:23 jnoller: exactly 19:21:40 is CDN a feature of openstack? 19:21:56 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 how do you verify mocks/stubs? (other than disable as a mock) 19:22:11 dhellmann: no, but it's a feature that many business want/need 19:22:30 well, that's fine -- as openstack developers we should focus on the features of openstack, though 19:22:40 You don't verify a mock/stub, you verify a fake! 19:22:45 dhellmann: the OpenStack SDK will not support it. 19:22:49 http://martinfowler.com/articles/mocksArentStubs.html 19:22:56 But vendor subclasses might 19:22:57 edleafe: what I want to avoid is "from openstack import cdn" 19:23:03 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 because if CDN isn't a feature of openstack, it shouldn't look like it is from the API 19:23:11 Alex_Gaynor: OK OK! how do you verify a fake, other than not fake? 19:23:26 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 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 jamielennox: Which API 19:23:42 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 dhellmann: right, but the SDK should be extensible 19:23:52 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 jnoller: identity.v3.user.create() 19:24:17 from vendor import wrapper; from openstack import client; from provider import auth; c = wrapper(client(auth())) 19:24:18 jnoller: we are a long way off overarching things like CDN 19:24:32 dhellmann: vendor specific wrappers become vendor specific forks 19:24:35 jamielennox: openstack.create_user() 19:24:38 seems like a vendor could just provide their own api... why does it need to be in openstack api? 19:24:41 dhellmann: I've done just that to add Rackspace CDN stuff to my base OpenStack object storage client 19:24:46 jnoller: I have no interest in supporting vendor-specific APIs in the shared client 19:24:47 a wrapper is just one way to implement extensions 19:24:48 dolphm: that namespace is going to get very busy 19:25:00 jamielennox: openstack.user.create() 19:25:02 dolphm: also there are times i care about v2 vs v3 19:25:02 bknudson: because apps written to a vendor API would not be portable 19:25:08 mfer: the difference is no user would be confused that the wrapper is part of the client itself 19:25:10 bingo 19:25:12 jamielennox: you shouldn't 19:25:16 jamielennox: as an end user 19:25:31 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 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 dolphm: if this is going to replace the various -clients then it will probably need to 19:25:58 dhellmann and what about developers who write apps against multiple openstack installs. those with and without extensions 19:26:06 jamielennox: it needs to care about API versions, sure. but end users should not 19:26:14 real world practicality for end users is of interest to me 19:26:15 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 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 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 if rackspace and hp can agree on a cdn API, then they can share a wrapper library 19:27:00 jamielennox: right 19:27:10 dhellmann: ++ 19:27:21 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 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 dhellmann ++ 19:27:57 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 dhellmann: that's why specific vendor imports are preferable over setuptools entry points 19:28:11 dhellmann: the high level abstraction would be. 19:28:24 jnoller: ++ 19:28:32 jnoller++ 19:28:33 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 I just want users to be clear about what is and is not part of openstack as a whole 19:29:09 dhellmann: I'm advocating for Openstack first, but vendor extensions are something which affect users day to day 19:29:21 dhellmann: I don't imagine that the vendor-specific stuff would live in this project 19:29:22 dhellmann: we should *plan* for it, and architect for it 19:29:23 dhellmann note, it's not just HP and Rackspace doing extensions. I'm aware of others 19:29:42 mfer: sure, that's just the example that was raise 19:29:52 it's likely Dreamhost will offer extra services, too 19:29:55 architect to enable users to use extensions 19:30:11 architect to ensure users know when they are using an extension, and when not 19:30:13 I hope a goal is to endable end user developers to be successful 19:30:24 dhellmann yes. 19:30:35 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 in this discussion, user == developer 19:30:53 edleafe: yes 19:30:55 "architect to ensure users know when they are using an extension, and when not" +1000000000 dhellmann 19:31:16 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 It should be clear. Let's call it "extension" ;) 19:31:32 that's why importing a vendor module for an extension is preferred over setuptools-type extensions 19:31:47 edleafe: I'm not sure what that looks like in practice 19:32:08 Ok 19:32:22 import a vendor module that does all the things... or register a vendor extension with the openstack module? 19:32:48 people importing modules is clearly preferably to mutating global state 19:33:03 dhellmann: ok, the identity example I have would be something like: from rs_identity import RackspaceIdentity 19:33:04 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 It's clear that you're not using standard OpenStack identity 19:33:24 edleafe: ok, sure, that's similar to the generic example I mentioned earlier 19:33:29 yep 19:33:30 That's a concrete action item for a wiki page / blue print 19:33:31 and that's what I want 19:33:40 jnoller noted 19:33:48 briancurtin: thanks! 19:34:31 dhellmann: and the Rackspace class follows the same structure (methods/atts) as the base OpenStack class 19:34:51 edleafe: makes sense 19:35:07 #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 Err, why would they live in the openstack namespace at all? 19:35:49 #action briancurtin wiki page outlining vendor extension plugins/namespacing/loading and abstractions 19:35:50 are there any pages other than https://wiki.openstack.org/wiki/PythonOpenStackSDK that are relevant? 19:36:01 I want to make sure I've read everything I should... 19:36:05 Alex_Gaynor: +1 19:36:11 it wasn't clear if https://wiki.openstack.org/wiki/SDK-Development was part of this? 19:36:17 It is 19:36:17 or https://wiki.openstack.org/wiki/SDKs as well 19:36:20 ok 19:36:32 dhellmann: I meant to #link to https://wiki.openstack.org/wiki/SDK-Development 19:36:34 so one point of feedback is to collect all of those under a namespace 19:36:47 it's possible to have slashes in the URLs, for example, so we could have everything live under that SDK page 19:36:56 naming things is hard 19:37:03 also, making sure the top level page links to the others would help with discoverability 19:37:19 Who wants to fix the wiki namespacing :) 19:37:20 i can do some rearranging 19:37:23 searching brought up those few pages, so that worked, but obviously I wasn't sure they were all together 19:37:31 the wiki is full of old project notes :-) 19:37:34 #action briancurtin fix wiki namespaces / cleaning things up 19:37:40 briancurtin: cool, thanks 19:37:43 Ok 19:38:07 #topic State of blueprints / API strawman 19:38:35 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 (first time writing blue prints, comments/criticism more than welcome) 19:39:12 Yes, we've all held off on deep blue prints until we could discuss this as a community 19:39:23 Same with so much code 19:39:26 * dhellmann brings up one more pedantic point 19:39:37 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 should that be "openstack-sdk" or something? launchpad is used for lots of non-openstack projects 19:39:55 although I guess there could be a trademark issue 19:39:59 dhellmann: yeah, the name changed *after* I made the launchpad 19:40:04 that's why we have code names for the other projects 19:40:10 jnoller: ok 19:40:16 i'd like it to be openstack-sdk-python ... a reusable pattern with the language on the end 19:40:18 it's fine as it is, we can fix it when we incubate 19:40:21 this is what developers are used to 19:40:22 #action jollier rename launchpad project 19:40:47 we should also talk about who is on the drivers team, and eventually the core review team 19:40:55 mfer: Which developers? Python devs for AWS use boto 19:41:15 mfer: how widespread is that naming pattern? 19:41:56 jnoller: could you also change the python-osdk-team to allow people to request membership? 19:42:12 I think that's called a "moderated team" 19:42:19 dhellmann: can you show me how offline? I deleted the team the last time I tried ;) 19:42:26 haha, I'll try 19:42:35 Ok 19:42:42 aws and azure use it. google calls it a google cloud sdk but doesn't have multiple languages 19:43:26 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 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 dhellmann: thanks! 19:43:44 ok 19:44:08 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 i can't tell if they're light or just right for where we're at 19:44:35 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 I will, before our next meeting 19:44:43 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 briancurtin: they need content :) 19:44:58 if you all look at: 19:44:58 https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman 19:45:02 #link https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman 19:45:22 We'll start with the API / structure Alex proposed: Alex_Gaynor you're up 19:46:16 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 * Doing all auth using the API hooks in the HTTP layer 19:46:16 * Seperating compute from IO 19:46:21 What do these mean and why? 19:46:39 The first means we can truly write these as "Just HTTP requests", which gives clean seperation. 19:46:46 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 The latter makes this far easier to test, and makes it more reusable if you change the HTTP layer. 19:47:12 I don't understand the issue with auth? 19:47:12 Are we really supporting swauth here? 19:47:13 briancurtin: it'd be nice if these "API mockups" were actually in review as WIP for final docs 19:47:21 jamielennox has been doing a lot of work on auth plugins in keystoneclient. 19:47:30 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 right, i would realllly like you to look through all the plugin stuff we have 19:47:52 jamielennox: ++ 19:48:33 dolphm: good idea 19:48:47 so if there's a difference between v2 and v3 compute API -- how does the python API handle that? 19:48:51 Would the point here in having multiple auths be where the extensions come in to make it simpler for each provider? 19:49:03 e.g., maybe compute v3 gives you a task handle for a boot request 19:49:16 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 these are things that it would be nice if the API could hide, but not sure if that's possible. 19:49:44 bknudson: that would be a backwards compatible addition to the python sdk if a v3 compute endpoint was available 19:49:49 Alex_Gaynor: that may just be a matter of ensuring the request class has a rich enough API, though 19:50:25 dhellmann: Upload seems straightforward, the abstract definition of a request just needs to include a file-like/iterable/etc. 19:50:45 for body that is 19:51:03 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 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 Alex_Gaynor: yeah, I think that works, I just wanted to point out that not all request types are equal 19:51:54 we've already talked about whether it should be client.compute.list_images() or client.images.list() 19:52:08 I don't really care which we pick between those two :-) 19:52:23 Alex_Gaynor: they're quite different! 19:52:26 I obviously prefer the latter 19:52:31 dhellmann: ++ 19:52:34 Let's got with the latter 19:52:35 ++ 19:52:43 dhellmann++ 19:52:47 i just don't want 'compute' in there 19:52:55 but why have compute? aren't images in the image source? 19:53:03 images.list() 19:53:06 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 client.list_images() vs client.images.list() are both identical to me 19:53:16 dolphm: aren't there cinder images as well? 19:53:30 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 dolphm: the difference will come out in how the docs read 19:53:43 if it is client.list_images() then we have a HUGE flat API 19:53:55 dhellmann: e.g. openstack --help 19:53:55 yuck 19:53:55 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 Yeah, I'd really prefer NOT to have ONE GIANT NAMESPACE 19:54:20 it's confusing as all get-out 19:54:29 dolphm: right, it's the same reason I suggested "object verb" for the CLI instead of "verb object" 19:54:30 dhellmann: as mentioned though there is some contention around words like images 19:54:35 Assuming there's only one context for images, ever. 19:54:44 fwiw openstack --help: http://pasteraw.com/t01pe2jm4rqzlwvlqrelulrzfswr2ik 19:54:45 jamielennox: images are a glance thing, where is the contention? 19:55:17 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 dhellmann: cinder uses images, too 19:55:28 as far as nomenclature is concerned 19:55:44 rgbkrk: we're not going to get away from terminology overload 19:55:52 this is why I think we need the official service names contain the caller methods 19:55:57 dhellmann: IMHO, client.list_images and client.images.list are _both_ wrong :) 19:56:01 edleafe: the cinder-implemented operations for images would need to be named differently, I guess 19:56:07 glyph: alternate? 19:56:11 jnoller: like .identity. ? 19:56:18 dhellmann: sure - just pointing out name overloading 19:56:21 services.blockstorage.list_block() gives me context as a developer 19:56:23 That was my thought on what the contention is, from supporting web devs using our services. 19:56:31 dhellmann: As a very basic straw man, ImagesClient(client).list_images() 19:56:32 glyph: what's your alternative suggestion? 19:56:37 * dolphm spoke too soon 19:56:55 which is why I don't think we'll get 100% away from services in the namespace. 19:56:56 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 glyph: hey i'm writing that design in keystoneclient now 19:57:19 glyph: yeah, that's not so different than what we're providing today with the existing libraries 19:57:22 edleafe: what operations does cinder support on images? 19:57:25 jamielennox: ++ 19:57:28 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 dhellmann: YES the main client could implicitly interrogate the service catalog and create the sub clients 19:57:59 dhellmann: create, delete, and use as base for a new volume 19:58:01 jnoller: that's getting awfully automagical 19:58:08 jnoller: it could, or it could just create them when the code calls for it 19:58:31 jamielennox: is that not exactly what you're providing the tooling for? 19:58:35 jamielennox: Users don't care about authentication or service catalogs. They want to "make server start from my application" 19:58:40 sounds like a ClientManager to me…we're already doing that 19:58:43 edleafe: maybe those are "volume images" 19:58:46 dtroyer: right 19:58:52 ok 19:58:56 edleafe: i.e., different object type 19:58:58 we're just about out of time 19:59:01 question 19:59:02 but we can work out those details with more thought 19:59:03 dolphm: i don't like the idea of attributes sometimes available and sometimes not 19:59:21 i would much prefer the error after i've called something 19:59:25 dhellmann: yep, in my strawman it's volume.create_image() 19:59:28 jamielennox: +1 - make the object on demand, and let the api call fail if the service isn't there 19:59:33 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 there's two there. 19:59:39 edleafe: volume_images.create() 20:00:07 dhellmann: no, since you're acting on the volume 20:00:16 creating an image of that volume 20:00:16 the first 20:00:24 jnoller: the second one bundles the auth with the transport layer - don't do that 20:00:32 edleafe: ah, didn't get that 20:00:36 jnoller: an hour is up 20:00:37 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 #action jollier "note make the object on demand, and let the api call fail if the service isn't there" 20:00:54 jnoller or Alex_Gaynor : could you describe the difference 20:00:59 I don't like the list_image 20:01:11 glyph: welcome to OpenStack versioned APIs 20:01:19 whoops 20:01:25 glyph: well, that gets back to the original question of what should be included, only OpenStack features or any plugins 20:01:40 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 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 jamielennox: I made it a week? before 20:02:12 dtroyer: good point, I don't see versioning exposed anywhere, should it be? 20:02:19 I think glyph's point is that if people create ImageClient themselves, it obviates the need for a distiction 20:02:20 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 jnoller: i meant the start time - 24 hours 20:02:28 there's simply stuff you import from openstack and stuff you import from somewhere else 20:02:29 dhellmann: once we know how to do it, yes 20:02:39 And then discuss next meeting? 20:02:40 that buts it up against keystone 20:02:49 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 edleafe: good idea 20:02:55 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 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 I'd like to see a blueprint and a ML discussion 20:03:53 do we have a git repo? 20:04:01 yeah, I linked to it 20:04:07 https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman 20:04:07 ok, I'll read the logs 20:04:08 https://github.com/stackforge/python-openstacksdk 20:04:08 jnoller: i'd prefer some wiki or blueprints before we write any code - testing or not 20:04:16 oh, that one, ok 20:04:22 I didn't even read the URL, I just clicked it 20:04:25 * dhellmann is too trusting 20:04:57 jamielennox: have a link to a BP that walks through a high level API and then underlying architecture? 20:05:12 jamielennox: It's helps us newbs do some big design up front ;) 20:05:35 jnoller: not sure it exists - but this is fairly ambitious so we might need a first 20:05:59 #action Alex_Gaynor Flesh out your underlying http transport separation example documented on the wiki / blueprints 20:06:11 let's move back to -sdks at least 20:06:22 Ok 20:07:03 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 ++ 20:07:26 Thanks jnoller: 20:07:31 #endmeeting