Re: Supporting Ansible as another tool for ovirt infra mgmt

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(a)redhat.com&gt; 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 need - Testing 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 us - If 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(a)redhat.com&gt; 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra