Supporting Ansible as another tool for ovirt infra mgmt

Tue Apr 12 19:59:09 UTC 2016

I was not talking abut using tower, but about asking them to push the support on foreman and keep using foreman.

David Caro

El 12/4/2016 6:00 p. m., Anton Marchukov <amarchuk at redhat.com> escribió:

Hello David, All.

Maybe it makes sense to rereview foreman alternatives for future... Tower might be a good choice, but not open sourced yet and no plans for that. Also using puppet from it needs to be reviewed. 

Anton.

On Tue, Apr 12, 2016 at 5:52 PM, David Caro Estevez <dcaroest at redhat.com> wrote:

I had a small chat with dlobato, it seems that the Foreman-ansible integration is halted because it potentially conflicts/collides with tower, but that if we publicly request it as project we might get it unlocked.

David Caro

El 12/4/2016 15:52, Eyal Edri <eedri at redhat.com> escribió:

Top posting to summarize things:

I'm OK with doing a 'POC' of using Ansible with mailman 3 in order to move forward with this migration and release linode server which we pay money for it

on a regular basis while we could use this for other usage.

This is what I suggest:

1. Create a VM in PHX called 'mail.phx.ovirt.org' - anyone from the team can do it - if no one is doing it by the end of this week, I'll do it.

2. You should get access to that VM (please send you ssh public key to infra list so we can add you and you'll get access to the VM).

3. Using the Ansible playbook to install the new service (hyperkitty) on the new VM.

4. Documenting the current configuration we have on lists.ovirt.org (existing mailman) and applying it to the new server. ( adapting the Ansible playbook to include our configuration )

5. Pushing the Ansible code into a repo (we might need to create a new git repo for it)

6. Migrating the server ( with a rollback option )

Up until now this didn't include managing Ansible via foreman and only refers to migrating existing mailman to new server using Ansible.

The second part is more tricky:

1. Install new foreman VM on PHX ( that's a pending task we need prioritze regarless of the mailman migration and we'll do it soon after jenkins migrated )

2. Check if its possible manage Ansible via foreman or what does it mean to do it

3. If we'll see that its not correlate to how we manage the infra right now and takes a big toll on management, we will decide the POC is a fail and we will need to write puppet classes to the new installed mailman.

As you can understand this approach has a "risk" of doing some duplicate work, but I think its the best way to go because it will allow us to:

Migrate the quickest way, saving money on hosting we don't needTesting Ansible support, which is something we can't ignore, as we see more and more Ansible adoption and I believe we should evaluate it.We will be able to open bugs to foreman if we'll hit any issues which is blocking usIf we will end up writing puppet manifest, we would have not wasted too much time on Ansible since most of the code is already available.

Lets move forward with this.

Eyal.

On Mon, Apr 11, 2016 at 12:36 PM, Marc Dequènes (Duck) <duck at redhat.com> wrote:

Quack,

On 04/11/2016 05:38 PM, Barak Korren wrote:

> Well, what kind of hand is needed?

Help about the VM, you replied to this part (which unfortunately began
off-list, my bad), thanks.

The other part is tracking the features you need, to see if upgrading
Foreman and using the work Misc pointed at could be a working solution.
Because if an important feature is missing, then this path will not
happen now.

And then if it is a possible path, are you all willing to work on this
migration?

> I remain unconvinced about the benefits of using Ansible here as
> oppsed to the downsides of maintaining two CM systems in parallel.

I only viewed Mailman as a proof of concept. I agree maintaining both
systems sux. So that's why I'm talking about a possible migration. I
guess if it fails then we'll be back to reintegrating MailMan in the
current system and this is not that horrible. If it works we can work on
converting the rest with the knowledge we gained.

I'd be happy to help but clearly I would need some time and energy from
people in the project. Other OSAS members could also give a hand.

> Yeah I'm the current owner of the ticket to upgrade it and migrate it
> to PHX, I will get to it eventually...

I've no idea about your workload, nor about the urgency of migrating
Mailman. I think this is important to check our availability and will to
invest on this.

> I think doing this kind of work will benefit us as well as others, it
> should not be too much trouble imo.
> Consider sending a rough patch to Gerrit, we can help and lead you from there.

Probably. Nevertheless it seems most projects OSAS are in touch with are
getting out of Puppet and I myself in other projects decided not to go
into this solution after some comparison and XP collection. So you may
understand I'd like to invest my time in something not totally
ephemeral. But if this migration is rejected or postponed, I will.

> Eyal suggested using Ansible right now in a one-off fashion to get the
> Mailman server up. I don't particularity like that idea beucase it
> seems to me it would make us incur some technical debt we will not pay
> quickly. I'd rather pay it upfront. But I can understand if we want to
> take such short cuts it the interest of getting Mailman out of some
> bad state it is currently it. I'm not sure what is the situation with
> it right now.

I'm new here :-), neither do I.

Regards.

-- 

Eyal Edri
Associate Manager

RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)

_______________________________________________
Infra mailing list
Infra at ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

-- 

Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160412/ad5f32ae/attachment.html>