<div dir="ltr">Top posting to summarize things:<div><br></div><div>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</div><div>on a regular basis while we could use this for other usage.</div><div><br></div><div>This is what I suggest:</div><div><br></div><div>1. Create a VM in PHX called '<a href="http://mail.phx.ovirt.org">mail.phx.ovirt.org</a>' - anyone from the team can do it - if no one is doing it by the end of this week, I'll do it.</div><div>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).</div><div>3. Using the Ansible playbook to install the new service (hyperkitty) on the new VM.</div><div>4. Documenting the current configuration we have on <a href="http://lists.ovirt.org">lists.ovirt.org</a> (existing mailman) and applying it to the new server. ( adapting the Ansible playbook to include our configuration )</div><div>5. Pushing the Ansible code into a repo (we might need to create a new git repo for it)</div><div>6. Migrating the server ( with a rollback option )</div><div><br></div><div>Up until now this didn't include managing Ansible via foreman and only refers to migrating existing mailman to new server using Ansible.</div><div><br></div><div>The second part is more tricky:</div><div><br></div><div>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 )</div><div>2. Check if its possible manage Ansible via foreman or what does it mean to do it</div><div>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.</div><div><br></div><div><br></div><div>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:</div><div><ul><li>Migrate the quickest way, saving money on hosting we don't need</li><li>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.</li><li>We will be able to open bugs to foreman if we'll hit any issues which is blocking us</li><li>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.</li></ul><div><br></div></div><div>Lets move forward with this.</div><div><br></div><div>Eyal.</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 12:36 PM, Marc Dequènes (Duck) <span dir="ltr"><<a href="mailto:duck@redhat.com" target="_blank">duck@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quack,<br>
<span class=""><br>
On 04/11/2016 05:38 PM, Barak Korren wrote:<br>
<br>
> Well, what kind of hand is needed?<br>
<br>
</span>Help about the VM, you replied to this part (which unfortunately began<br>
off-list, my bad), thanks.<br>
<br>
The other part is tracking the features you need, to see if upgrading<br>
Foreman and using the work Misc pointed at could be a working solution.<br>
Because if an important feature is missing, then this path will not<br>
happen now.<br>
<br>
And then if it is a possible path, are you all willing to work on this<br>
migration?<br>
<span class=""><br>
> I remain unconvinced about the benefits of using Ansible here as<br>
> oppsed to the downsides of maintaining two CM systems in parallel.<br>
<br>
</span>I only viewed Mailman as a proof of concept. I agree maintaining both<br>
systems sux. So that's why I'm talking about a possible migration. I<br>
guess if it fails then we'll be back to reintegrating MailMan in the<br>
current system and this is not that horrible. If it works we can work on<br>
converting the rest with the knowledge we gained.<br>
<br>
I'd be happy to help but clearly I would need some time and energy from<br>
people in the project. Other OSAS members could also give a hand.<br>
<span class=""><br>
> Yeah I'm the current owner of the ticket to upgrade it and migrate it<br>
> to PHX, I will get to it eventually...<br>
<br>
</span>I've no idea about your workload, nor about the urgency of migrating<br>
Mailman. I think this is important to check our availability and will to<br>
invest on this.<br>
<span class=""><br>
> I think doing this kind of work will benefit us as well as others, it<br>
> should not be too much trouble imo.<br>
> Consider sending a rough patch to Gerrit, we can help and lead you from there.<br>
<br>
</span>Probably. Nevertheless it seems most projects OSAS are in touch with are<br>
getting out of Puppet and I myself in other projects decided not to go<br>
into this solution after some comparison and XP collection. So you may<br>
understand I'd like to invest my time in something not totally<br>
ephemeral. But if this migration is rejected or postponed, I will.<br>
<span class=""><br>
> Eyal suggested using Ansible right now in a one-off fashion to get the<br>
> Mailman server up. I don't particularity like that idea beucase it<br>
> seems to me it would make us incur some technical debt we will not pay<br>
> quickly. I'd rather pay it upfront. But I can understand if we want to<br>
> take such short cuts it the interest of getting Mailman out of some<br>
> bad state it is currently it. I'm not sure what is the situation with<br>
> it right now.<br>
<br>
</span>I'm new here :-), neither do I.<br>
<br>
Regards.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div></div>