21:02:34 <debo_os> #startmeeting
21:02:35 <openstack> Meeting started Wed Oct 19 21:02:34 2011 UTC.  The chair is debo_os. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:36 * markvoelker lurks because he has to leave in a few minutes
21:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:47 <debo_os> #topic Donabe
21:04:02 <dendrobates> hi danwent
21:04:09 <debo_os> hi Dan!
21:04:11 <danwent> hey
21:04:17 <markvoelker> o/
21:04:25 <debo_os> hi Mark
21:04:39 <mtaylor> danwent: I'm supposed to be working with you on something, aren't I?
21:04:50 <debo_os> #info Agenda
21:05:20 <danwent> mtaylor:  maybe packaging or jenkins releated?  both are things we're working to take care of for quantum
21:05:37 <debo_os> API design issues•	Database layer•	Transactional semantics – should we post the whole topology in 1 shot in a xml chunk or in pieces•	Model driven …. Define primitives for 1) compute 2) network 3) storage•	Plugins for the above primitives. Declarative languages•	Pluggable module•	We choose 1 default one
21:05:50 <debo_os> sorry I cut pasted the agenda too soon
21:07:15 <debo_os> are we the 4 of us here?
21:07:27 <dendrobates> looks like it
21:07:32 <debo_os> :)
21:08:02 <debo_os> maybe we give 2 more mins and then get started?
21:08:03 <glenc> \o
21:08:39 <dendrobates> debo_os: sure
21:08:54 <debo_os> debo.sleep(2m)
21:08:54 <zykes-> question, what is donabe in a easy description? a overlaying service for the netstack ?
21:09:02 <debo_os> well
21:09:25 <debo_os> donabe is an abstraction of app containers that leverages services like nova and quantum
21:09:53 <dendrobates> zykes-: or an abstraction for groups of cloud resources
21:10:07 <debo_os> that too! Thanks Dan
21:10:28 <zykes-> hmm, i wonder what the usage of it is
21:11:24 <debo_os> there are several usage models
21:11:27 <glenc> Does Donabe only address the cloud resources themselves, or does it also work with applications within them? (i.e., can it configure an app in a virtual server)
21:11:39 <debo_os> one possible way is http://www.slideshare.net/ddutta1/donabe-models-openstack-essex-summit
21:12:03 <debo_os> yes Donabe is geared towards describing app behavior too
21:12:43 <glenc> FYI, http://panelpicker.sxsw.com/ideas/view/10497
21:12:47 <dendrobates> glenc: we are mostly concerned with the abstraction and the ability to package that abstraction so it can be deployed
21:13:36 <dendrobates> glenc: that is a very similar concept
21:13:47 <glenc> Good - just making sure I'm on the right track
21:13:57 <glenc> which is why I wanted to be here
21:14:10 <dendrobates> glenc: I have even used oracle financials as an example
21:14:18 <glenc> great minds think alike
21:14:43 <dendrobates> :)
21:14:53 <dendrobates> debo_os: ok, go
21:15:01 <zykes-> dendrobates: werent you with rackspace earlier on ?
21:15:10 <debo_os> good guess :)
21:15:25 <dendrobates> zykes-: yes
21:15:45 <debo_os> #topic agenda
21:16:23 <debo_os> 1. A little more about whats Donabe .... in case we need it
21:16:30 <debo_os> 2. API and data model
21:16:36 <debo_os> 3. Declarative languages
21:16:40 <debo_os> anything more?
21:16:46 <debo_os> Rick?
21:16:48 <debo_os> Dan?
21:16:54 <debo_os> anyone?
21:17:03 <dendrobates> good for me
21:17:17 <debo_os> Shall we skip 1.
21:17:22 <danwent> sound good for me… i'm mostly just listening in :)
21:17:41 <debo_os> #topic API
21:18:07 <debo_os> During the summit, we agreed upon 1) recursive/nested containers
21:18:40 <debo_os> 2) simple use case -> scalableweb<-->scalable db tiers
21:18:59 <debo_os> 3) for essex leverage quantum and nova to stitch the containers
21:19:25 <debo_os> 4) use a declarative language for describing configs
21:20:32 <debo_os> for recursive containers, we need a data model
21:21:01 <debo_os> the simple API takes in a graph (with nodes = containers, edges = container pairs that communicate)
21:21:28 <debo_os> the data model leads to semi structured data
21:21:36 <debo_os> hence we need a data model that will be suitable
21:21:40 <debo_os> any comments on that>
21:21:41 <debo_os> ?
21:21:54 <glenc> could you also use a bill of materials type model?
21:21:58 <debo_os> possible approaches could be xml dbs or neo4j
21:22:24 <debo_os> glenc: in bom like models we would still need the relationships or edges
21:23:04 <debo_os> so this graph structure is like a BOM
21:23:27 <glenc> it is, but it doesn't have to be recursive (I'm just thinking out loud here)
21:24:05 <debo_os> assume its non recursive for a moment ...  its a good debate to have ....
21:24:21 <debo_os> you still need a semi structured way of representing a graph
21:24:51 <debo_os> thats why people have been looking at graph databases
21:25:16 <debo_os> but if there is a relational way of looking at it that covers the use cases, it might be good
21:25:34 <debo_os> in that case our higher layer graph model would then need to be mapped
21:26:34 <debo_os> any other suggestions
21:27:00 <debo_os> please send more suggestions to the list
21:27:38 <debo_os> the next thing is transactional semantics
21:27:52 <debo_os> for defining a higher layer container, you need to group smaller containers
21:28:03 <debo_os> now we could implement the API in 2 ways
21:28:18 <debo_os> 1st define smaller container types ... then build higher ones
21:28:54 <debo_os> but an alt way is to define it in 1 shot ... do a POST with a blob describing the graph
21:29:09 <debo_os> actually OVS has an app prpoosal with a graph structure too :)
21:29:14 <debo_os> thoughts?
21:29:39 <danwent> OVS != open vswitch i assume?
21:29:47 <debo_os> sorry OVF
21:29:51 <danwent> :)
21:29:55 <dendrobates> I'm concerned about posing a big blob
21:30:14 <dendrobates> is that your preference?
21:30:20 <debo_os> I am ok as long as we note that there will be transactional issues
21:30:33 <debo_os> we will need to have a fix for that
21:31:01 <debo_os> else we need a blob ....
21:31:20 <debo_os> I prefer the blob to keep the implementation is simpler
21:31:29 <dendrobates> can you explain the transactional issues in detail
21:31:51 <debo_os> well say you have a big container request that has 3 smaller containers
21:32:00 <debo_os> you need to create the smaller container requests 1st
21:32:04 <debo_os> then the bigger one
21:32:17 <debo_os> so you will have 4 requests
21:32:37 <debo_os> ideally you want this is as a part of a single transaction
21:32:58 <glenc> yes, with orchestration and rollback on error, right?
21:33:03 <debo_os> yes
21:33:52 <glenc> is the blob where it would contain the declarative language?
21:34:17 <debo_os> blob would have the graph structure ... and a reference to the manifest
21:34:45 <debo_os> because the manifest could be common for several containers
21:35:01 <glenc> I tend to read blob as a BINARY large object, which makes me nervous -
21:35:24 <glenc> I would hope it would be editable with standard tools
21:35:35 <debo_os> sorry ... I should have clarified
21:35:47 <debo_os> here a blob would mean a big xml blob
21:35:52 <debo_os> :)
21:35:55 <dendrobates> can we not assume xml
21:36:12 <debo_os> we could .... I just didnt want to offend JSON people
21:36:17 <debo_os> hence I am trying to use generic terms
21:36:20 <debo_os> ;)
21:37:10 <glenc> I tend to visualize it as XML (hey, I've been in IT for 20+ years) and convert mentally to json
21:37:25 <dendrobates> I would say the representation of the containers (blobs) is up for discussion
21:37:34 <glenc> I'm cool with it as long as it isn't really binary
21:38:16 <glenc> or Visual BASIC
21:38:22 <debo_os> :)
21:38:52 <debo_os> so these are the primary things I wanted to point out form the design point of view
21:39:11 <debo_os> please punt feedback
21:40:05 <dendrobates> awesome
21:40:19 <debo_os> the other things are slightly long temrs
21:40:26 <debo_os> like what declarative languages to use
21:41:26 <debo_os> and we want the donabe engine to be at a higher layer
21:41:35 <debo_os> using model driven stuff
21:41:59 <debo_os> so that we could have plugins for say things like declarative behavior engines etc
21:42:10 <debo_os> but all that might be relevant for later discussions
21:42:29 <debo_os> As DanW keeps saying, we need a simple demos
21:42:46 <danwent> :)
21:42:46 <debo_os> thats all from me
21:43:24 <dendrobates> should we take one part and delve into it next meeting?
21:43:29 <debo_os> I think once we have rough consensus about the graph backend, the demo is going to happen soon
21:43:33 <dendrobates> the model perhaps
21:43:39 <debo_os> yes ....
21:43:41 <glenc> yes
21:43:44 <debo_os> and the data backend
21:43:47 <debo_os> if time permits
21:44:46 <debo_os> any more thoughts/advice?
21:44:52 <dendrobates> sounds good to me
21:45:13 <dendrobates> next week we should advertise the meeting a bit more.
21:45:17 <debo_os> all right ... bye for now
21:45:21 <danwent> one thing...
21:45:24 <debo_os> sure
21:45:33 <danwent> i've heard juju brought up several times in this context.
21:45:53 <danwent> I don't know enough about the details to know the difference, but crisp messaging of donabe vs. juju (spelling?) would be nice.
21:46:18 <debo_os> I will let Rick answer too but juju doesnt do containers
21:46:30 <dendrobates> debo_os: that was what I was going to say.
21:46:36 <debo_os> It can be compared to chef / puppet
21:46:41 <dendrobates> it's all orchestration
21:46:54 <danwent> but orchestration of single elements only?
21:47:01 <debo_os> for now
21:47:13 <dendrobates> I will be meeting the juju guys in a couple weeks to see where we can work together
21:47:20 <danwent> ok, good to know.  I've just been asked several times and didn't know enough to explain the difference
21:47:31 <danwent> that's all
21:48:57 <dendrobates> ok, now I just need to find a place to watch the world series
21:48:59 <debo_os> #endmeeting