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