<div dir="ltr">The second option seems like the most viable. Not sure how the TripleO 
integration would go though. Care to elaborate on what you had in mind?
<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@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 class="gmail-HOEnZb"><div class="gmail-h5">On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki <<a href="mailto:hrybacki@redhat.com">hrybacki@redhat.com</a>> wrote:<br>
> Greetings Stackers,<br>
><br>
> Recently, I brought up a discussion around deploying FreeIPA via<br>
> TripleO-Quickstart vs TripleO. This is part of a larger discussion<br>
> around expanding security related CI coverage for OpenStack.<br>
><br>
> A few months back, I added the ability to deploy FreeIPA via<br>
> TripleO-Quickstart through three reviews:<br>
><br>
> 1) Adding a role to deploy FreeIPA via OOOQ_E[1]<br>
> 2) Providing OOOQ with the ability to deploy a supplemental node<br>
> (alongside the undercloud)[2]<br>
> 3) Update the quickstart-extras playbook to deploy FreeIPA[3]<br>
><br>
><br>
> The reasoning behind this is as follows (copied from a conversation<br>
> with jaosorior):<br>
><br>
>> So the deal is that both the undercloud and the overcloud need to be registered as a FreeIPA client.<br>
>> This is because they need to authenticate to it in order to execute actions.<br>
>><br>
>> * The undercloud needs to have FreeIPA credentials because it's running novajoin, which in turn<br>
>> executes requests to FreeIPA in order to create service principals<br>
>>  - The service principals are ultimately the service name and the node name entries for which we'll<br>
>> requests the certificates.<br>
>> * The overcloud nodes need to be registered and authenticated to FreeIPA (which right now happens > through a cloud-init script provisioned by nova/nova-metadata) because that's how it requests<br>
>> certificates.<br>
>><br>
>> So the flow is as follows:<br>
>><br>
>> * FreeIPA node is provisioned.<br>
>>  - We'll appropriate credentials at this point.<br>
>>  - We register the undercloud as a FreeIPA client and get an OTP (one time password) for it<br>
>> - We add the OTP to the undercloud.conf and enable novajoin.<br>
>> * We trigger the undercloud install.<br>
>>  - after the install, we have novajoin running, which is the service that registers automatically the<br>
>> overcloud nodes to FreeIPA.<br>
>> * We trigger the overcloud deploy<br>
>>  - We need to set up a flag that tells the deploy to pass appropriate nova metadata (which tells<br>
>> novajoin that the nodes should be registered).<br>
>>  - profit!! we can now get certificates from the CA (and do other stuff that FreeIPA allows you to do,<br>
>> such as use kerberos auth, control sudo rights of the nodes' users, etc.)<br>
>><br>
>> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA being installed by<br>
>> TripleO, even if that's possible by doing it through a composable service.<br>
>> If we would use a composable service to install FreeIPA, the flow would be like this:<br>
>><br>
>> * Install undercloud<br>
>> * Install overcloud with one node (running FreeIPA)<br>
>> * register undercloud node to FreeIPA and modify undercloud.conf<br>
>> * Update undercloud<br>
>> * scale overcloud and register the rest of the nodes to FreeIPA through novajoin.<br>
>><br>
>> So, while we could install FreeIPA with TripleO. This really complicates the deployment to an<br>
>> unnecessary point.<br>
>><br>
>> So I suggest keeping the current behavior, which treats FreeIPA as a separate node to be<br>
>> provisioned before the undercloud). And if folks would like to have a separate FreeIPA node for their > overcloud deployment (which could provision certs for the tenants) then we could do that as a<br>
>> composable service, if people request it.<br>
><br>
> I am now re-raising this to the group at large for discussion about<br>
> the merits of this approach vs deploying via TripleO itself.<br>
<br>
</div></div>There are 3 approaches here:<br>
<br>
- Keep using Quickstart which is of course not the viable option since<br>
TripleO Quickstart is only used by CI and developers right now. Not by<br>
customers neither in production.<br>
- Deploy your own Ansible playbooks or automation tool to deploy<br>
FreeIPA and host it wherever you like. Integrate the playbooks in<br>
TripleO, as an external component (can be deployed manually between<br>
some steps but will be to be documented).<br>
- Create a composable service that will deploy FreeIPA service(s),<br>
part of TripleO Heat Templates. The way it works *now* will require<br>
you to have a puppet-freeipa module to deploy the bits but we're<br>
working toward migrating to Ansible at some point.<br></blockquote><div> </div><div>This approach is not ideal and will be quite a burdain as I described 
above. I wouldn't consider this an option.  <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I hope it helps, let me know if you need further details on a specific approach.<br>
<span class="gmail-HOEnZb"><font color="#888888">--<br>
Emilien Macchi<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>