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 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, - automatic documentation build, - at least 1 pylxd-maintainer willing to guide us during the sprint to provide quick patch reviews. Otherwise, we could either work on a fork that's going to grow fast outside pylxd, either just get on with our lives and just leave a PR or two die upstream while lxd_container never makes it to ansible. What do you think ? Thanks for reading, Best James B) _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
