[Container-tools] Recommendations for bootstrapping a local k8s cluster?

[Aaron Weitekamp]

Top-posting since I'm not following all of this thread.

omv breaks the typical Vagrant model in that I can't have a different Vagrantfile per project that each do different things. I have to keep changing my omv.yaml file. So I *must* run vagrant from the omv dir to get all of its functionality. This also means the common "rsync from current working directory" model has to change. It's a bit awkward and I feel like I'm always "managing" my dev environment.

As I work to containerize my desktop I really like the "run from current working directory" model where the container bindmounts whatever git repo I'm working in. This fits with Vagrant and containers and I think it can work with omv as well. It's a pattern that is beginning to emerge with development environment containers.

* super-priv container with git, ansible and omv (not vagrant)
* rely on host-installed vagrant
* each development project repo has a customized omv.yaml file for that project
* bindmount `pwd` into container


----- Original Message -----
> On 26 May 2015 at 02:13, James Shubin <purpleidea at redhat.com> wrote:
> > On Mon, 2015-05-25 at 23:52 +1000, Nick Coghlan wrote:
> >> P.S. It also doesn't hurt that asking you questions about Ansible
> >> works a lot better time zone wise than asking James about OMV ;)
> >
> > Ouch, Burn! Async FTW! There are a bunch of other people using OMV, and
> > one user has even started an external IRC channel: #ohmyvagrant
> >
> > The channel isn't hugely known or popular yet, but you're invited to
> > join if you like. It's a channel for users, hacking on OMV, and help
> > writing patches for it too! Usual rules apply, so come, but be positive!
> 
> Cool. I'm actually learning lots of things at once here (hands-on
> Docker, as opposed to Docker-in-theory, and likewise for Vagrant,
> Ansible and Kubernetes), so I see value in my learning how to use
> Vagrant *without* OMV, and then adding OMV back into the mix once I'm
> in a position to better appreciate what it's doing for me. I *do* see
> longer term value in having that abstraction layer there that provides
> a declarative approach to "vagrant up" rather than the imperative
> Vagrantfile approach.
> 
> If you're wondering "Why the insistence on Ansible?" that's day job
> related - we use Ansible for orchestration, so if I learn how to use
> it effectively to bootstrap a local Kubernetes in Vagrant, that means
> I can likely adapt whatever I come up with to further streamline
> https://beaker-project.org/docs-develop/in-a-box/
> 
> > The biggest issue the project faces, is that the Fedora packages for
> > vagrant+vagrant-libvirt don't work perfectly, so it's hard to get those
> > up and going, and they're a pre-req for OMV. One such bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1221006
> 
> Thanks for the heads up - I don't think that's the problem I'm seeing,
> but it's definitely one to keep in mind.
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> 
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>