eod status 06-nov-2012

[Frank Mueller]

> I do not understand this at all.

Hi Aram,

sorry that this hasn't been communicated clear enough to you. I thought you got aware of it already on Thursday.

>> as discussed in Copenhagen we currently try two different approaches for
>> the lxc integration: a native Go implementation directly using system
>> calls etc and a wrapper around the command line tools of lxc.
> 
> I was not aware we ever took any decision regarding this, and this is
> the first time I hear the idea that there will be two implementations.

Maybe it's only bad formulated. Thursday morning Gustavo and I discussed about the actual approach so far and that it's worth to also do a wrapping implementation, both for evaluation and to get a better feeling for lxc. So I already worked on Thursday on this approach (and talked about it and my progress).

>> changed my quick Copenhagen hack into a pure wrapper package with create,
>> clone, start, stop, wait, and info; built a little command line front-end
>> using this package to perform the operations based on its arguments.
> 
> We discussed and agreed that I will be working on LXC related stuff,
> while you will be working on changing the state package. We cannot work
> as a team if you decide to work on something else than agreed upon or
> if you decide to work on the same thing as another member of the team.

So far, yes. But as you remember the way of implementing the lxc integration is not yet clear and an open point for discussion. That's the reason behind the evaluation and why I also added a section with pros and cons for both ways into the document.

Once again, sorry that this hasn't got clear last Thursday. Good that the eod status helped. 

cu mue

PS @Dave: It's nothing big so far, I'll push it into a +junk repository later.

--
** Frank Mueller <frank.mueller at canonical.com>
** Software Engineer - Juju Development
** Canonical