| *** sacharya1 has joined #openstack-meeting-alt | 02:08 | |
| *** sacharya has quit IRC | 02:10 | |
| *** ErikB has joined #openstack-meeting-alt | 02:18 | |
| *** cp16net is now known as cp16net|away | 02:38 | |
| *** ErikB has quit IRC | 03:07 | |
| *** enigma1 has joined #openstack-meeting-alt | 03:21 | |
| *** enigma2 has joined #openstack-meeting-alt | 03:23 | |
| *** enigma1 has quit IRC | 03:23 | |
| *** sacharya has joined #openstack-meeting-alt | 04:04 | |
| *** sacharya1 has quit IRC | 04:05 | |
| *** cp16net|away is now known as cp16net | 04:11 | |
| *** HenryG has joined #openstack-meeting-alt | 04:18 | |
| *** enigma2 has quit IRC | 04:20 | |
| *** cp16net is now known as cp16net|away | 04:26 | |
| *** cp16net|away is now known as cp16net | 04:35 | |
| *** hartsocks has joined #openstack-meeting-alt | 04:35 | |
| *** hartsocks1 has quit IRC | 04:36 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 04:42 | |
| *** glikson has joined #openstack-meeting-alt | 04:55 | |
| *** amyt has joined #openstack-meeting-alt | 05:04 | |
| *** glikson has quit IRC | 05:08 | |
| *** amyt has quit IRC | 05:11 | |
| *** amyt has joined #openstack-meeting-alt | 05:11 | |
| *** glikson has joined #openstack-meeting-alt | 05:15 | |
| *** sacharya has quit IRC | 05:21 | |
| *** glikson has quit IRC | 06:00 | |
| *** ewindisch has joined #openstack-meeting-alt | 06:09 | |
| *** ewindisch has quit IRC | 06:10 | |
| *** SergeyLukjanov has quit IRC | 06:22 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 06:23 | |
| *** glikson has joined #openstack-meeting-alt | 06:27 | |
| *** glikson has quit IRC | 07:14 | |
| *** ewindisch has joined #openstack-meeting-alt | 07:18 | |
| *** glikson has joined #openstack-meeting-alt | 07:32 | |
| *** amyt has quit IRC | 07:46 | |
| *** amyt has joined #openstack-meeting-alt | 07:48 | |
| *** amyt has quit IRC | 07:52 | |
| *** ewindisch has quit IRC | 07:54 | |
| *** ewindisch has joined #openstack-meeting-alt | 08:07 | |
| *** ewindisch has quit IRC | 08:14 | |
| *** ewindisch has joined #openstack-meeting-alt | 08:17 | |
| *** ewindisch has quit IRC | 08:31 | |
| *** SergeyLukjanov has quit IRC | 08:38 | |
| *** bradjones|away has quit IRC | 09:01 | |
| *** bradjones|away has joined #openstack-meeting-alt | 09:09 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 09:41 | |
| *** SergeyLukjanov has quit IRC | 10:07 | |
| *** ewindisch has joined #openstack-meeting-alt | 10:23 | |
| *** glikson has quit IRC | 10:46 | |
| *** glikson has joined #openstack-meeting-alt | 11:04 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 11:11 | |
| *** glikson has quit IRC | 11:26 | |
| *** HenryG has quit IRC | 11:32 | |
| *** HenryG has joined #openstack-meeting-alt | 11:33 | |
| *** SergeyLukjanov has quit IRC | 11:41 | |
| *** ErikB has joined #openstack-meeting-alt | 11:43 | |
| *** ewindisch has quit IRC | 11:44 | |
| *** glikson has joined #openstack-meeting-alt | 11:46 | |
| *** ewindisch has joined #openstack-meeting-alt | 11:47 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 11:48 | |
| *** SergeyLukjanov has quit IRC | 12:02 | |
| *** ErikB has quit IRC | 12:11 | |
| *** ewindisch has quit IRC | 12:26 | |
| *** ewindisch has joined #openstack-meeting-alt | 12:34 | |
| *** ewindisch has quit IRC | 12:40 | |
| *** jcru has joined #openstack-meeting-alt | 12:42 | |
| *** ErikB has joined #openstack-meeting-alt | 12:57 | |
| *** ErikB has quit IRC | 13:03 | |
| *** ewindisch has joined #openstack-meeting-alt | 13:03 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 13:13 | |
| *** SergeyLukjanov has quit IRC | 14:04 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 14:07 | |
| *** cloudchimp has joined #openstack-meeting-alt | 14:08 | |
| *** djohnstone has joined #openstack-meeting-alt | 14:10 | |
| *** thatsdone has joined #openstack-meeting-alt | 14:11 | |
| *** sacharya has joined #openstack-meeting-alt | 14:12 | |
| *** cp16net is now known as cp16net|away | 14:14 | |
| *** amyt has joined #openstack-meeting-alt | 14:19 | |
| *** amyt has quit IRC | 14:19 | |
| *** amyt has joined #openstack-meeting-alt | 14:19 | |
| *** sacharya has quit IRC | 14:24 | |
| *** enigma1 has joined #openstack-meeting-alt | 14:25 | |
| *** cp16net|away is now known as cp16net | 14:26 | |
| *** enigma2 has joined #openstack-meeting-alt | 14:27 | |
| *** sarob has joined #openstack-meeting-alt | 14:29 | |
| *** enigma1 has quit IRC | 14:30 | |
| *** dhellmann has joined #openstack-meeting-alt | 14:35 | |
| *** hub_cap has left #openstack-meeting-alt | 14:37 | |
| *** SergeyLukjanov has quit IRC | 14:44 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 14:49 | |
| *** sarob has quit IRC | 14:50 | |
| *** sarob has joined #openstack-meeting-alt | 14:50 | |
| *** markwash has quit IRC | 14:51 | |
| *** sarob has quit IRC | 14:55 | |
| *** demorris has joined #openstack-meeting-alt | 14:55 | |
| *** sacharya has joined #openstack-meeting-alt | 15:00 | |
| *** ewindisch has quit IRC | 15:06 | |
| *** cloudchimp has quit IRC | 15:06 | |
| *** grapex has joined #openstack-meeting-alt | 15:12 | |
| *** cp16net is now known as cp16net|away | 15:15 | |
| *** cp16net|away is now known as cp16net | 15:16 | |
| *** hartsocks has quit IRC | 15:27 | |
| *** hartsocks has joined #openstack-meeting-alt | 15:29 | |
| *** dmitryme has joined #openstack-meeting-alt | 15:31 | |
| *** grapex has quit IRC | 15:34 | |
| *** sarob has joined #openstack-meeting-alt | 15:35 | |
| *** sarob_ has joined #openstack-meeting-alt | 15:36 | |
| *** bdpayne has joined #openstack-meeting-alt | 15:38 | |
| *** sarob has quit IRC | 15:40 | |
| *** jcru is now known as jcru|away | 15:42 | |
| *** cp16net is now known as cp16net|away | 15:44 | |
| *** dmitryme has quit IRC | 15:55 | |
| *** yamahata_ has joined #openstack-meeting-alt | 15:59 | |
| *** thatsdone has quit IRC | 15:59 | |
| *** demorris_ has joined #openstack-meeting-alt | 16:01 | |
| *** glikson has quit IRC | 16:02 | |
| *** demorris has quit IRC | 16:03 | |
| *** demorris_ is now known as demorris | 16:03 | |
| *** grapex has joined #openstack-meeting-alt | 16:06 | |
| *** jcru|away is now known as jcru | 16:10 | |
| *** grapex has quit IRC | 16:13 | |
| *** cp16net|away is now known as cp16net | 16:22 | |
| *** glikson has joined #openstack-meeting-alt | 16:22 | |
| *** cp16net is now known as cp16net|away | 16:42 | |
| *** esp1 has joined #openstack-meeting-alt | 16:44 | |
| *** esp1 has left #openstack-meeting-alt | 16:44 | |
| *** jcru is now known as jcru|away | 16:44 | |
| *** enigma2 has quit IRC | 16:53 | |
| *** stanlagun has joined #openstack-meeting-alt | 16:57 | |
| *** sarob_ has quit IRC | 17:00 | |
| *** markwash has joined #openstack-meeting-alt | 17:00 | |
| *** sergmelikyan has joined #openstack-meeting-alt | 17:03 | |
| *** SergeyLukjanov has quit IRC | 17:05 | |
| *** jgriffith has joined #openstack-meeting-alt | 17:11 | |
| *** sarob has joined #openstack-meeting-alt | 17:25 | |
| *** enigma1 has joined #openstack-meeting-alt | 17:26 | |
| *** enigma2 has joined #openstack-meeting-alt | 17:28 | |
| *** enigma1 has quit IRC | 17:31 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 17:42 | |
| *** sarob has quit IRC | 17:43 | |
| *** sarob has joined #openstack-meeting-alt | 17:43 | |
| *** jcru|away is now known as jcru | 17:44 | |
| *** enigma2 has quit IRC | 17:46 | |
| *** enigma1 has joined #openstack-meeting-alt | 17:47 | |
| *** cp16net|away is now known as cp16net | 17:50 | |
| *** enigma2 has joined #openstack-meeting-alt | 17:50 | |
| *** dteselkin has joined #openstack-meeting-alt | 17:52 | |
| *** enigma1 has quit IRC | 17:53 | |
| sergmelikyan | #startmeeting murano | 18:00 |
|---|---|---|
| openstack | Meeting started Mon May 6 18:00:46 2013 UTC. The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| *** openstack changes topic to " (Meeting topic: murano)" | 18:00 | |
| openstack | The meeting name has been set to 'murano' | 18:00 |
| sergmelikyan | Welcome to Murano Project community meeting | 18:00 |
| sergmelikyan | Today's agenda: | 18:01 |
| sergmelikyan | 1) New team members introduction | 18:01 |
| sergmelikyan | 2) Blueprints tracking | 18:01 |
| sergmelikyan | 3) Transfer to StackForge infrastructure | 18:01 |
| sergmelikyan | 4) Q&A | 18:01 |
| sergmelikyan | #topic New Team Members | 18:02 |
| *** openstack changes topic to "New Team Members (Meeting topic: murano)" | 18:02 | |
| sergmelikyan | #info Igor Yozhikov (igor_yozhikov) has joined to our team as deployment engineer. Igor is going to help us to extend capabilities of Murano Project in configuration management area, add new deployment scenarios and help us to build setup scripts for Murano project | 18:05 |
| *** tnurlyga has joined #openstack-meeting-alt | 18:05 | |
| sergmelikyan | #topic Blueprints Tracking | 18:05 |
| *** openstack changes topic to "Blueprints Tracking (Meeting topic: murano)" | 18:05 | |
| sergmelikyan | Currently we do not track any blueprints, we need some way to publish already existing blueprints and write new according to features from roadmap | 18:06 |
| *** gokrokve has joined #openstack-meeting-alt | 18:07 | |
| sergmelikyan | Launchpad is one way to track our blueprints, but we can't rewrite our blueprints specially for publishing for now (it's lots of work). What about writing and publishing blueprints for new features as main activity with top priority in this area? | 18:08 |
| sergmelikyan | Blueprints for already implemented features we can prepare and publish with some new changes within features. | 18:09 |
| sergmelikyan | ? | 18:09 |
| gokrokve | Yes. Lets publish upcoming features blueprints first. At least for first and second phases. | 18:10 |
| *** dhellmann has quit IRC | 18:11 | |
| sergmelikyan | any objections? Stan? | 18:11 |
| sergmelikyan | #idea we going to publish upcoming features blueprints first. Old features will receive bluprints with new changes within feature. | 18:12 |
| stanlagun | I agree with @gokrokve. Let's do it as soon as we would know what to publish | 18:12 |
| sergmelikyan | #action stanlagun, write and publish blueprint for ASP.NET Application Deployment feature | 18:13 |
| sergmelikyan | #action stanlagun, write and publish blueprint for IIS Cluster feature | 18:13 |
| sergmelikyan | #action sergmelikyan, write and publish blueprint for Session Handling and Deployments feature | 18:14 |
| sergmelikyan | Ok, looks like we done with AI's for this topic. I missed something? | 18:14 |
| sergmelikyan | stanlagun, more detailed info about blueprints can be found at launchpad itself, and i will consult you about 'How to write blueprint' :D | 18:16 |
| sergmelikyan | stanlagun, gokrokve? | 18:16 |
| stanlagun | sergmelikyan: thanx | 18:16 |
| gokrokve | Looks good. | 18:16 |
| sergmelikyan | moving on... | 18:16 |
| sergmelikyan | #topic Transfer to Stackforge | 18:16 |
| *** openstack changes topic to "Transfer to Stackforge (Meeting topic: murano)" | 18:17 | |
| gokrokve | Is it done? | 18:18 |
| sergmelikyan | Our changeset (https://review.openstack.org/27471) still not merged to master, i have rebased it to HEAD as James suggested | 18:18 |
| gokrokve | We plan to do this last week. | 18:18 |
| gokrokve | Ok. | 18:18 |
| sergmelikyan | It's look pretty good actually (according to words from reviewers team), but master branch moved forward since commiting and rebase was required | 18:19 |
| sergmelikyan | #topic Q&A | 18:20 |
| *** openstack changes topic to "Q&A (Meeting topic: murano)" | 18:20 | |
| sergmelikyan | Let | 18:20 |
| *** vipul is now known as vipul|away | 18:21 | |
| sergmelikyan | Let's try to answer some questions :) Maybe there are some after announcement :) | 18:21 |
| sergmelikyan | Till the next week! We always available at #murano channel and via mailing list murano-all@lists.launchpad.net | 18:29 |
| sergmelikyan | #endmeeting murano | 18:29 |
| *** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack" | 18:29 | |
| openstack | Meeting ended Mon May 6 18:29:54 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:29 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-06-18.00.html | 18:29 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-06-18.00.txt | 18:29 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-05-06-18.00.log.html | 18:29 |
| *** vipul|away is now known as vipul | 18:34 | |
| *** tnurlyga has quit IRC | 18:35 | |
| *** glikson has quit IRC | 18:38 | |
| *** sirushti has joined #openstack-meeting-alt | 18:43 | |
| *** vipul is now known as vipul|away | 18:51 | |
| *** vipul|away is now known as vipul | 19:06 | |
| *** vipul is now known as vipul|away | 19:06 | |
| *** sarob has quit IRC | 19:10 | |
| *** ewindisch has joined #openstack-meeting-alt | 19:24 | |
| *** dhellmann has joined #openstack-meeting-alt | 19:24 | |
| *** cp16net is now known as cp16net|away | 19:34 | |
| *** dteselkin has quit IRC | 19:35 | |
| *** cp16net|away is now known as cp16net | 19:37 | |
| *** jbresnah has joined #openstack-meeting-alt | 19:54 | |
| *** vipul|away is now known as vipul | 19:57 | |
| *** sarob has joined #openstack-meeting-alt | 19:58 | |
| *** markwash has quit IRC | 19:58 | |
| jbresnah | Are those interested in the transfer service meeting around? | 20:01 |
| ameade | ack | 20:01 |
| *** markwash has joined #openstack-meeting-alt | 20:01 | |
| jbresnah | #startmeeting transfer-service | 20:01 |
| openstack | Meeting started Mon May 6 20:01:51 2013 UTC. The chair is jbresnah. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:01 |
| *** openstack changes topic to " (Meeting topic: transfer-service)" | 20:01 | |
| openstack | The meeting name has been set to 'transfer_service' | 20:01 |
| jbresnah | ameade is here, anyone else ready? | 20:02 |
| markwash | o/ | 20:02 |
| *** gokrokve has quit IRC | 20:02 | |
| jbresnah | iccha, nikhil, rosmaita? | 20:02 |
| *** sarob has quit IRC | 20:02 | |
| nikhil | ack | 20:02 |
| iccha__ | hey jbresnah | 20:02 |
| jbresnah | excelent | 20:03 |
| *** sarob has joined #openstack-meeting-alt | 20:03 | |
| jbresnah | ok | 20:03 |
| jbresnah | i emailed out the agenda | 20:03 |
| jbresnah | The first thing is a quick introduction to the idea | 20:03 |
| jbresnah | it is largely documented elsewhere | 20:04 |
| jbresnah | https://blueprints.launchpad.net/glance/+spec/image-transfer-service | 20:04 |
| jbresnah | and there are many links there | 20:04 |
| jbresnah | The main idea is to have a service that handles data transfer as a first class problem | 20:05 |
| jbresnah | in the current state of OS trasnfers is a sort of second class operation of storage | 20:05 |
| jbresnah | there is not end to end management | 20:05 |
| jbresnah | this would look to solve that | 20:05 |
| jbresnah | http://tropicaldevel.files.wordpress.com/2013/04/the_wild_west.png | 20:05 |
| jbresnah | versus | 20:06 |
| jbresnah | http://tropicaldevel.files.wordpress.com/2013/04/tamed_west.png | 20:06 |
| jbresnah | sort of show the idea | 20:06 |
| jbresnah | are people generally familiar with the links in the blue print? | 20:06 |
| ameade | i've read through them | 20:07 |
| jbresnah | cool | 20:07 |
| jbresnah | and we had a meeting at the summit on the topic | 20:07 |
| jbresnah | iccha, ameade, nikhil, and rosmaita were all there | 20:07 |
| nikhil | jbresnah: i like your diagram | 20:07 |
| jbresnah | on use case i want to state really quick came up from the earlier meeting about cloning | 20:08 |
| nikhil | read through most of your use cases, looks pretty solid | 20:08 |
| nikhil | hoping everyone else adds stuff too | 20:08 |
| jbresnah | in that we outlined the need for the a glance to glance transfer of an image with its metadata | 20:08 |
| nikhil | jbresnah: +1 | 20:08 |
| jbresnah | to close to other regions | 20:08 |
| jbresnah | i see this servicing fitting in there like this: | 20:08 |
| jbresnah | an async worker would call out to it to handle the transfer from storage system to storage system | 20:08 |
| jbresnah | instead of having glance try to handle that work load itself | 20:09 |
| jbresnah | once that worker was notified by the transfer service of completion it would continue to its next job of updating metadata etc | 20:09 |
| jbresnah | does that make sense as a use case? | 20:09 |
| iccha__ | yeah makes sense | 20:10 |
| ameade | how would the notification happen? | 20:10 |
| jbresnah | right, i am not sure about that just yet | 20:11 |
| jbresnah | what i have outlined right now is poll based | 20:11 |
| nikhil | jbresnah: ameade guess in that particular case notification is handed over to glance? | 20:11 |
| jbresnah | something like that | 20:11 |
| ameade | ah ok | 20:11 |
| jbresnah | which goes into the next agenda point | 20:11 |
| jbresnah | feedback | 20:11 |
| iccha__ | https://blueprints.launchpad.net/glance/+spec/async-glance-workers ? | 20:11 |
| jbresnah | any thoughts, specific or general? | 20:11 |
| nikhil | jbresnah: do you feel the need for managing transfers | 20:11 |
| nikhil | just an extension to what ameade was saying | 20:12 |
| nikhil | rosmaita: and I were discussing a bit on the async workers | 20:12 |
| jbresnah | what do you mean by manage? | 20:12 |
| nikhil | and it kinda makes sense to have a queue based system for that | 20:12 |
| jbresnah | i think the trasnfer should be managed by a service that makes sure it properly completes and does not over/under consume its provisioned resources | 20:12 |
| nikhil | if you'r polling then we need a managed state of the transfer | 20:12 |
| jbresnah | ah, ok | 20:13 |
| jbresnah | so from glance | 20:13 |
| nikhil | something like qonos | 20:13 |
| jbresnah | glance would be a client to this service | 20:13 |
| nikhil | https://github.com/rackspace-titan/qonos | 20:13 |
| jbresnah | an async worker could poll | 20:13 |
| jbresnah | or there could be some contact point back (like a tempurl) for completion notification | 20:13 |
| ameade | callbacks would be nice but nothing really has that tech in place | 20:14 |
| jbresnah | i would prefer that there is an PI boundry between this service and glance | 20:14 |
| jbresnah | *A*PI | 20:14 |
| jbresnah | i would not like them to share a messaging queue, for example | 20:15 |
| nikhil | ah | 20:15 |
| jbresnah | tho i am open to discuss that | 20:15 |
| iccha__ | yes we want it to be indepedent from glance | 20:15 |
| jbresnah | iccha: I agree | 20:15 |
| nikhil | jbresnah: i think that would be good to keep this as independent as possible | 20:15 |
| jbresnah | ok cool | 20:15 |
| nikhil | like APIs | 20:16 |
| jbresnah | so on that point... should this effort be part of the glance project? in the summit unconference we decided that it should be its own new project | 20:16 |
| jbresnah | and hope for incubation | 20:16 |
| jbresnah | any new thoughts there? | 20:16 |
| markwash | so, how would the transfer service affect how clients work with openstack | 20:16 |
| jbresnah | markwash: any thoughts? | 20:16 |
| nikhil | +1 for new | 20:16 |
| markwash | like, clients that want to upload data to glance or swift | 20:16 |
| nikhil | markwash: which client? | 20:17 |
| jbresnah | markwash: well, i think backward compat will be there | 20:17 |
| markwash | sure, but with the new approach, how would it work? | 20:17 |
| jbresnah | markwash: so the traditional means would still happen | 20:17 |
| jbresnah | right, so i have a use case for that | 20:17 |
| jbresnah | getting it... | 20:17 |
| jbresnah | https://etherpad.openstack.org/transfer_workflow | 20:18 |
| jbresnah | basic download sort of covers that | 20:18 |
| jbresnah | the idea would be that a user would form a fileurl | 20:18 |
| jbresnah | and find a transfer service that can deal with such a url | 20:18 |
| rosmaita | (don't want to interrupt, i have a thought about where this project should live, will share later) | 20:18 |
| jbresnah | and then contact the store that galnce is using to get a url, and find a transfer service for it | 20:18 |
| jbresnah | so a 4 tuple is needed | 20:19 |
| jbresnah | source url, source service, dest url, dest service | 20:19 |
| jbresnah | source service can == dest service | 20:19 |
| jbresnah | in which case it ultimately looks like the service is doing a managed 2 party up/download | 20:19 |
| jbresnah | does that make sense? | 20:19 |
| jbresnah | rosmaita: please tell! | 20:20 |
| jbresnah | markwash: does that sound too heavy weight? | 20:20 |
| rosmaita | well, this is from our qonos experience ... | 20:20 |
| rosmaita | oslo is not appropriate because you want a service not a lib | 20:21 |
| markwash | it sounds kinda heavy, I'm wondering about "killer" use cases | 20:21 |
| rosmaita | but an incubator project is going to be a pain to manage | 20:21 |
| nikhil | jbresnah: we prolly won't need source url for upload and dst for download? (wanna make sure we'r on the same page) | 20:21 |
| rosmaita | if you could find a nice PTL, you could incubate the project in, say, i don't know, glance | 20:21 |
| rosmaita | do the engineering so it can easily be detached | 20:21 |
| rosmaita | but build it in glance | 20:22 |
| markwash | I'd have to go to the TC about that probably | 20:22 |
| rosmaita | that way it will get into the community earlier | 20:22 |
| markwash | I don't think I have the power to redefine the scope of glance | 20:22 |
| jbresnah | rosmaita: so devel under glance with the intent to break away? | 20:22 |
| jbresnah | rosmaita: that was what was discuss for keystone and quotas IIRC | 20:22 |
| rosmaita | markwash: that would be ok, there needs to be a place for small projects to incubate | 20:23 |
| jbresnah | markwash, nikhil: I am not forgetting about the killer use case thread btw | 20:23 |
| rosmaita | so maybe a new "project" project, i don't know | 20:23 |
| jbresnah | rosmaita: here is my take on that: pragmatically I am completely fine with that | 20:23 |
| rosmaita | but if john does glance-useful stuff to start with, it would make sense to start dev in glance | 20:23 |
| jbresnah | however, to me it shows that the incubation process might be broken | 20:23 |
| rosmaita | jbreshah: yes, depends where you want to put your efforts now, fix incubation process or get started on xfer service | 20:24 |
| jbresnah | rosmaita: I guess that is a good point. at first it is all glance useful stuff | 20:24 |
| jbresnah | heh | 20:24 |
| rosmaita | i think so, this is a markwash call, though | 20:24 |
| * jbresnah would prefer to not fix incubation ;-) | 20:24 | |
| jbresnah | markwash: ok lets get back to killer use case | 20:25 |
| nikhil | jbresnah: to me it sounds like whether we want to tie this closely to glance xfer or find storage xfer use cases in general | 20:25 |
| jbresnah | markwash: or first use case | 20:25 |
| jbresnah | what about that cloning issue? | 20:25 |
| jbresnah | it is sort of the perfect starting point | 20:25 |
| jbresnah | because it is by nature a 3rd party transfer | 20:25 |
| jbresnah | the client says to glance 'trasnfer this image from you, to another glance' | 20:25 |
| jbresnah | and then it leaves | 20:25 |
| jbresnah | for glance to do that right it needs to monitor the trasnfer, restart where needed, verify success etc etc | 20:26 |
| jbresnah | all these things are what this transfer service wants to do | 20:26 |
| jbresnah | *and* | 20:26 |
| jbresnah | in the case of the science community | 20:26 |
| jbresnah | that wants 1 upload and then a broadcast of the image to many clouds | 20:26 |
| jbresnah | you may even want to negotation protocol (bit torrent, some wide area, etc) | 20:27 |
| jbresnah | so that cloning case is really a great starting point for this | 20:27 |
| jbresnah | thoughts? | 20:27 |
| *** esheffield has joined #openstack-meeting-alt | 20:27 | |
| iccha__ | i know it is difficult to find places for smaller projects, but i am not a 100 | 20:28 |
| iccha__ | % convinced that it should belong to glance | 20:28 |
| nikhil | i'm not sure where glance is heading, though from a HPC perpective and the use case that you just linked it makes sense to abstract out the transfer based on the deployer needs | 20:28 |
| ameade | cloning case makes sense to me, esp if we are starting in glance | 20:28 |
| jbresnah | nikhil: well hpc is one example | 20:28 |
| nikhil | jbresnah: esp when doing multi day longing transfers | 20:28 |
| jbresnah | in every cloning case there is a trasnfer | 20:28 |
| jbresnah | that should be managed properly | 20:28 |
| ameade | the generic service doesnt belong in glance but if we are only doing glance use cases at first then it makes sense | 20:28 |
| jbresnah | ameade: that is what i am pitching | 20:29 |
| iccha__ | how heavy would it end up being? | 20:29 |
| jbresnah | ameade: Well put | 20:29 |
| jbresnah | iccha: I am hoping to make it modular | 20:29 |
| jbresnah | so a first cut would have single set of plug ins | 20:29 |
| jbresnah | to address that use case | 20:29 |
| markwash | I'm just seeing a lot of alternatives to the transfer service for each "killer" use case I can come up with | 20:29 |
| jbresnah | markwash: ex? | 20:29 |
| markwash | so for example, efficiency by having the two endpoints talking directly to each other | 20:30 |
| markwash | that's what the expose-locations thing is about | 20:30 |
| jbresnah | sure... but i would argue that is the trasnfer service case where source service == dest service | 20:30 |
| jbresnah | in tat case it would effectively be a managed wget | 20:31 |
| jbresnah | or some such | 20:31 |
| jbresnah | where the client can walk away and check back later | 20:31 |
| jbresnah | ...doesnt have to have full privaledegs | 20:31 |
| jbresnah | ...doesnt have to baby sit/restart on failure | 20:31 |
| jbresnah | etc | 20:31 |
| jbresnah | effectively, the way to think of this transfer service is something that wraps a client to make sure it does the trasnfer right | 20:32 |
| markwash | I don't completely follow src service == dest service | 20:32 |
| jbresnah | the rest is an implementaion detail | 20:32 |
| jbresnah | i could say to a single transfer service 'download http://xxxx to file://yyyy' | 20:32 |
| jbresnah | and it would manage that transfer | 20:33 |
| jbresnah | does that make sense? | 20:33 |
| markwash | yeah | 20:33 |
| jbresnah | i see those as the first use cases | 20:33 |
| jbresnah | take the arch where nova-compute nodes mount a SAN for instance storage | 20:34 |
| jbresnah | and 1 machine is dedicated for transfering images to it | 20:34 |
| jbresnah | that machine could do what i said above | 20:34 |
| jbresnah | only it has a global pitcure so it can schedule them nicely | 20:34 |
| jbresnah | and make sure the restart on error | 20:34 |
| jbresnah | etc | 20:34 |
| markwash | so suppose I'm doing "transfer swift://region1/foo/bar swift://region2/foo/bar" | 20:34 |
| nikhil | jbresnah: i think you could extend it a bit here and say | 20:34 |
| *** ashwini has joined #openstack-meeting-alt | 20:34 | |
| ameade | can we talk more about how this would be implemented within glance for the cloning use case? so that it's clear and we could maybe agree on it | 20:35 |
| markwash | I'm guessing in the ideal case I'd want the transfer to be happening directly between nodes on the rings of each swift deployment | 20:35 |
| nikhil | if you want to transfer http:xxx to list[url1, url2, url3 ...] | 20:35 |
| jbresnah | ameade: i think that is a good idea | 20:35 |
| jbresnah | pushing on that use case might make the most sense for clarity | 20:35 |
| ameade | just think that if we do that we can get started too | 20:35 |
| jbresnah | markwash: probably yes | 20:35 |
| nikhil | ameade: guess the dialogue is whether it should be in glance or not | 20:36 |
| jbresnah | ameade: good point | 20:36 |
| nikhil | from what i see in markwash's concern | 20:36 |
| jbresnah | nikhil: true, and that is a practical use case at hand | 20:36 |
| jbresnah | markwash: so, if we talk about that use case | 20:36 |
| jbresnah | markwash: and how we would acco,mplish it within glance | 20:36 |
| jbresnah | i agrue that the glance code would look a lot like an image trasnfer service | 20:36 |
| jbresnah | (especially if you let me write it hehehe) | 20:37 |
| * markwash is unfortunately a bit distracted at the moment | 20:37 | |
| ameade | yeah we have to implement it somehow, we would just do it with the fact it could eventually break out into the transfer service in the future | 20:37 |
| markwash | can we start this out as an apache-licensed (2.0) open source project on its own? | 20:37 |
| jbresnah | markwash: i am open to anything | 20:38 |
| markwash | and then look at optionally using it in glance? | 20:38 |
| jbresnah | markwash: but naother apporach is to start working on the cloning case, with this in mind | 20:38 |
| jbresnah | and see how much sense it makes to break it out | 20:38 |
| rosmaita | +1 cloning | 20:38 |
| jbresnah | cause really... if we work on this and the cloning case at the same time, there will be work overlap | 20:38 |
| ameade | +1 that work has to be done anyways | 20:38 |
| jbresnah | right | 20:38 |
| jbresnah | i think that is the most efficient way to spend time | 20:39 |
| jbresnah | it has the downside that ineviitably it will be more tightly married to glance then is idea | 20:39 |
| nikhil | jbresnah: +1 to cloning | 20:39 |
| jbresnah | iccha: do you have thoughts there? | 20:39 |
| markwash | isn't this just an optimization to the cloning work? | 20:39 |
| jbresnah | i would say a generalization | 20:39 |
| markwash | its just a different way of saying "download image X" on the target service | 20:39 |
| jbresnah | with the potential for a lot of optimization | 20:39 |
| ameade | this thought guides the impl | 20:40 |
| nikhil | we need a cloning data transfer management anyhu | 20:40 |
| jbresnah | markwash: i can see looking at it that way sure | 20:40 |
| iccha__ | if we are going the glance route, i would like to be as modular as possible.. a separate node, etc because currently glance nodes designed to be more lightweight etc.. | 20:40 |
| jbresnah | especially when coupled with the direct_url business | 20:40 |
| jbresnah | iccha: agreed | 20:40 |
| jbresnah | markwash: what you are sayibn gis true. any effective use case we could come up with could also be solved with a combination of cloning and direct_url exposure | 20:41 |
| jbresnah | i think anyway | 20:41 |
| markwash | perhaps I'm just being a bit dense (and I'm happy if people want to try to enlighten me as forcefully as necessary) | 20:41 |
| jbresnah | but... that would be a way to work around functionality instead of supporting it in a first class way, IMHO | 20:42 |
| markwash | but I feel a bit like this is trading a bird in the hand for a bird in the bush | 20:42 |
| markwash | wrt the cloning work | 20:42 |
| jbresnah | markwash: can you explain a bit more? | 20:42 |
| ameade | well lets say we did the cloning work seperate | 20:42 |
| ameade | then the first step for this service could be transforming that work into the service | 20:42 |
| markwash | bird in hand -> the blueprint and design approach we discussed in the previous meeting | 20:42 |
| markwash | for cloning | 20:42 |
| markwash | we have a pretty low level view the design for that, which means there's more certainty and more momentum | 20:43 |
| nikhil | markwash: we need a service to handle data transfer anyway | 20:43 |
| markwash | nikhil: the current plan involves glance as that service | 20:43 |
| markwash | for the cloning use case | 20:44 |
| jbresnah | markwash: async workers too? | 20:44 |
| markwash | so maybe I need to think more about the "first class" approach to using this | 20:44 |
| jbresnah | markwash: so it is fair point to say that the cloning effort could be done faster and with less architectural high mindedness if we just do it | 20:44 |
| iccha__ | the transfer service is a bit different from cloning blueprint, it is solving a different problem | 20:44 |
| jbresnah | markwash: but it is also fair to say that there will be a ton of overlap in code | 20:44 |
| markwash | would you just say "transfer glance://region1/abcd glance://region2/" ? | 20:45 |
| *** enigma2 has quit IRC | 20:45 | |
| nikhil | iccha__: just abstraction in teh initial phase, no? | 20:45 |
| jbresnah | iccha: agreed. but the cloning work shares overlap of a subset of what it is solving | 20:45 |
| markwash | but I can also support the current cloning plan with just eventlet threads running on existing glance api nodes | 20:45 |
| jbresnah | iccha: IOW if the xfer service existed, the cloning work could be more easily done by just using it. | 20:45 |
| iccha__ | what was decided in cloning meeting? the stores transfer content to each other? | 20:46 |
| jbresnah | markwash: ummm | 20:46 |
| jbresnah | markwash: you can | 20:46 |
| jbresnah | markwash: but you will need to deal with failures | 20:46 |
| markwash | iccha__: that would just be an optimization, normal case is glance2glance | 20:46 |
| jbresnah | markwash: overlaoding the NIC of those api nodes | 20:46 |
| jbresnah | etc | 20:46 |
| nikhil | markwash: you sure you wanna run multiple threads on glance api nodes for public API glance nodes? | 20:47 |
| markwash | jbresnah: I agree its not ideal, but if you're just testing or at a small scale, it works fine | 20:47 |
| markwash | nikhil: I definitely do *not* want to do that | 20:47 |
| jbresnah | markwash: if this were done inside of the cloning work, i think the results would be the same, only there would be more points of abstraction etc that would seem not needed to just the cloning work | 20:47 |
| markwash | but some folks with small scale might | 20:47 |
| markwash | and would enjoy not having to deploy new components | 20:47 |
| nikhil | hmm | 20:47 |
| ameade | my concern is that this logic gets all over the inside of glance and is a nightmare to move towards this service | 20:47 |
| jbresnah | the service could share process space with api and still have good points of abstraction at first | 20:48 |
| markwash | ameade: its really easy though | 20:48 |
| ameade | markwash: until we add a million patches for error cases | 20:48 |
| nikhil | markwash: guess the basic question is which is more flexibly for scale? scale up and scale down? | 20:48 |
| jbresnah | ameade: i would worry about that too | 20:48 |
| markwash | if you want the xfer service to do the data transfer, you just use it instead of a manual download and upload | 20:48 |
| markwash | if you want the xfer service to do both data and metadata, then you just work completely outside the clone code as we discussed it earlier | 20:49 |
| nikhil | markwash: agree | 20:49 |
| jbresnah | markwash: i want to get a consise feel for your concern | 20:49 |
| markwash | nikhil: its not about scale up or down here. . the lightweight eventlet one would never scale up | 20:49 |
| markwash | nikhil: when you want to scale up, you would select a different async processing driver | 20:50 |
| jbresnah | markwash: you are worried that the code does not belong in glance as starting point. or you think cloning should not use it at all? | 20:50 |
| markwash | I think if this existed, it would make sense to do cloning using it | 20:50 |
| jbresnah | markwash: Ideally i would like to get consensus on having cloning be a good first use case | 20:50 |
| jbresnah | be it where the code initially lives or not | 20:50 |
| jbresnah | | 3) Consensus on a basic use case (fully documented and approved later) | 20:51 |
| jbresnah | from my optimistic set of goals | 20:51 |
| jbresnah | 4) Consensus on part of Glance or a new project | 20:51 |
| ameade | +1, we have 10 min to know our next steps | 20:51 |
| jbresnah | can we get a vote on #3? | 20:51 |
| markwash | again, maybe I'm just being dense, but I want to understand the advantages more before we go all in on the xfer service as a blocker for cloning | 20:51 |
| jbresnah | oh, not a blocker | 20:52 |
| jbresnah | the other way around | 20:52 |
| jbresnah | i would like to use the cloning use case as a way to show the benefits of xfer | 20:52 |
| jbresnah | not block it | 20:52 |
| markwash | so then cloning has to come first, because I don't want to say "you can't have cloning unless you deploy a transfer service component" | 20:53 |
| jbresnah | so, perhaps a quick impl with less features could be done | 20:53 |
| *** flaper87 has joined #openstack-meeting-alt | 20:53 | |
| jbresnah | markwash: i understand that concern | 20:53 |
| flaper87 | I guess I got here late | 20:53 |
| nikhil | so we'r doing both then? | 20:53 |
| flaper87 | :( | 20:53 |
| flaper87 | sorry | 20:53 |
| nikhil | small impl for cloning and xfer service | 20:53 |
| iccha__ | i see markwash's concerns about overloading glance with responsibility of data transfer. it is agreed that cloning can be enhanced by data transfer service, but i guess markwash would not like it to be dependent on it | 20:54 |
| nikhil | because, i really don't want something to block cloning, please | 20:54 |
| jbresnah | markwash: so the worry is that if cloning is the main use case, then you worry its effort will be delayed? | 20:54 |
| * jbresnah nod iccha | 20:54 | |
| ameade | jbresnah: what was the other potential starting point? | 20:54 |
| markwash | jbresnah: yes, because I don't know what saying "cloning == xfer service" does to our previous cloning plans | 20:54 |
| jbresnah | the nova compute case where nodes mount a SANs | 20:54 |
| jbresnah | i find it less compeling because cloning seems so perfect for me | 20:55 |
| jbresnah | but it still has legs | 20:55 |
| markwash | what about region-to-region swift transfers. . is that a possible first use case? | 20:55 |
| jbresnah | especialy when talking about a boot of 1000s of instances | 20:55 |
| nikhil | markwash: +1 | 20:55 |
| jbresnah | markwash: isn't that cloning? | 20:55 |
| nikhil | jbresnah: i like markwash's use case | 20:55 |
| nikhil | yes but store level | 20:55 |
| markwash | jbresnah: I don't think so? | 20:55 |
| nikhil | and not blocking glance cloning | 20:55 |
| markwash | jbresnah: suppose I am running something other than swift as my store | 20:56 |
| jbresnah | swift to swift + import/export == cloning? | 20:56 |
| jbresnah | markwash: ok, i can see that | 20:57 |
| iccha__ | 3 minutes | 20:57 |
| markwash | the way we talked earlier, I thought cloning was a glance to glance kind of thing | 20:57 |
| jbresnah | markwash: we may have to table this... | 20:57 |
| jbresnah | #3 and #4 | 20:57 |
| * markwash is remembering quotes from requiem for a dream | 20:57 | |
| jbresnah | ouch | 20:57 |
| jbresnah | i hate remebering that movie | 20:57 |
| jbresnah | i curl up into a fetal position and cry | 20:57 |
| markwash | me too | 20:57 |
| jbresnah | great movie, but ... wow | 20:57 |
| jbresnah | anyway | 20:58 |
| jbresnah | | 1) A list of concerns to be addressed (either at the end or in the future). | 20:58 |
| jbresnah | i think i can pull a bunch of those from the transcript | 20:58 |
| jbresnah | | 2) A list of parties interested in working on this (not a time commitment) | 20:58 |
| jbresnah | how about that part | 20:58 |
| jbresnah | what is the general interest level | 20:58 |
| ameade | jbresnah: what if the transfer service started off seperate as a way to replace the image upload handler code in nova? | 20:58 |
| jbresnah | coding, designing, reviewing, etc? | 20:58 |
| jbresnah | ameade: hmmm | 20:58 |
| jbresnah | ameade: that makes sense | 20:59 |
| nikhil | jbresnah: markwash have we decided to keep it separate from glance or in it? | 20:59 |
| jbresnah | ameade: and download | 20:59 |
| jbresnah | something specific like that is good | 20:59 |
| ameade | jbresnah: yeah very easily | 20:59 |
| jbresnah | i recall we talked about that briefly once | 20:59 |
| markwash | nikhil: I'd like for it to start seperately from glance | 20:59 |
| ameade | jbresnah: yeah really early on | 20:59 |
| jbresnah | nod | 20:59 |
| jbresnah | ok | 20:59 |
| jbresnah | so it looks like, separate from glance | 21:00 |
| jbresnah | votes? | 21:00 |
| nikhil | works for me | 21:00 |
| iccha__ | i like the idea of store to store transfer going first so it be used in image cloning if needed sooner | 21:00 |
| nikhil | +1 | 21:00 |
| * flaper87 will comment later | 21:00 | |
| jbresnah | iccha, i like that | 21:00 |
| nikhil | can we do #vote or something? | 21:00 |
| jbresnah | oh right, sorry | 21:00 |
| jbresnah | ummm how do i do that? | 21:00 |
| nikhil | not sure | 21:00 |
| * markwash doesn't know either. . . | 21:00 | |
| flaper87 | jbresnah: #startvote | 21:01 |
| jbresnah | #startvote outside of glance | 21:01 |
| openstack | Unable to parse vote topic and options. | 21:01 |
| jbresnah | #startvote own_project | 21:01 |
| openstack | Unable to parse vote topic and options. | 21:01 |
| flaper87 | jbresnah: #startvote Should we vote now? Yes, No, Maybe | 21:01 |
| flaper87 | #link http://ci.openstack.org/meetbot.html | 21:01 |
| flaper87 | :) | 21:01 |
| nikhil | #vote Yes | 21:02 |
| markwash | #vote maybe | 21:02 |
| * markwash giggles | 21:02 | |
| flaper87 | jbresnah: has to start the vote :D | 21:02 |
| jbresnah | heh | 21:02 |
| iccha__ | #vote yes | 21:02 |
| *** markwash has left #openstack-meeting-alt | 21:02 | |
| westmaas | bold move | 21:03 |
| jbresnah | #startvote Should the transfer service be its own project? Yes, No, Maybe | 21:03 |
| openstack | Begin voting on: Should the transfer service be its own project? Valid vote options are Yes, No, Maybe. | 21:03 |
| openstack | Vote using '#vote OPTION'. Only your last vote counts. | 21:03 |
| *** markwash has joined #openstack-meeting-alt | 21:03 | |
| nikhil | #vote yes | 21:03 |
| ameade | #vote apathetic | 21:03 |
| openstack | ameade: apathetic is not a valid option. Valid options are Yes, No, Maybe. | 21:03 |
| nikhil | lol | 21:03 |
| flaper87 | #vote yes | 21:03 |
| ameade | #vote apathetic | 21:03 |
| openstack | ameade: apathetic is not a valid option. Valid options are Yes, No, Maybe. | 21:03 |
| jbresnah | ameade maybe will be apathetic for now | 21:03 |
| markwash | what was the vote again? sorry, user error | 21:04 |
| jbresnah | #vote maybe | 21:04 |
| nikhil | #vote ameade | 21:04 |
| openstack | nikhil: ameade is not a valid option. Valid options are Yes, No, Maybe. | 21:04 |
| ameade | #vote maybe | 21:04 |
| jbresnah | markwash: ? I am pretty sure you are a yes.... | 21:04 |
| nikhil | we'r voting on Should the transfer service be its own project? | 21:04 |
| markwash | I accidentally left the room right when you said "startvote" | 21:04 |
| nikhil | btw | 21:04 |
| markwash | #vote yes | 21:04 |
| nikhil | markwash: ^^ | 21:04 |
| jbresnah | For next steps i will type up the two potential use cases and et a vote on them | 21:05 |
| flaper87 | jbresnah: you have to call #endvote now | 21:05 |
| jbresnah | #action jbresnah doc up cloning and simple nova-compute up/down use cases | 21:05 |
| jbresnah | #endvote | 21:05 |
| openstack | Voted on "Should the transfer service be its own project?" Results are | 21:05 |
| openstack | Maybe (2): ameade, jbresnah | 21:05 |
| openstack | Yes (3): nikhil, markwash, flaper87 | 21:05 |
| nikhil | where's iccha__ ? | 21:05 |
| markwash | I want to say, we can look at bringing it into glance after its been on its own for a while too | 21:05 |
| jbresnah | cool | 21:06 |
| markwash | as a way to unbreak the incubation process (if necessary and expedient) | 21:06 |
| iccha__ | i am here i guess i voted before it started | 21:06 |
| flaper87 | markwash: +1 | 21:06 |
| jbresnah | +1 | 21:06 |
| jbresnah | markwash: that makes sense | 21:06 |
| flaper87 | 23:02:32 iccha__ | #vote yes | 21:06 |
| iccha__ | +1 | 21:06 |
| nikhil | so 4 yes-es | 21:06 |
| jbresnah | so, ho about a quick statement of interest in the project? | 21:06 |
| nikhil | i just want some tangible outcome | 21:06 |
| * markwash isn't sure how something necessary wouldn't be expedient, but hopes nobody noticed | 21:06 | |
| nikhil | else i'd voted maybe | 21:06 |
| jbresnah | | 2) A list of parties interested in working on this (not a time commitment) | 21:07 |
| nikhil | jbresnah: interested | 21:07 |
| flaper87 | jbresnah: me | 21:07 |
| jbresnah | in terms of design, coding, peripheral, etc | 21:07 |
| jbresnah | or just 'interested' works too | 21:07 |
| ameade | interested | 21:07 |
| iccha__ | interested | 21:07 |
| jbresnah | might be hard to say at this point | 21:07 |
| markwash | jbresnah: me, especially to get an early high level view of the project and where you'd want it to go | 21:07 |
| nikhil | design, coding for sure | 21:07 |
| jbresnah | great! | 21:08 |
| jbresnah | ok i think we can call it | 21:08 |
| jbresnah | 8 minutes over | 21:08 |
| ameade | jbresnah: lemme know if you wanna talk more about the image upload code | 21:08 |
| nikhil | nice meeting! | 21:08 |
| jbresnah | markwash: let me know if you ever have questions or a good idea on how to transfer some thoughts etc | 21:08 |
| jbresnah | nd ameade | 21:08 |
| ameade | nikhil: it was very kind | 21:08 |
| jbresnah | ameade: i definitely will | 21:09 |
| jbresnah | ameade: and probably soon | 21:09 |
| nikhil | :) | 21:09 |
| ameade | jbresnah: cool, the more i think about it the more it makes sense | 21:09 |
| jbresnah | nikhil: thanks! | 21:09 |
| nikhil | thanks too! | 21:09 |
| jbresnah | #endmeeting | 21:09 |
| *** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack" | 21:09 | |
| openstack | Meeting ended Mon May 6 21:09:53 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:09 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/transfer_service/2013/transfer_service.2013-05-06-20.01.html | 21:09 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/transfer_service/2013/transfer_service.2013-05-06-20.01.txt | 21:09 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/transfer_service/2013/transfer_service.2013-05-06-20.01.log.html | 21:09 |
| *** ewindisch has quit IRC | 21:13 | |
| *** flaper87 has left #openstack-meeting-alt | 21:14 | |
| *** ewindisch has joined #openstack-meeting-alt | 21:15 | |
| *** ewindisch has quit IRC | 21:34 | |
| *** djohnstone has quit IRC | 21:34 | |
| *** demorris has quit IRC | 21:43 | |
| *** sacharya has quit IRC | 21:43 | |
| *** RajeshMohan has quit IRC | 21:53 | |
| *** RajeshMohan has joined #openstack-meeting-alt | 21:53 | |
| *** RajeshMohan has quit IRC | 21:59 | |
| *** RajeshMohan has joined #openstack-meeting-alt | 21:59 | |
| *** RajeshMohan has quit IRC | 21:59 | |
| *** RajeshMohan has joined #openstack-meeting-alt | 22:00 | |
| *** lifeless has quit IRC | 22:20 | |
| *** SergeyLukjanov has quit IRC | 22:21 | |
| *** amyt has quit IRC | 22:26 | |
| *** ashwini has quit IRC | 22:30 | |
| *** vipul is now known as vipul|away | 22:33 | |
| *** vipul|away is now known as vipul | 22:34 | |
| *** enigma1 has joined #openstack-meeting-alt | 22:37 | |
| *** enigma2 has joined #openstack-meeting-alt | 22:40 | |
| *** enigma1 has quit IRC | 22:40 | |
| *** jcru has quit IRC | 22:41 | |
| *** bdpayne has quit IRC | 23:00 | |
| *** bdpayne has joined #openstack-meeting-alt | 23:01 | |
| *** esheffield has quit IRC | 23:07 | |
| *** lifeless has joined #openstack-meeting-alt | 23:08 | |
| *** sacharya has joined #openstack-meeting-alt | 23:09 | |
| *** markwash has quit IRC | 23:28 | |
| *** lifeless has quit IRC | 23:35 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
