[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] De-duping vagrant work by adding a new one: cgwalters/vagrant-atomic-cluster

On Thu, Apr 23, 2015 at 10:20 AM, Colin Walters <walters verbum org> wrote:
> On Sat, Apr 18, 2015, at 02:22 AM, James wrote:
>> I just noticed:
>> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00027.html
>> I've just posted a message to this list about the oh-my-vagrant
>> patches that I just wrote. For whatever reason, the archives don't
>> seem to update very quickly, so I can't link you to the message!
>> In any case, I think my patches are feature complete with
>> https://github.com/cgwalters/vagrant-atomic-cluster (I just had a
>> quick look) but also add much more functionality, in particular
>> because you get the existing oh-my-vagrant features too.
> This is basically
> https://github.com/purpleidea/oh-my-vagrant/commit/1f26e5bda5d7585f7b26babcb56a529cc34b96bd
> right?
Yes, although there are other features in some other commits of course :)

> The thing I really like about Vagrant is the ease of use for
> linking in *real* config/management/scrripting tools (Ansible/Puppet)

> etc.  (I personally think Vagrant's built-in provisioning like the Docker
> provisioner are mostly lame hacks)
I don't completely agree, I think the idea is correct, but it is
missing some features which I have implemented at the moment as shell
scripts in OMV.
If someone wanted to port those features upstream as ruby, that would be useful.

> The idea that you can easily test Ansible code locally in a Vagrant
> cluster on your laptop, and then be able to run those same scripts against
> a test cluster in AWS/GCE/etc. is powerful.

> But because you're not using kubernetes-ansible here that means
> we have less of a shared base.
> Maybe that's not an immediate burning problem...but from my
> perspective you're not actually obsoleting cgwalters/vagrant-atomic-cluster
> because I still want to hack on kubernetes-ansible.

Aha, good points. So for normal uses where people don't want to use
kubernetes-ansible, and are more interested in writing apps that _use_
kubernetes, then I think my vagrant solution is correct. However we're
not opinionated in that way, and oh-my-vagrant contains support to
plug into ansible.

In that case you can plug into ansible kubernetes and test it that
way. I actually have an example file that's even in git master:

The only issue is that ansible support needs more testing:

> Does that make sense?

I think my above comments should hopefully clarify.
Would love your help testing the omv-ansible code paths.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]