Wednesday, 2013-05-08

*** vipul is now known as vipul|away00:10
*** manip has joined #openstack-meeting-alt00:12
*** manip has left #openstack-meeting-alt00:13
*** yidclare has quit IRC00:17
*** manip has joined #openstack-meeting-alt00:19
*** cp16net_ has joined #openstack-meeting-alt00:20
*** cp16net has quit IRC00:20
*** cp16net_ is now known as cp16net00:20
*** manip has left #openstack-meeting-alt00:21
*** manip has joined #openstack-meeting-alt00:22
*** manip has quit IRC00:23
*** kagan has quit IRC00:30
*** vipul|away is now known as vipul00:32
*** egor has quit IRC00:33
*** vipul is now known as vipul|away00:48
*** grapex has quit IRC00:50
*** vipul|away is now known as vipul00:52
*** bdpayne has quit IRC01:21
*** sarob has joined #openstack-meeting-alt01:23
*** sarob_ has quit IRC01:25
*** saurabhs has left #openstack-meeting-alt01:39
*** egor has joined #openstack-meeting-alt01:57
*** amyt has joined #openstack-meeting-alt03:52
*** amyt has quit IRC03:55
*** amyt has joined #openstack-meeting-alt03:57
*** amyt has quit IRC04:06
*** amyt has joined #openstack-meeting-alt04:07
*** amyt has quit IRC04:12
*** amyt has joined #openstack-meeting-alt04:13
*** SergeyLukjanov has joined #openstack-meeting-alt04:15
*** amyt has quit IRC04:20
*** amyt has joined #openstack-meeting-alt04:21
*** vipul is now known as vipul|away04:21
*** vipul|away is now known as vipul04:24
*** amyt has quit IRC04:24
*** amyt has joined #openstack-meeting-alt04:25
*** amyt has quit IRC04:33
*** amyt has joined #openstack-meeting-alt04:34
*** amyt has quit IRC04:41
*** amyt has joined #openstack-meeting-alt04:42
*** amyt has quit IRC04:44
*** vipul is now known as vipul|away04:53
*** sarob has quit IRC04:58
*** sarob has joined #openstack-meeting-alt04:59
*** egor has quit IRC05:00
*** egor has joined #openstack-meeting-alt05:01
*** sarob has quit IRC05:04
*** sacharya has quit IRC05:10
*** egor has quit IRC05:18
*** eghobo has joined #openstack-meeting-alt05:18
*** eghobo has quit IRC05:20
*** eghobo has joined #openstack-meeting-alt05:20
*** eghobo has quit IRC05:37
*** SergeyLukjanov has quit IRC05:49
*** eghobo has joined #openstack-meeting-alt06:07
*** eghobo has quit IRC06:17
*** eghobo has joined #openstack-meeting-alt07:07
*** eghobo has quit IRC07:18
*** eghobo has joined #openstack-meeting-alt08:08
*** dmitryme has joined #openstack-meeting-alt08:12
*** eghobo has quit IRC08:21
*** SergeyLukjanov has joined #openstack-meeting-alt08:27
*** SergeyLukjanov has quit IRC08:45
*** johnthetubaguy has joined #openstack-meeting-alt08:46
*** eghobo has joined #openstack-meeting-alt08:47
*** SergeyLukjanov has joined #openstack-meeting-alt08:55
*** eghobo has quit IRC08:56
*** openfly_ has joined #openstack-meeting-alt09:10
*** esmute_ has joined #openstack-meeting-alt09:11
*** iccha has joined #openstack-meeting-alt09:12
*** notmyname_ has joined #openstack-meeting-alt09:12
*** jcooley_ has joined #openstack-meeting-alt09:13
*** jcooley has quit IRC09:14
*** notmyname has quit IRC09:14
*** notmyname_ is now known as notmyname09:14
*** jcooley_ is now known as jcooley09:14
*** briancline has quit IRC09:21
*** openfly has quit IRC09:21
*** esmute has quit IRC09:21
*** iccha__ has quit IRC09:21
*** esmute_ is now known as esmute09:21
*** eghobo has joined #openstack-meeting-alt09:22
*** eghobo has quit IRC09:27
*** SergeyLukjanov has quit IRC09:41
*** SergeyLukjanov has joined #openstack-meeting-alt09:43
*** SergeyLukjanov has quit IRC10:19
*** eghobo has joined #openstack-meeting-alt10:22
*** eghobo has quit IRC10:26
*** rnirmal has joined #openstack-meeting-alt10:28
*** SergeyLukjanov has joined #openstack-meeting-alt10:30
*** briancline has joined #openstack-meeting-alt10:30
*** dmitryme has quit IRC10:34
*** dmitryme has joined #openstack-meeting-alt10:39
*** SergeyLukjanov has quit IRC10:54
*** yamahata_ has joined #openstack-meeting-alt11:05
*** SergeyLukjanov has joined #openstack-meeting-alt11:22
*** dhellmann-away has quit IRC11:23
*** eghobo has joined #openstack-meeting-alt11:50
*** yamahata_ has quit IRC11:50
*** SergeyLukjanov has quit IRC11:55
*** SergeyLukjanov has joined #openstack-meeting-alt12:08
*** yamahata_ has joined #openstack-meeting-alt12:28
*** eghobo has quit IRC12:37
*** dosaboy has quit IRC12:37
*** dosaboy has joined #openstack-meeting-alt12:39
*** dmitryme has quit IRC12:45
*** dmitryme has joined #openstack-meeting-alt12:46
*** eghobo has joined #openstack-meeting-alt13:07
*** eghobo has quit IRC13:17
*** eghobo has joined #openstack-meeting-alt13:23
*** johnthetubaguy has quit IRC13:28
*** SergeyLukjanov has quit IRC13:32
*** SergeyLukjanov has joined #openstack-meeting-alt13:34
*** sacharya has joined #openstack-meeting-alt13:51
*** sacharya has quit IRC13:55
*** eghobo has quit IRC14:02
*** djohnstone has joined #openstack-meeting-alt14:04
*** jcru has joined #openstack-meeting-alt14:04
*** sacharya has joined #openstack-meeting-alt14:19
*** grapex has joined #openstack-meeting-alt14:24
*** amyt has joined #openstack-meeting-alt14:25
*** grapex has quit IRC14:25
*** grapex has joined #openstack-meeting-alt14:25
*** yidclare has joined #openstack-meeting-alt14:26
*** dmitryme has quit IRC14:31
*** sacharya has quit IRC14:33
*** dmitryme has joined #openstack-meeting-alt14:46
*** cp16net is now known as cp16net|away14:46
*** johnthetubaguy has joined #openstack-meeting-alt14:49
*** grapex has quit IRC14:51
*** dmitryme has quit IRC14:57
*** dmitryme has joined #openstack-meeting-alt14:58
*** sacharya has joined #openstack-meeting-alt15:04
*** dmitryme has quit IRC15:05
*** tnurlyga has joined #openstack-meeting-alt15:06
*** yidclare has quit IRC15:08
tnurlyga#startmeeting15:09
openstacktnurlyga: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'15:09
tnurlyga#startmeeting murano15:10
openstackMeeting started Wed May  8 15:10:56 2013 UTC.  The chair is tnurlyga. Information about MeetBot at http://wiki.debian.org/MeetBot.15:10
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:10
*** openstack changes topic to " (Meeting topic: murano)"15:10
openstackThe meeting name has been set to 'murano'15:11
tnurlyga#endmeeting15:16
*** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack"15:16
openstackMeeting ended Wed May  8 15:16:37 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:16
openstackMinutes:        http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-08-15.10.html15:16
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-08-15.10.txt15:16
openstackLog:            http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-08-15.10.log.html15:16
*** tnurlyga has quit IRC15:20
*** sarob has joined #openstack-meeting-alt15:22
*** SergeyLukjanov has quit IRC15:27
*** cp16net|away is now known as cp16net15:30
*** vipul|away is now known as vipul15:35
*** vipul is now known as vipul|away15:36
*** SergeyLukjanov has joined #openstack-meeting-alt15:36
*** cloudchimp has joined #openstack-meeting-alt15:44
*** yidclare has joined #openstack-meeting-alt15:46
*** bdpayne has joined #openstack-meeting-alt15:52
*** grapex has joined #openstack-meeting-alt15:53
*** SergeyLukjanov has quit IRC15:59
*** vipul|away is now known as vipul16:08
*** dmitryme has joined #openstack-meeting-alt16:13
*** SergeyLukjanov has joined #openstack-meeting-alt16:14
*** SergeyLukjanov has quit IRC16:20
*** SergeyLukjanov has joined #openstack-meeting-alt16:25
*** dmitryme has quit IRC16:35
*** SergeyLukjanov has quit IRC16:35
*** yamahata_ has quit IRC16:39
*** bdpayne has quit IRC16:43
*** bdpayne has joined #openstack-meeting-alt16:45
*** ErikB has joined #openstack-meeting-alt16:54
*** jspeidel has joined #openstack-meeting-alt16:59
*** jmaron has joined #openstack-meeting-alt17:01
*** jspeidel has left #openstack-meeting-alt17:05
*** jspeidel has joined #openstack-meeting-alt17:06
*** jspeidel has left #openstack-meeting-alt17:06
*** jspeidel has joined #openstack-meeting-alt17:06
*** dmitryme has joined #openstack-meeting-alt17:07
*** jspeidel has left #openstack-meeting-alt17:09
*** jspeidel has joined #openstack-meeting-alt17:09
*** sarob_ has joined #openstack-meeting-alt17:26
*** sarob has quit IRC17:30
*** sarob has joined #openstack-meeting-alt17:35
*** sarob_ has quit IRC17:36
*** SergeyLukjanov has joined #openstack-meeting-alt17:36
*** amyt has quit IRC17:39
*** amyt has joined #openstack-meeting-alt17:40
*** dontalton has joined #openstack-meeting-alt17:47
*** highlycaffeinate has joined #openstack-meeting-alt17:58
*** akuznetsov has joined #openstack-meeting-alt17:59
*** jcru is now known as jcru|away18:03
dmitrymeHello everybody, lets start Savanna meeting18:04
dmitryme#startmeeting Savanna18:04
openstackMeeting started Wed May  8 18:04:27 2013 UTC.  The chair is dmitryme. Information about MeetBot at http://wiki.debian.org/MeetBot.18:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:04
*** openstack changes topic to " (Meeting topic: Savanna)"18:04
openstackThe meeting name has been set to 'savanna'18:04
dmitrymeHere is our agenda for today:18:04
dmitryme#info 1. Savanna 0.1.1 is released18:05
dmitryme#info 2. The docs are moved to readthedocs.org18:05
dmitryme#info 3. We continue to discuss Pluggable Provisioning Mechanism for phase 218:05
*** jcru|away is now known as jcru18:05
dmitrymeand that is all the news we have for today18:05
dmitrymeIn more details:18:05
dmitrymeAs I said we've just release a new version18:06
dmitrymeit contains a number of fixes and enhancements18:06
dmitrymeyou can see the full list by the following links:18:07
dmitryme#link https://launchpad.net/savanna/0.1/0.1.1a118:07
dmitryme#link https://launchpad.net/savanna/0.1/0.1.1a218:07
dmitryme#link https://launchpad.net/savanna/0.1/0.1.118:07
rnirmalcool thanks for the update dmitryme18:07
*** ruhe has joined #openstack-meeting-alt18:08
dmitrymeOk, as for the docs, they were moved to the http://savanna.readthedocs.org/18:08
dmitrymewe've also updated the wiki and launchpad, they both reference readthedocs as the main location18:08
dmitrymeAnd we continue our discussion on the Pluggable Provisioning Mechanism18:10
dmitrymeI will not retell it all there :-), just take a look at mailing archive if you're interested:18:11
dmitryme#link https://lists.launchpad.net/savanna-all/18:11
jmarondo you want to take up some of that discussion here, or continue on email?18:11
dmitrymethat is pretty all we wanted to anounce today18:11
rnirmalis there any specific agenda for today or open discussion ? or I suppose discuss on the pluggable provisioning part18:12
dmitrymesure, I guess that is the place18:12
dmitrymewe have agenda for discussion18:12
dmitrymeou18:12
dmitrymewe have NO agenda for discussion18:12
rnirmalah ok.. cool so maybe if we want to talk about some of the points for pluggable provisioning18:13
dmitrymesure, why not18:13
dmitrymefeel free to ask anything what concerns you, we will try to answer everything18:13
rnirmalsuppose exec_resource_action has been the most discussed without any conclusion18:14
jmaronI responded with some additional info/context to the email18:14
jmarondoes that response clear things up?18:15
ruhejmaron, can you please provide an example use case for ambari?18:16
rnirmaljmaron: some of the issues I see with that are... what do the responses look like.. those seem like they would be specific per plugin18:16
rnirmaljust at an api interaction level. is the expectation that the user makes a POST/PUT call that gets passed to the exec_resource_action18:18
jmaronexactly. they would be. the idea here is that your an experienced ambari administrator with existing scripting capabilities.  but since you're provisioning clusters dynamically you do not want to keep modifying the host and port etc to communicate directly with ambari.  savanna can act as a "gateway" so that you continue to interact with the savanna server but calls go to the current hadoop cluster(s)18:18
jmaronI haven't thought thru this completely, and I'm not a security expert, but there also seems to be a capability for having the savanna server sitting in a DMZ fronting clusters that exist within an enterprise that doesn't want those resources exposed directly18:19
ruheok, i see. thanks18:20
rnirmalfrom the savanna standpoint performing the get_maagement_urls() call to return that information seems more adept for savanna, than having to pass thru calls to the provider18:20
jmaronin a dynamic cluster environment, especially the analytics case, those URIs, though available, will be fairly transient18:21
jmaronthis is simply a convenience for those scenarios18:22
rnirmalsure agree with that... but wouldn't it be as easy to get the lastest URI for the cluster and perform those operations as you would with Ambari today18:22
*** heller-mobi has joined #openstack-meeting-alt18:22
rnirmalinstead of having them interlaced with savanna18:22
dmitrymeJon, to me that Savanna sitting in DMZ sounds like a usefull usecase18:22
rnirmalalso pardon my ignorance... I haven't really used ambari to comment on it properly.. I'm just looking at it from a savanna generic service standpoint18:23
jmaronrnirmal, in a manual interaction, yes - that would be feasible.  but what about an automated scenario (monitoring scripts)?  the pass thru capability enables that much more readily18:24
jmaronand there is the DMZ use case as well18:24
jmaronwhere the actual management URIs aren't exposed to the end users (analysts)18:24
dmitrymeas for automatic - actually auto client can query get_management_urls and take the one with specific name18:25
*** mattf has joined #openstack-meeting-alt18:25
dmitrymeI mean that could be easily automated18:25
rnirmalunderstandable for a case where the URI's need not be exposed to the end user18:25
jmaronone other capability:18:26
dmitrymeYes as I said, I agree with security usecase18:26
jmaronthe plugin could actually interpret the URI requested as a request to consolidate info from multiple hadoop clusters (each managed separately)18:27
jmarona feature that could be easily enabled if the plugin is allowed to process the URI and the response18:27
rnirmalbut that goes out of scope for the savanna api... since it would be operating on a specific cluster. I understand the plugin could support it, we also need to think how it's going to be exposed in savanna.18:28
jmaronthis isn't a UI targeted feature.  end users querying for such information are targeting specific providers with REST invocations18:29
rnirmalso something like extensions to the base savanna api ?18:30
jmaronin this particular case savanna is simply a REST "gateway"18:30
jspeidelbasically savanna would just need to expose a new endpoint such as 'hadoop'18:31
rnirmalyeah not worried about the UI... just the savanna api part18:31
jspeidelall requests to this endpoint would be passed through to the appropriate provider18:31
dmitrymeas for me, I think me and my team need time to consider all pros and cons18:32
ruhewe need to compose pros and cons of this approach, compared to simple api call which would return management url18:32
dmitrymegenerally pros are what Jon said right now18:32
jmaronGET /v1/{tenant-id}/hadoop/{provider_id}/clusters/c1/services/HDFS/components/DATANODE would be a request that would be passed to given {provider_id}18:32
dmitrymethe main cons - we're not sure if that will be a "popular"18:33
jmaronso URI from {provider_id} on would be interpreted by plugin18:33
dmitryme"popular" feature18:33
jmaronit's not "sexy", but it would support admin tasks18:34
jmaronand some security scenarios18:34
rnirmaldmitryme: you beat me to it... I was going to say is it a case that is applicable for more than just one plugin18:34
jspeidelmost hadoop providers hava a rest api18:34
jspeidelfor monitoring and management18:35
dmitrymeby "popular" I mean popularity within end users18:35
jspeidelthis provides flexibility to the user without complicating the savanna api18:35
jspeidelcurrently, there is great demand for the Ambari REST api's for HDP users18:36
jspeidelI would assume the same would hold for Cloudera, etc18:36
jmaronand if we're concerned about perception, there is no exposure to end users via UI elements etc.  It is an admin feature18:36
dmitrymeok guys, your points sounds reasonable, just give us some time to consider that18:37
jmaronok.  thanks!18:37
rnirmaljmaron: I wouldn't be too opposed to it, if it's proposed as an admin feature  ;) .. the perception holds18:37
ruheif i have a script to manage cluster (hdp or cdh) and i have a cluster i want to manage through rest api. I have two choices here: 1. update cluster name in the script to work with it. 2. update management url to work with it. So I don't see a difference between returning management URL or passing through such requests18:38
rnirmaljmaron: another question... so it's a pass thru rest call ?18:38
rnirmalwell n/m18:38
rnirmalit still has to be passed to the plugin right18:38
jspeidelone  difference is that the user would need to resolve the public ip addr and port of each management server prior to invoking the api18:39
jspeidelinstead of just providing a cluster name18:39
jmaronruhe:  there's a third option - you don't have to modify the script at all.  you continue to make your requests to savanna18:39
jspeideland having savanna/plugin resolve the cluster management server18:39
jspeidelalso, savanna could streamline security as mentioned earlier instead of the user having to obtain management specific user credentials18:40
rnirmalother than the proxy part.. I'm still not seeing too much differences between both the approaches.18:41
rnirmalsorry benefits one over the other18:41
rnirmalI suppose lets doc the pros/cons and get back to it18:42
ruheagree18:42
jmaronI'm not sure how you can argue with the DMZ/security proxy use case.  but yes - let's think about it some more...18:42
ruheDMZ is a good case of course18:44
jspeidelI can't really think of any cons for providing this and haven't seen any mentioned yet18:45
jmaronon to…you seem to have  a concern with an "execute" command with a list of prompt responses to handle situations in which there is an interactive session?  we're concerned with writing that capability in the plugin since it make environmental assumptions (i.e. OS, SSH availability) in the plugin which we feel are unwise…18:47
rnirmalwith multiple providers handling the requests / responses could make the savanna api complicated.18:47
jmaron"forces the plugin to make.."18:47
jmarononly one plugin would handle the request18:48
jspeidelrnimral: the savanna api would only need to add a single 'hadoop' endpoint18:48
*** hub_cap has left #openstack-meeting-alt18:48
jmaronthere's nothing complicated about the api.  all it means from savanna is exposing a context root18:48
*** johnthetubaguy has quit IRC18:49
ruheDmitry pointed a couple of cons today in the mailing list: supporting exec_resource_action() call will require significant amount of work. It will include HTTP proxy functionality, error handling, etc.18:50
dmitrymeJon, as for interactive execute. No matter where this code will be, it will need to handler OS differences.18:50
jmaronI think that's a misunderstanding?  the plugin is making the REST invocation18:50
dmitrymeOn the other side, at this time we think about working mainly with RHEL and Ubuntu18:51
jspeideldmitryme: that is why this should be provided as a service to the plugin18:51
jmaronright - but that abstraction is precisely the sort of service we expect of the controller18:52
jspeidelthe hadoop provider should focus on hadoop18:52
jspeidelnot low level connection details18:52
ruhejmaron, it's seems to me that each plugin will end up with it's own rest client implementation18:52
jspeideleach already have their own REST API's18:52
dmitrymeand will require its own set of utilities, which is not good18:52
jmaronruhe:  unless the controller provides HTTP client as a service18:52
dmitrymewe want Savanna to keep only API common for different plugins18:53
ruhelooking at cloudera rest api python client- it's a sufficient amount of code18:53
jmaronin our view, the plugin should only deal with hadoop provisioning and be abstracted from environmental concerns.  any leakage of the environment into the plugin is going to make the whole thing very brittle18:54
jspeidelruhe: not sure I understand.  what does it matter how much code in in the cloudera python client?18:54
*** grapex has left #openstack-meeting-alt18:56
rnirmalyeah that shouldn't matter... it will just be a dependency and not actually live within the savanna codebase.18:56
jspeidelwe are simply proposing making access to provider api's easier for a savanna user by providing a savanna context root18:57
jspeidelit is not a dependency18:57
*** zzs has joined #openstack-meeting-alt18:57
*** wolfdreamer has joined #openstack-meeting-alt18:57
jspeidelall you would need to do is pass the request to the provider and the provider would execute the rest call against the correct management server18:58
rnirmalwell if they plan on using their python sdk to interface with the rest api then it is... but that's a specific implementation detail18:59
jspeidelyes, it is really just an http call right18:59
rnirmalyup18:59
rnirmalwell think times up..19:00
dmitrymeJon, actually commands passed over SSH will always be environment-dependant, even if we implment interactive execute inside Savanna19:00
*** cp16net is now known as cp16net|away19:00
*** cp16net|away is now known as cp16net19:00
dmitrymeI mean, you will have list of commands and env variables dependent on OS you run on19:01
jspeidelthat is really no different that providing the ability to copy files is it?19:01
dmitrymein broader case, you might even run on non-bash shell19:01
jmaronright.  it seems to me you're making our argument...19:02
jmaronthe controller should abstract those details19:02
jmaronand allow plugins to simply execute19:02
jspeidelotherwise every hadoop provider will need to deal with these VM provider level details19:02
jmaronsince it would be a mistake to have plugins assume bash, or ssh availability, or ftp availability19:02
jmaronthe plugins should request a service (e.g. execute command on host) and not have to worry about the execution details19:03
ruheagree, plugin should not deal with OS details.19:04
jmaronimagine an openstack deployment on windows....19:04
jmaronthe plugin should still work19:06
ruheyep, I too think that controller should take control of that19:06
dmitrymeok, I guess we19:06
jmaronbut savanna would have an execution toolkit for supporting the same functionality on windows19:07
dmitrymewe're out of time19:07
jspeidelthe vm plugin would know how to deal with windows in this case19:07
jmaron"vm plugin"  - VM provisioning (as opposed to hadoop plugin) (just to be clear)19:08
jspeidelyes19:08
jspeidelit would know how to deal with the underlying vm's19:08
rnirmalyeah that will be something that needs to be built. that's a whole another topic19:09
jmaronand the controller would still support "execute on host".  the plugin would not know that the execution is occurring on a windows VM19:09
*** ErikB has quit IRC19:10
ruhewe only need to carefully pick the right tool for this task. do you have suggestions?19:10
jmarontask?19:10
ruheprovide OS-abstract functions such as install, execute19:11
*** highlycaffeinate has quit IRC19:11
*** ErikB has joined #openstack-meeting-alt19:11
*** dhellmann has joined #openstack-meeting-alt19:11
jmaronI have no suggestions off the top of my head.  I'm just making the architectural argument that these abstractions are important to a resilient successful software product19:12
ruheok, I agree with your argument, just wondering what would be the right tool19:13
*** dmitryme2 has joined #openstack-meeting-alt19:14
rnirmalruhe: you mean like a cross platform tool to do it?19:14
*** highlycaffeinate has joined #openstack-meeting-alt19:15
ruheyes. something like puppet or chef19:15
ruhebut simpler :)19:15
rnirmalyeah also need to look at heat a little more.. maybe something we can leverage from there.19:16
*** vipul is now known as vipul|away19:16
rnirmalanyways.. shall we end today's meeting... just seems like going into a long tail of conversations that can be carried over to #savanna19:16
*** dmitryme has quit IRC19:17
dmitryme2yep, lets continue the discussion in emails19:17
*** dmitryme2 is now known as dmitryme19:17
dmitryme#endmeeting19:18
*** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack"19:18
openstackMeeting ended Wed May  8 19:18:23 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:18
openstackMinutes:        http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-05-08-18.04.html19:18
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-05-08-18.04.txt19:18
openstackLog:            http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-05-08-18.04.log.html19:18
dmitrymethanks everyone for your participation19:18
heller-mobibye19:19
*** highlycaffeinate has left #openstack-meeting-alt19:19
*** mattf has left #openstack-meeting-alt19:19
*** jspeidel has left #openstack-meeting-alt19:19
*** ruhe has left #openstack-meeting-alt19:25
*** heller-mobi has quit IRC19:25
*** akuznetsov has left #openstack-meeting-alt19:26
*** akuznetsov has joined #openstack-meeting-alt19:26
*** rnirmal has quit IRC19:31
*** SergeyLukjanov has quit IRC19:39
*** cp16net is now known as cp16net|away19:41
*** cp16net|away is now known as cp16net19:42
*** vipul|away is now known as vipul20:07
*** cp16net is now known as cp16net|away20:10
*** cp16net|away is now known as cp16net20:19
*** dmitryme has quit IRC20:23
*** jmaron has quit IRC20:25
*** jmaron has joined #openstack-meeting-alt20:32
*** wolfdreamer has left #openstack-meeting-alt20:37
*** jmaron has quit IRC20:44
*** jmaron has joined #openstack-meeting-alt20:45
*** akuznetsov has quit IRC20:57
*** jmaron has quit IRC20:58
*** jmaron has joined #openstack-meeting-alt21:08
*** RajeshMohan has quit IRC21:14
*** vipul is now known as vipul|away21:20
*** jmaron has quit IRC21:27
*** dosaboy has quit IRC21:35
*** dosaboy has joined #openstack-meeting-alt21:37
*** vipul|away is now known as vipul21:41
*** hub_cap has joined #openstack-meeting-alt21:42
*** ErikB has quit IRC21:52
*** jmaron has joined #openstack-meeting-alt21:57
*** sacharya has quit IRC21:57
*** dhellmann has quit IRC22:02
*** djohnstone1 has joined #openstack-meeting-alt22:03
*** djohnstone has quit IRC22:05
*** jmaron has quit IRC22:05
*** djohnstone1 has quit IRC22:07
*** ErikB has joined #openstack-meeting-alt22:23
*** yidclare has quit IRC22:25
*** ErikB has quit IRC22:28
*** yidclare has joined #openstack-meeting-alt22:29
*** ErikB has joined #openstack-meeting-alt22:29
*** cloudchimp has quit IRC22:35
*** jmaron has joined #openstack-meeting-alt23:02
*** jmaron has quit IRC23:07
*** sacharya has joined #openstack-meeting-alt23:18
*** amyt has quit IRC23:19
*** jcru is now known as jcru|away23:23
*** jcru|away is now known as jcru23:25
*** jcru has quit IRC23:28
*** wolfdrea_ has joined #openstack-meeting-alt23:28
*** wolfdrea_ has quit IRC23:33
*** ErikB has quit IRC23:43
*** yidclare has quit IRC23:54
*** yidclare has joined #openstack-meeting-alt23:55
*** yidclare has quit IRC23:55
*** yidclare has joined #openstack-meeting-alt23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!