[ovirt-devel] Firewalld migration.

[Yaniv Kaul]

On Tue, Mar 28, 2017 at 7:34 PM, Sven Kieske <s.kieske at mittwald.de> wrote:

> On 28/03/17 17:58, Martin Sivak wrote:
> > I actually like the radical option Didi mentioned -> using Ansible for
> > the whole deploy flow. A simple host-deploy dir with playbooks (and
> > builtin roles) is something most people would understand easily.
> >
> > And it would even remove all the infrastructure burden from us, oVirt
> > would not be the host management solution, Ansible would take the role
> > and we would just invoke it when deploying a new host much like we do
> > with host deploy now (except Ansible manages its own ssh connection
> > too).
>
> +1
>
> but some drawback (actual ansible user here):
>
> you in fact need _some_ libs on the managed hosts for certain ansible
> features to work (e.g. if you want to respect selinux settings on the
> host), so you would also need to provide these or list them as
> prerequisites.
>
> I understand ovirt can't just provide config mgmt solutions for every
> tool out there (puppet, chef, ansible, saltstack, etc.).
>
> the best approach would be, if it is pluggable, like foreman did this
> with it's smart proxys and plugins:
>
> https://theforeman.org/plugins/


Ah, that's a different story altogether.
You can use Forman/Satellite to manage your hosts life-cycle.
It's a great, quite well integrated solution we are very fond of.
We support both discovered hosts (from bare-metal) as well as hosts added
already to Foreman.


>
> so you could provide a plugin infrastructure and maybe write the ansible
> integration yourself and the community can add their own
> plugins like puppet or chef modules at will. If they mature enough
> you could even ship those (optional).
>
> I really think there would be some value in this, because many small
> deployments use tools like puppet or ansible, while these do not scale
> well for large environments, where you tend to have things like salt or
> chef.
>
> PS: if you want to annoy some users you could even declare a hard
> dependency on foreman and use foreman for the host deployment (a tool
> that's actually written for exact this scope), others might find this
> higher integration nice. I'm not sure if I would like it or not.
>

I'd be happy to do that in the future. Right now there are some obstacles
to doing that.
Remember that there are huge benefits to using Foreman not just for host
life-cycle, but also VM life-cycle.
Y.


>
> --
> Mit freundlichen Grüßen / Regards
>
> Sven Kieske
>
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +495772 293100
> F: +495772 293333
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170329/36bb9a89/attachment-0001.html>