Saltstack instead of ansible?

[tony]

Hi bsdploy developers,

I pointed out the gplv3 conflict with ansible at ployground/ploy_ansible#8.

However, at the same time, saltstack is a candidate for provisioning jails. They seem to have been pretty friendly to supporting BSD systems. Recently they put BSD Jails on their roadmap for salt-cloud: saltstack/salt#22983.

I'm checking to see if their is any desire on bsdploy's side to support salt for setting up environments in jails.

[tomster]

hi tony, (bsd)ploy is very modular by design. in theory, implementing a ploy_salt package and making bsdploy support that is entirely possible.

aside from the licence issue (thanks for pointing that out btw!) we simply don't have much of an incentive to support salt because all in all we're quite happy with ansible.

having said that, saltstack was the number two contender at the time when we started to develop bsdploy and i'd love to see ploy support it - it's just that neither @fschulze nor myself have any time to work on it.

if you'd be interested in providing support we'd be more than happy to shepherd and mentor, though

[tomster]

actually, the more i think about ployground/ploy_ansible#8 the more it bugs me...

while i don't see myself spending any significant energy on this in the near future, i definitely

a) wanted to take a closer look (again) at saltstack, anyway
b) would like to keep ploy as gpl free, as possible

[fschulze]

I couldn't find much about compatibility of the Apache License 2.0 which salt uses (http://www.apache.org/licenses/LICENSE-2.0) with the BSD License and whether that license affects usage somehow. Also if we do ploy_salt, could you still use ploy_ansible at the same time, since the GPL is incompatible with the Apache License? I think this is a pretty grey area, because we use those things not as self contained applications, but as libraries.

The upcoming changes in Ansible 2.0.0 are bugging me, so I'm thinking more about alternatives.

[JayBusch]

I would REALLY like to see a switch to SaltStack for BSDploy. The ONLY reason I'm not using BSDploy right now is that it relies on Ansible and I know that will never be license compatible with BSD and therefore means that Ansible is doomed to never be widely used or supported by the core BSD community. @fschulze - the Apache 2.0 License should be fully BSD compatible, I am not a lawyer, but that is my understanding.

If this switch was taken seriously by BSDploy contributors I'd be very happy to contribute heavily myself towards the effort. I am underway deploying SaltStack to my BSD systems and would love to have a community and project specific to making sure BSD is not left out of the plans (as usual) while SaltStack matures.

[fschulze]

I haven't looked too deeply into saltstack yet. As with puppet, there seem to be several modes it can be used. With some central server in pull mode or more like ansible explicitely on a host via push. We would need the latter. We would also need to be able to use saltstack like a library from ploy, which is a bit hacky with ansible and it looks like the changes in ansible 2 are quite invasive, so we would have to write a new plugin anyway. It would help if you could give any pointers to existing documentation on saltstack about the above stuff.

Anyway, I'm seriously considering saltstack, but didn't have time to look at it yet, so any help to reduce the time needed to evaluate it as an option would help.

If someone already used bsdploy and saltstack and could do a writeup on how they would like the two be integrated would help as well. Usecases etc.

[fschulze]

I made a proof of concept plugin for ploy: https://github.com/ployground/ploy_salt

It's crude, but simple things like raw commands and some basic modules already work. I haven't tried any state stuff yet.

[JayBusch]

Fantastic!

I was going to write you a primer on Salt this morning, including a recommendation to use salt-ssh and not the general master/minion configuration, but it looks like you figured all of that out already.

I will fork the new repository and try to use it. I am most interested in using Salt as a state management mechanism as well as providing some basic monitoring facilities all over SSH without additional install on the remote machine, so I will look at how we might implement states sooner than later.

Thank you for taking this step and moving towards Salt. I hope you will commit to keeping all future licensing for ploy_salt compatible with BSD? I hope to contribute to this project but I would like to know that at some future point GPL like software will not be included thus trapping the fruits of our labor under the GPL.

In that spirit can you add a proper LICENSE file indicating how you are releasing this software? Without a specific license developers such as my self will be very reluctant to contribute. I believe GitHub has a dropdown selector for the common open source licenses; something like MIT would be best to allow the most flexibility IMHO.

[fschulze]

I indicated the license in setup.py, BSD 3-clause.

[JayBusch]

Ok Great! Didn't see that :).

[tony]

Greetings, any update on this ?

I would like to have the prior git history with ansible rebased out. This won't win many fans, but to be frank the code is still a derivative of GPL by the means of changeset history. I imagine there will be disagreements in how some view this (there will be some who think merely removing ansible without rewriting history is sufficient) - as well as those who flat out refuse to do a destructive rewrite.

However, since I'm using bsdploy on a future commercial project, if we don't come to an agreement on rewriting the history, it complicates me giving changes back. I don't want GPL in the history.

[tony]

An aside: This is actually one of the reasons I think FreeBSD has as a complication with using git. In subversion, it's possible to remove infringing code from history. With git, not so easy. I comes up here https://www.youtube.com/watch?v=wwbO4eTieQY (I am going to update this message with what time git comes up in the video, but its interesting to watch the full thing anyway)

[fschulze]

What history do you mean? Only the separate ploy-ansible plugin has GPL parts as far as I can tell. Could you point to specific commits?

[tony]

How familiar are you with GPL and how it works downstream? It applies its terms to anything it touches.

If ploy-ansible has GPL parts, it is GPL.

If bsdploy pulls in ploy-ansible, such as with:

• https://github.com/ployground/bsdploy/blob/master/setup.py#L15 / https://github.com/ployground/bsdploy/blob/master/setup.py#L61
• https://github.com/ployground/bsdploy/blob/master/bsdploy/library/zpool#L204

That's all that you need to trigger a derivative. BSDPloy is live, hot, viral GPL code, if its pulling in GPL code. It may be licensed as BSD, but its a derivative (and subject to the terms of the GPL) until traces of GPL get wiped out.

[fschulze]

Wouldn't changing the history be lying? I guess I'd rather do a separate bsdploy2 which doesn't depend on ploy_ansible. What if I use code that I and Tom wrote from bsdploy in that new bsdploy2? Viruses are crap.

[tony]

Wouldn't changing the history be lying?

The contributions are already BSD. They are anyone's changes to edit, including rewriting them and the history to remove the GPL code.

I guess I'd rather do a separate bsdploy2 which doesn't depend on ploy_ansible. What if I use code that I and Tom wrote from bsdploy in that new bsdploy2?

That's how you would do it. SDL2 did something similar. They went LGPL -> zlib.

You could fork this repo as a new project (bsdploy2), rebase out ansible stuff, or just have a fresh history. You could also move this repo to bsdploy_old and make a new bsdploy. Then we're safe