20:02:34 <n0ano> #startmeeting
20:02:34 <openstack> Meeting started Thu Apr 12 20:02:34 2012 UTC.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:02:54 <n0ano> #topic get ready for the session next week
20:03:21 <n0ano> So, sriramhere (since you did all the work) are we ready for the session next week?
20:03:24 <sriramhere> looks like Ziad has some notes on SpiffWorkflow
20:04:23 <sriramhere> i couldnt make much progress on SWF mock :( - pressure to deliver some work before i take a week off for the summit
20:04:41 <sriramhere> maoy - any updates on ur side?
20:04:55 <sriramhere> Ziad's notes: http://wiki.openstack.org/NovaOrchestration/WorkflowEngines/SpiffWorkflow
20:05:28 <maoy> i'm preparing another session on concurrency
20:05:45 <maoy> but i'd like to present a few slides during the session if possible
20:05:53 <maoy> i mean the orchestration session
20:06:14 <n0ano> I would imagine that should be fine, sriramhere do you have slides you'll present?
20:06:45 <maoy> what's the format of our session?
20:06:50 <maoy> do we have an agenda?
20:06:57 <sriramhere> i am putting some intro/ explaining current thought processes. WIll be done by tomorrow
20:07:09 <n0ano> will you put that in the blueprint
20:07:13 <sriramhere> i would like to talk to you all about what we want to talk during the session
20:07:16 <sriramhere> yes, i will
20:07:35 <sriramhere> we had 3 topics considered/ wanted to be talked about during session
20:07:41 <n0ano> then I think we can use the BP as the guide to the agenda
20:07:46 <sriramhere> stepping back - this is a brainstorming session
20:08:13 <sriramhere> also, my first. can one of u tell me what to expect during the brainstorming session?
20:08:22 <sriramhere> i am using the following link as guideline
20:08:31 <n0ano> agreed, but having a little structure to the discussion is always good.
20:08:39 <sriramhere> https://www.youtube.com/watch?v=GmY4cK_6NKY
20:08:46 <maoy> i only been to one summit before
20:09:18 <maoy> i think if the session chair (leader?) is organized with an agenda, it works much better
20:09:25 <n0ano> me too but we're allowed to be fairly loose
20:09:35 <sriramhere> i like to have an agenda
20:09:45 <sriramhere> that also helps to keep focussed.
20:09:46 <n0ano> hence making sure the BP has the right outline then I think we'll be good
20:09:57 <maoy> ok
20:09:58 <sriramhere> what i am thinking now, ur suggestions d help me
20:10:39 <sriramhere> is - to start with the need for orchestration. though most of us agree, this is to set the tone
20:11:15 <sriramhere> then introduce some of the back ground work. this will include Ziad's and maoys., if any progress i can make on aws swf mock
20:11:34 * vishy jumps in
20:11:42 <sriramhere> then incude the things we want to hash out - api design
20:11:50 <vishy> have you guys considered where the orchestration code will go?
20:11:52 <sriramhere> open up brainstorming
20:12:23 <vishy> (I ask because with volume splitting out it might be nice to have some/all of the code in openstack-common
20:12:26 <n0ano> vishy, not sure we've gone there yet beyond thinking that it'll be part of nova
20:12:28 <sriramhere> u mean branch? general consensus so far is to have a branch
20:13:03 <sriramhere> in terms of project, under nova. a separate sevice
20:13:06 <maoy> vishy, we did talk about the orchestration as a general service independent of nova-core
20:13:12 <vishy> n0ano: it could go into nova branch initiially, but it would be great if it is useful for volume and/or network
20:13:15 <sriramhere> nova-orchestration.
20:13:31 <vishy> that it eventually moves into openstack-common
20:13:36 <vishy> similar to how rpc code is moving now
20:14:03 <vishy> just wanted to put that thought in your heads, didn't mean to derail the meeting.
20:14:06 <vishy> :)
20:14:08 <maoy> 3 components: nova-orch (server side), nova-orch (client library), and modify existing nova code to utilize nova-orch client
20:14:15 <sriramhere> vishy - i am hearing u suggest to keep this away from nova
20:14:18 <n0ano> I like the idea of in the nova branch to begin with, keeping in mind that we might want to split out if it is useful for other projects.
20:14:33 <vishy> maoy: hmm maybe we are discussing different things
20:14:56 <vishy> I'm referring to the state management part of the code
20:15:21 <vishy> as in workflow engine defining the states for a vm for example
20:15:34 <vishy> that part will probably have to be in nova or integrated somehow
20:15:43 <vishy> but it also applies to volumes and networks
20:15:44 <n0ano> I thought that was where the spiff-workflow investigation applied
20:16:04 <vishy> right, but nova-orch with a client library sounds like it is higher level orchestration
20:16:10 <maoy> i think we are talking about the same thing..
20:16:13 <vishy> like using a bunch of services together
20:16:43 <vishy> ah sorry i missed the last part of your sentence: modify existing nova code to utilize nova-orch client
20:16:54 <sriramhere> so u like a nov-orch service, side by side with nova-volume, etc
20:17:00 <vishy> that seems reasonable, as long as you keep it simple
20:17:15 <n0ano> my only concern is would that too heavy weight for what we need
20:17:18 <vishy> I see two approaches
20:17:19 <sriramhere> but would like to keep it in openstakc-common?
20:17:31 <vishy> 1) a totally separate service with a rest-api for state management
20:17:36 <vishy> other servies use it
20:17:47 <vishy> 2) a set of python libraries for state management
20:17:52 <vishy> other services use it
20:18:01 <vishy> i personally would lean towards 2
20:18:10 <vishy> you could always add 1 later
20:18:15 <n0ano> personally, I like 2, maybe think about 1 later if needed
20:18:35 <vishy> if it is going to be 2, openstack-common could be a good place for it to ultimately end up.
20:18:39 <sriramhere> in 2, other services would just include/ use this library?
20:18:46 <vishy> sriramhere: correct
20:19:05 <n0ano> I think we're in violent agreement here
20:19:09 <maoy> I feel 1) is a specific implementation of 2)
20:19:16 <vishy> agreed
20:19:18 <sriramhere> na0no - wait please
20:19:23 <sriramhere> i am just typing
20:19:23 <vishy> and it might be very cool long term
20:19:39 <vishy> StateManagementaaS
20:19:51 <vishy> or OrchestrationaaS
20:19:52 <sriramhere> my only concern is orchestration layter may not sit on top if we need it to
20:20:23 <sriramhere> if we are thinjking aaS, may be 1 is a better solution rt?
20:20:41 <n0ano> I think it's too early to do an aaS, walk before we run
20:20:59 <vishy> n0ano: +1
20:21:13 <sriramhere> i agree, was commenting to vishy's long term names
20:21:46 <maoy> we should dive deeper in the summit, e.g. talk about the actual persistent storage layer for state we manage. e.g. mysql vs zookeeper
20:21:54 <sriramhere> 2 is simple to start with - i agree. i think all agree to that
20:22:16 <sriramhere> but is 2 going to be the end? and if we wan tto go towards1, how difficult would that be ?
20:23:02 <n0ano> If we keep 1 in mind as an option then, hopefully, we won't make design decisions that make transitioning to that difficult
20:23:14 <sriramhere> i like to have the ability to have orchestration running by itself
20:23:47 <maoy> it's very hard to define 1 without having hands-on experience with 2
20:24:02 <sriramhere> n0ano - agreed
20:24:04 <n0ano> comes back to maoy's point that 1 can be used as an implementation for 2
20:24:20 <sriramhere> rather on top of 2?
20:25:10 <n0ano> I see it as there are python APIs we create, they either execute python code (option 2 for now) or call out to a service (option 1 for later)
20:25:11 <sriramhere> ok - looks like the consensus is to start with 2, but keep in mind 1 as an option
20:26:19 <sriramhere> i personally would still servicify it
20:26:53 <sriramhere> it may not be complex, but would like other services consider orch as a service. not library
20:27:41 <n0ano> to me, you call an API and what that API does is arbitrary
20:27:50 <maoy> to make it as a service, you need to decide which functions live on the server, which live on the client.
20:28:12 <maoy> if just having APIs, you can defer that decision. change it without changing the APIs
20:28:29 <sriramhere> and it is better to answer the question sooner than later. else, it might be very difficult to do later
20:28:54 <n0ano> giving us time to get some experience as to what is truly needed
20:29:13 <sriramhere> ok - something the experienced can help here
20:29:23 <maoy> sriramhere: rest service is nothing more than a specific way of remote API call semantics-wise
20:29:25 <sriramhere> wat has been the experience so far - to rip out a library in to a service
20:30:20 <sriramhere> maoy - i agree, and we can start with that. but this would force the other services not to consider this as a library, there by not making themselves too tied
20:30:59 <sriramhere> i mean - just consider that as a rest end point. and it could be a light weight to begin with.
20:31:37 <sriramhere> as long as other services keep thinkint it as a service, we are better off, rt?
20:31:53 <n0ano> I would hope that other services don't care, they want something done and the API does it, that's all that matters, not that it's a service
20:32:05 <maoy> i don't think it matters..
20:32:16 <maoy> n0ano: agree
20:32:33 <maoy> the drawback of API is that is language dependent
20:32:50 <maoy> so you have to use Python. and upgrading is hard
20:33:04 <maoy> not a problem in openstack now since every component is released together, all written in python
20:33:37 <sriramhere> pausing for a moment - what is the difficulty tht i am missing on wrapping a rest end point on these apis?
20:34:38 <n0ano> no difficulty, comes back to I'd like to see something very light weight to begin with before we decide we need an extra service
20:36:04 <sriramhere> ok - everybody else seems to like to stat with 2. i will also go with it then for now.
20:36:43 <n0ano> I think we'll have some good discussions at the session.
20:37:00 <n0ano> Back to the seesion, I see the brief outline of the agenda as:
20:37:06 <n0ano> 1)  Why orchestration is needed
20:37:06 <n0ano> 2)  Background
20:37:06 <n0ano> 3)  Current thoughts (3 topics)
20:37:13 <sriramhere> so, this is another item to add for discussionduring summit
20:37:26 <n0ano> certainly it would be appropriate
20:37:51 <maoy> sounds great
20:38:02 <maoy> do we know which day the session is on?
20:38:21 <n0ano> I curious about that also
20:39:31 <maoy> i guess it's still in flux then
20:39:31 <sriramhere> i dont know tht e - as of yesterday night.
20:39:35 <sriramhere> let me check quickly now
20:39:57 <maoy> hopefully it won't conflict with my other sessionx
20:40:00 <maoy> sessions
20:40:42 <maoy> I guess that's it for today?
20:40:57 <maoy> I'm excited
20:41:07 <n0ano> that's all I have, looking forward to the summit
20:41:28 <sriramhere> action items?
20:41:51 <n0ano> #action sriramhere to finalize the BP
20:41:52 <sriramhere> also , shall we ahve an offline sync by the week end just to make sure we have all ready for the summit?
20:42:07 <n0ano> #action everyone to attend the session
20:42:20 <sriramhere> this will include a slide deck
20:42:38 <n0ano> sriramhere, we're all available via email, when you have the deck ready just send it out and we'll review
20:43:00 <sriramhere> works
20:43:22 <n0ano> in that case, tnx everyone and we'll see you next week.
20:43:31 <sriramhere> 5 pm on tuesday is ours
20:43:31 <maoy> thx. bye
20:43:47 <n0ano> excellent, now we know
20:43:48 <maoy> who did you talk to to get that?
20:43:52 <sriramhere> http://openstack.org/conference/san-francisco-2012/sessions/
20:43:56 <sriramhere> its updated
20:44:27 <sriramhere> no conflicts that we know of now?
20:45:00 <n0ano> I'm certainly good
20:45:06 <maoy> nice. didn't know that link. no conflict from my end
20:45:14 <sriramhere> other sesison is resource rationing in glance
20:45:26 <sriramhere> same time i meant
20:45:27 <sriramhere> ok then.
20:45:40 <sriramhere> thanks, cya all next week
20:45:50 <n0ano> later
20:45:57 <n0ano> #endmeeting