<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 10:56 PM, Eyal Edri <span dir="ltr"><<a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="">+1 from me as well.</span><div>We are also thinking on moving existing bash deploy scripts we're using with ovirt-system-tests (running on Lago) with existing Ansible playbooks to install ovirt instead,</div><div>though not sure its the same purpose as yours.</div></div></blockquote><div><br></div><div>A bit more into the future - I don't think there's an immediate benefit to this right now - all provisioning is stable and should not have a lot of changes that we foresee.</div><div>I do agree that once we have Ansible playbooks for installation (hosted-engine specifically), we may want to think of moving to use it - in order to exercise it.</div><div><br></div><div>In addition, we may (some day) want to think of using it for the storage provisioning (although again right now it's good and solid).</div><div><br></div><div>I'd like to add more services, and FreeIPA and Foreman+Katello are right on the list there - they should be probably be installed via Ansible already.</div><div><br></div><div>Lastly, we need Gluster, which obviously should use gdeploy. My (incomplete) patch[1] does use it.</div><div>Y.</div><div><br></div><div>[1] <a href="https://gerrit.ovirt.org/#/c/57283/">https://gerrit.ovirt.org/#/c/57283/</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 15, 2016 at 4:10 PM, Eric Helms <span dir="ltr"><<a href="mailto:ehelms@redhat.com" target="_blank">ehelms@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Jun 15, 2016 at 8:53 AM, Barak Korren <span dir="ltr"><<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 15 June 2016 at 15:41, Eric Helms <<a href="mailto:ehelms@redhat.com" target="_blank">ehelms@redhat.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jun 15, 2016 at 8:20 AM, Barak Korren <<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>> wrote:<br>
>><br>
>> >><br>
>> >> See [1] for official reference. Instead of writing a static inventory<br>
>> >> script of hostnames, IPs and groupings Ansible allows writing a script<br>
>> >> to<br>
>> >> be run that produces that information dynamically.<br>
>> >><br>
>><br>
>> Ah ok. I failed to realise that was in the Ansible context.<br>
>><br>
>> +1 from me as well.<br>
>> Could we also assign server roles/Ansible variable from the Lago YAML?<br>
>> Would we want to?<br>
><br>
><br>
> You could/can and that would depend on how we write the inventory script.<br>
> Currently my script will parse out group assignments from the metadata. This<br>
> would probably be clearer seeing the source code and an example. Would<br>
> opening an issue with be best? Or a pull request with an example output to<br>
> then decide where the script should live?<br>
><br>
<br>
</span>I'd say start with an issue.<br>
WRT to where will that live, would an output format plugin for 'Lago<br>
status' be a reasonable place for this?<br>
<div><div><br></div></div></blockquote><div><br></div></span><div>Created <a href="https://github.com/lago-project/lago/issues/281" target="_blank">https://github.com/lago-project/lago/issues/281</a> with some sample output, template info and the source code at the bottom for perusal.</div><span><font color="#888888"><div><br></div><div>Eric</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
--<br>
Barak Korren<br>
<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a><br>
RHEV-CI Team<br>
</div></div></blockquote></span></div><br></div></div>
<br></div></div><span class="">_______________________________________________<br>
lago-devel mailing list<br>
<a href="mailto:lago-devel@ovirt.org" target="_blank">lago-devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/lago-devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/lago-devel</a><br>
<br></span></blockquote></div><span class=""><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="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: <a href="tel:%2B972-9-7692018" value="+97297692018" target="_blank">+972-9-7692018</a><br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
lago-devel mailing list<br>
<a href="mailto:lago-devel@ovirt.org">lago-devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/lago-devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/lago-devel</a><br>
<br></blockquote></div><br></div></div>