[lxc-devel] pylxd sprint

[Serge E. Hallyn]

Quoting James Pic (jamespic at gmail.com):
> Hi all \o/
> 
> There's been a lot of discussion around pylxd since a PR has been
> opened on Ansible to include an lxd_container module. It's really long
> so I'll try to brief you about it in this email, but FTR here it is:
> https://github.com/ansible/ansible-modules-extras/pull/2208
> 
> Basically we're a pretty broad group of developers and we would love
> to use the next pylxd release. I don't know what happened in the

Awesome.

> cosmos if the planets aligned some way, perhaps the great chtulu is
> coming or something, but we more or less all decided at the same time
> that using lxd in ansible would be the next big thing and it turns out
> we're all willing to spend a really fair amount of time in making this
> happen and be awesome.
> 
> It seems like the pylxd module could be even more awesome if only we
> could give it some love. And that's what we want to do: there has been
> discussion about how we could avoid using pylxd for now. And it seems
> like nobody can honestly say that using the lxc command line or
> re-inventing pylxd inside ansible would be the right thing to do.
> 
> I'd like to ask you if you could kindly help us organize a 1-week
> sprint to get an awesome pylxd RC out. The contribution flow is going
> to increase a bit, so, IMHO, we'd need:
> 
> - proper CI, running the new integration tests,

Ok, two options I see here are:

1. you can temporarily fork pylxd on github and set up your own jenkins
on github.  Chuck would look over the pylxd patches as quickly as he
can and merge them back into the main pylxd, and/or provide feedback.
We can also create a pylxd-ci tree, which I assume Stéphane would, if
it's reasonable, then hook up to github.com/lxc/pylxd.

2. we can set up a cloud server somewhere (perhaps gce) where you can
run your own jenkins server for the week.  Again, we'd definately want
to take the ci source and try to integrate it into the main pylxd
github jenkins.

> - automatic documentation build,

<no idea what this is about>

> - at least 1 pylxd-maintainer willing to guide us during the sprint to
> provide quick patch reviews.

I'm gonna go out on a limb and say I bet Chuck would do his best to
give review of such patches priority for a week.  He's already
overworked, but pylxd is important to him.

> Otherwise, we could either work on a fork that's going to grow fast
> outside pylxd,

That's an option, and not always a bad one.  If it turns out that what
you need simply doesn't mesh with what nova-lxd needs from an api, then
that may be best.  But I doubt that's the case.  I think that changes
to the pylxd api to enable ansible will make it better for everyone.

>  either just get on with our lives and just leave a PR
> or two die upstream while lxd_container never makes it to ansible.

Forking is a much better option.

> What do you think ?

Awesome.

-serge