20:01:45 <n0ano> #startmeeting
20:01:47 <openstack> Meeting started Thu Mar 29 20:01:45 2012 UTC.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:02:31 <n0ano> maoy, do you have an open for today, I don't have anything specific myself.
20:02:48 <maoy> could someone give me the link for previous meetings log?
20:03:18 <maoy> I'd like to discuss how to merge/collaborate on related orchestration blueprints
20:03:35 <mikeyp> #link http://wiki.openstack.org/Orchestration/MeetingLogs
20:03:42 <maoy> especially at the summit
20:04:01 <n0ano> #topic orchestration blueprints for the Summit
20:04:57 <maoy> there is this one https://blueprints.launchpad.net/nova/+spec/transaction-orchestration
20:05:13 <n0ano> I know that sriram (looks like he won't make the meeting today) is proposing a BP, then there's that one, are the any others?
20:05:56 <maoy> and also this one proposed from me
20:05:57 <maoy> https://blueprints.launchpad.net/nova/+spec/task-management
20:06:16 <maoy> In the wiki from this bp: http://wiki.openstack.org/TransactionalTaskManagement
20:06:26 <maoy> several related BPs are listed
20:06:58 <maoy> mikeyp: thx
20:07:27 <n0ano> indeed, seems like we should try an consolidate the orchestration BPs into one discussion at the Summit
20:07:35 <mikeyp> and of course, the main 'orchestration link on the wiki http://wiki.openstack.org/NovaOrchestration
20:08:10 <maoy> do we know how long timeslot we'll get at the summit?
20:08:28 <maoy> there seems to be way too many proposals for the summit
20:08:55 <mikeyp> has anyone even proposed something for the summit yet - I haven't
20:08:59 <n0ano> I'm no expert, who/how is the summit schedule decided, does anyone know?
20:09:25 <n0ano> sriram definitely wanted to propose something for the summit, it's a pity he can't be here today
20:09:31 <maoy> http://summit.openstack.org/sessions/view/69
20:10:01 <maoy> I wanted to propose one, but after I saw this one I want to work with folks here together
20:11:14 <mikeyp> we need to poporse a summit session to get feedback, and we also need to spend time before that consolidating the existing work and ideas
20:11:38 <maoy> absolutely.
20:11:48 <maoy> has anyone started coding towards the bps?
20:12:16 <n0ano> looks like the session is proposed, what else needs to be done to get it on the schedule
20:12:44 <mikeyp> sriram said he was going to propose a branch soon
20:13:16 <n0ano> he said hopefully by the end of this week he'd create the branch
20:14:54 <maoy> that's promising
20:16:46 <mikeyp> I believe there are two pieces to this
20:16:59 <mikeyp> 1. the transaction management / workflow service
20:17:19 <mikeyp> 2. changes to Nova to leverage that service
20:17:24 <mikeyp> make sense ?
20:18:07 <n0ano> maybe, are seeing this as a new service (ala Glance) or more like just changes to Nova
20:18:10 <maoy> sure
20:18:35 <maoy> It seems to be very nova centric
20:19:20 <mikeyp> was thinking a nova service initially, ala nova-compute, nova-network, et al
20:19:37 <mikeyp> but a higher level service isn't out of the question
20:19:55 <maoy> agree. but making it a separate component seems not a top priority to me
20:20:25 <maoy> but no doubt that it will be utilized by many sub nova components, such as nova-compute, nova-sched, nova-volume
20:20:52 <n0ano> I kind of like the idea of a separate component, that compartmentalizes things and makes it potentially usable by different areas.
20:21:28 <mikeyp> my reasoning is mainly driven by how to do this, without having to sync up with the main nova branch all the time during development
20:21:28 <maoy> e.g. right now there are cross component race conditions that not addressed
20:21:30 <n0ano> when you talk about `changes to Nova' isn't that really just defining the APIs to be used?
20:23:07 <mikeyp> n0ano: I think there will be changes within nova to call those api's as well.
20:23:21 <maoy> mikeyp: the devil will be revising current nova code to use the orchestration APIs
20:23:38 <maoy> will have to work closely with nova-core folks on that
20:23:57 <mikeyp> maoy: yup - I agree.
20:24:21 <n0ano> given the right set of APIs (hopefully ones that don't change much) then changes to nova can be done once and further development is in the service
20:24:46 <maoy> i sense some reluctant reaction from them in adopting this idea. nova-core is a big monster with 100K lines of code. :)
20:25:16 <mikeyp> n0ano: maybe - depends on how and where  specific workflows are defined and stored
20:25:46 <n0ano> it's possible that we can move some of the nova-core code into the orchestration service, reduing the size of nova-core (in a perfect world of course)
20:27:16 <mikeyp> what about swift and glance integration ?
20:27:51 <maoy> i'm very unfamiliar with swift and glance. do they have tasks/workflows to orchestrate?
20:27:56 <mikeyp> currently I believe nova calls out to swift for images.
20:28:21 <mikeyp> would that operation now be done from orchestrator ?
20:28:43 <mikeyp> maoy: not really, but they are involved in nova operations
20:28:43 <maoy> I believe it's to the glance image service?
20:28:56 <mikeyp> my bad - meant glance
20:30:16 <maoy> I believe orchestration is best to define control plane state transition. are you saying we want to get involved with the data path of glance as well?
20:30:37 <mikeyp> maoy: definitely not
20:30:46 <n0ano> well, who's driving things then, is nova-core scheduling/creating/destroying tasks, utilizing orchestration services for serialization, or is everything driven through the orchestration service?
20:31:21 <n0ano> (my vision would be the first alternatvie)
20:31:44 <mikeyp> n0ano: that is the question I"m asking
20:32:17 <n0ano> well, to me nova-core does the work, asking for help from orchestration when needed.
20:32:40 <n0ano> That way the orchestration service is also available to other components if they need it.
20:32:53 <maoy> agree.
20:33:46 <maoy> the orchestration service should be purely state management, including workflow progress, status, resource lock management, etc
20:34:14 <maoy> but we'll provide client side APIs to easily utilize the service
20:34:28 <n0ano> that would work for me
20:35:13 <mikeyp> I also agree that is the right approach
20:35:21 <maoy> excellent
20:36:04 <n0ano> #agreed orchestration service provides state management with client side APIs
20:36:43 <maoy> in the wiki I posted, it talked a bit about the APIs. I have a simple, half-baked MySQL based implementation.
20:36:52 <maoy> some APIs make sense, some perhaps don't
20:37:25 <maoy> I was hoping to use ZooKeeper to implement the service side
20:37:29 <n0ano> I think an API discussion would be a good topic at the summit
20:37:48 <maoy> but that'd introduce another new external dependency. not sure if people like it
20:38:54 <n0ano> the counter is why re-invent the wheel, it ZooKeeper does what we want we should use it (note I know nothing about it)
20:39:45 <maoy> API design and where to store orchestration state are great topics to discuss..
20:40:48 <mikeyp> maoy: discuss at the summit ?
20:40:49 <n0ano> #idea add API design and state storage as topics for the orchestration session at the Summit
20:41:08 <maoy> mikepy: yeah. that's what i meant
20:41:13 <n0ano> I agree
20:41:25 <maoy> of course it's the best if we have something in mind before summit. :)
20:41:45 <n0ano> indeed, some sort of template to start from
20:42:22 <mikeyp> I think another topic is the implementation plan - how we do openheart surgery on nova while folsom development is running full steam ahead
20:42:39 <maoy> absolutely
20:43:01 <maoy> that seems to be the biggest blocker..
20:43:19 <n0ano> #idea implementation plan as session topic
20:43:26 <maoy> we need someone from the nova core team to be onboard
20:43:45 <n0ano> hence the need for a session where we can get wider coverage
20:47:47 <mikeyp> who will update the session proposal - I think sriramhere, because he proposed / has edit permissions
20:48:03 <maoy> agree
20:48:14 <maoy> let's ping him via email..
20:48:22 <n0ano> I'll send sriram an email and see if he's willing, shouldn't be a problem
20:48:54 <maoy> cool
20:48:57 <n0ano> #action sriram to update the Orchestration session proposal
20:49:31 <n0ano> (I won't comment on giving ARs to non-attendees who can't defend themselves :-)
20:51:01 <mikeyp> Also, Sandy metioned the efforts by HP and IBM re: HPC scheduling, and some thoughs from RedHat
20:51:37 <maoy> hopefully orchestration service should be scheduler (algorithm) agnostic
20:51:37 <n0ano> yeah, I saw that, i'd be interested in the details on that but, without Sandy being here ...
20:52:17 <mikeyp> maoy: true, but I'm in the dark about those efforts and ideas.
20:52:31 <maoy> mikeyp: me 2
20:52:39 <maoy> do we have links for those?
20:52:46 <maoy> i didn't see Sandy's email
20:53:03 <n0ano> maoy, I'll forward it to you, but there's not much detail in it.
20:53:12 <maoy> ok cool
20:54:24 <mikeyp> BTW, procedural point: we'r supposed to be using the main list with a prefix of [Orchestration], rather than the independent mailing list
20:54:52 <n0ano> #action n0ano to forward Sandy's email to maoy
20:54:53 <mikeyp> that was decided rounde begninng of the year, I think.
20:55:12 <mikeyp> and other  items for today ?
20:55:16 <n0ano> mikeyp, looks like we missed that, we'll try and be better in the future.
20:55:26 <n0ano> nothing else from me
20:55:43 <maoy> not from me
20:55:47 <maoy> take care guys
20:56:15 <n0ano> OK, let's maybe discuss the details of the Orchestration session in a little more detail next week, think about it in the meantime.
20:57:12 <mikeyp> thats all from me for today.
20:57:24 <n0ano> later everyone
20:57:28 <n0ano> #endmeeting