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 <[email protected]> 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 <[email protected]> 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) <[email protected]> > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/infra > > -- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
_______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
