Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-09-07 Thread Harry Rybacki
On Thu, Aug 31, 2017 at 12:52 PM, Juan Antonio Osorio
 wrote:
> Something that just came to my mind: Another option would be to allocate an
> extra IP Address for the undercloud, that would be dedicated to FreeIPA, and
> that way we MAY be able to deploy the FreeIPA server in the undercloud. If
> folks are OK with this I could experiment on this front. Maybe I could try
> to run FreeIPA on a container [1] (which wasn't available when I started
> working on this).
>
Interesting idea, Ozz! I'm not sure what/if the security implications
of running them
on the same host would be.

I'm cc'ing Toure to discuss possible workflow approach to this as well.

/R

> [1] https://hub.docker.com/r/freeipa/freeipa-server/
>
> On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi  wrote:
>>
>> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
>>  wrote:
>> > 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?
>>
>> Trying to reproduce what we did with ceph-ansible and use Mistral to
>> deploy FreeIPA with an external deployment tool.
>> Though I find the solution quite complex, maybe we can come-up with an
>> easier approach this time?
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-31 Thread Juan Antonio Osorio
Something that just came to my mind: Another option would be to allocate an
extra IP Address for the undercloud, that would be dedicated to FreeIPA,
and that way we MAY be able to deploy the FreeIPA server in the undercloud.
If folks are OK with this I could experiment on this front. Maybe I could
try to run FreeIPA on a container [1] (which wasn't available when I
started working on this).

[1] https://hub.docker.com/r/freeipa/freeipa-server/

On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi  wrote:

> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
>  wrote:
> > 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?
>
> Trying to reproduce what we did with ceph-ansible and use Mistral to
> deploy FreeIPA with an external deployment tool.
> Though I find the solution quite complex, maybe we can come-up with an
> easier approach this time?
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-25 Thread Emilien Macchi
On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
 wrote:
> 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?

Trying to reproduce what we did with ceph-ansible and use Mistral to
deploy FreeIPA with an external deployment tool.
Though I find the solution quite complex, maybe we can come-up with an
easier approach this time?
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-21 Thread Juan Antonio Osorio
On Mon, Aug 21, 2017 at 5:48 PM, Ben Nemec  wrote:

>
>
> On 08/21/2017 01:45 AM, Juan Antonio Osorio wrote:
>
>> 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?
>>
>
> I can't remember if we discussed this when we were first implementing the
> ci job, but could FreeIPA run on the undercloud itself?  We could have the
> undercloud install process install FreeIPA before it does the rest of the
> undercloud install, and then the undercloud by default would talk to that
> local instance of FreeIPA.  We'd provide configuration options to allow use
> of a standalone server too, of course.
>

Right, this would have been the preferred option, and we did try to do
this. However, FreeIPA not very flexible (it isn't at all) on its port
configuration. And unfortunately there are port conflicts. Hence why we
decided to use a separate node.


> I feel like there was probably a reason we didn't do that in the first
> place (port conflicts?), but it would be the easiest option for deployers
> if we could make it work.
>
>
>> On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi > > wrote:
>>
>> On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki > > wrote:
>>  > Greetings Stackers,
>>  >
>>  > Recently, I brought up a discussion around deploying FreeIPA via
>>  > TripleO-Quickstart vs TripleO. This is part of a larger discussion
>>  > around expanding security related CI coverage for OpenStack.
>>  >
>>  > A few months back, I added the ability to deploy FreeIPA via
>>  > TripleO-Quickstart through three reviews:
>>  >
>>  > 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
>>  > 2) Providing OOOQ with the ability to deploy a supplemental node
>>  > (alongside the undercloud)[2]
>>  > 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
>>  >
>>  >
>>  > The reasoning behind this is as follows (copied from a conversation
>>  > with jaosorior):
>>  >
>>  >> So the deal is that both the undercloud and the overcloud need
>> to be registered as a FreeIPA client.
>>  >> This is because they need to authenticate to it in order to
>> execute actions.
>>  >>
>>  >> * The undercloud needs to have FreeIPA credentials because it's
>> running novajoin, which in turn
>>  >> executes requests to FreeIPA in order to create service principals
>>  >>  - The service principals are ultimately the service name and
>> the node name entries for which we'll
>>  >> requests the certificates.
>>  >> * 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
>>  >> certificates.
>>  >>
>>  >> So the flow is as follows:
>>  >>
>>  >> * FreeIPA node is provisioned.
>>  >>  - We'll appropriate credentials at this point.
>>  >>  - We register the undercloud as a FreeIPA client and get an OTP
>> (one time password) for it
>>  >> - We add the OTP to the undercloud.conf and enable novajoin.
>>  >> * We trigger the undercloud install.
>>  >>  - after the install, we have novajoin running, which is the
>> service that registers automatically the
>>  >> overcloud nodes to FreeIPA.
>>  >> * We trigger the overcloud deploy
>>  >>  - We need to set up a flag that tells the deploy to pass
>> appropriate nova metadata (which tells
>>  >> novajoin that the nodes should be registered).
>>  >>  - profit!! we can now get certificates from the CA (and do
>> other stuff that FreeIPA allows you to do,
>>  >> such as use kerberos auth, control sudo rights of the nodes'
>> users, etc.)
>>  >>
>>  >> Since the nodes need to be registered to FreeIPA, we can't rely
>> on FreeIPA being installed by
>>  >> TripleO, even if that's possible by doing it through a
>> composable service.
>>  >> If we would use a composable service to install FreeIPA, the
>> flow would be like this:
>>  >>
>>  >> * Install undercloud
>>  >> * Install overcloud with one node (running FreeIPA)
>>  >> * register undercloud node to FreeIPA and modify undercloud.conf
>>  >> * Update undercloud
>>  >> * scale overcloud and register the rest of the nodes to FreeIPA
>> through novajoin.
>>  >>
>>  >> So, while we could install FreeIPA with TripleO. This really
>> complicates the deployment to an
>>  >> unnecessary point.
>>  >>
>>  >> So I suggest keeping the current behavior, which treats FreeIPA
>> as a separate node to be
>>  >> provisioned before the undercloud). And if folks would like to
>> have a separate FreeIPA node for their > overcloud 

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-21 Thread Ben Nemec



On 08/21/2017 01:45 AM, Juan Antonio Osorio wrote:
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?


I can't remember if we discussed this when we were first implementing 
the ci job, but could FreeIPA run on the undercloud itself?  We could 
have the undercloud install process install FreeIPA before it does the 
rest of the undercloud install, and then the undercloud by default would 
talk to that local instance of FreeIPA.  We'd provide configuration 
options to allow use of a standalone server too, of course.


I feel like there was probably a reason we didn't do that in the first 
place (port conflicts?), but it would be the easiest option for 
deployers if we could make it work.




On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi > wrote:


On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki > wrote:
 > Greetings Stackers,
 >
 > Recently, I brought up a discussion around deploying FreeIPA via
 > TripleO-Quickstart vs TripleO. This is part of a larger discussion
 > around expanding security related CI coverage for OpenStack.
 >
 > A few months back, I added the ability to deploy FreeIPA via
 > TripleO-Quickstart through three reviews:
 >
 > 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
 > 2) Providing OOOQ with the ability to deploy a supplemental node
 > (alongside the undercloud)[2]
 > 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
 >
 >
 > The reasoning behind this is as follows (copied from a conversation
 > with jaosorior):
 >
 >> So the deal is that both the undercloud and the overcloud need
to be registered as a FreeIPA client.
 >> This is because they need to authenticate to it in order to
execute actions.
 >>
 >> * The undercloud needs to have FreeIPA credentials because it's
running novajoin, which in turn
 >> executes requests to FreeIPA in order to create service principals
 >>  - The service principals are ultimately the service name and
the node name entries for which we'll
 >> requests the certificates.
 >> * 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
 >> certificates.
 >>
 >> So the flow is as follows:
 >>
 >> * FreeIPA node is provisioned.
 >>  - We'll appropriate credentials at this point.
 >>  - We register the undercloud as a FreeIPA client and get an OTP
(one time password) for it
 >> - We add the OTP to the undercloud.conf and enable novajoin.
 >> * We trigger the undercloud install.
 >>  - after the install, we have novajoin running, which is the
service that registers automatically the
 >> overcloud nodes to FreeIPA.
 >> * We trigger the overcloud deploy
 >>  - We need to set up a flag that tells the deploy to pass
appropriate nova metadata (which tells
 >> novajoin that the nodes should be registered).
 >>  - profit!! we can now get certificates from the CA (and do
other stuff that FreeIPA allows you to do,
 >> such as use kerberos auth, control sudo rights of the nodes'
users, etc.)
 >>
 >> Since the nodes need to be registered to FreeIPA, we can't rely
on FreeIPA being installed by
 >> TripleO, even if that's possible by doing it through a
composable service.
 >> If we would use a composable service to install FreeIPA, the
flow would be like this:
 >>
 >> * Install undercloud
 >> * Install overcloud with one node (running FreeIPA)
 >> * register undercloud node to FreeIPA and modify undercloud.conf
 >> * Update undercloud
 >> * scale overcloud and register the rest of the nodes to FreeIPA
through novajoin.
 >>
 >> So, while we could install FreeIPA with TripleO. This really
complicates the deployment to an
 >> unnecessary point.
 >>
 >> So I suggest keeping the current behavior, which treats FreeIPA
as a separate node to be
 >> 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
 >> composable service, if people request it.
 >
 > I am now re-raising this to the group at large for discussion about
 > the merits of this approach vs deploying via TripleO itself.

There are 3 approaches here:

- Keep using Quickstart which is of course not the viable option since
TripleO Quickstart is only used by CI and developers right now. Not by
customers neither in production.
- Deploy your own Ansible playbooks or automation tool to deploy

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-21 Thread Juan Antonio Osorio
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?

On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi  wrote:

> On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki 
> wrote:
> > Greetings Stackers,
> >
> > Recently, I brought up a discussion around deploying FreeIPA via
> > TripleO-Quickstart vs TripleO. This is part of a larger discussion
> > around expanding security related CI coverage for OpenStack.
> >
> > A few months back, I added the ability to deploy FreeIPA via
> > TripleO-Quickstart through three reviews:
> >
> > 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
> > 2) Providing OOOQ with the ability to deploy a supplemental node
> > (alongside the undercloud)[2]
> > 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
> >
> >
> > The reasoning behind this is as follows (copied from a conversation
> > with jaosorior):
> >
> >> So the deal is that both the undercloud and the overcloud need to be
> registered as a FreeIPA client.
> >> This is because they need to authenticate to it in order to execute
> actions.
> >>
> >> * The undercloud needs to have FreeIPA credentials because it's running
> novajoin, which in turn
> >> executes requests to FreeIPA in order to create service principals
> >>  - The service principals are ultimately the service name and the node
> name entries for which we'll
> >> requests the certificates.
> >> * 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
> >> certificates.
> >>
> >> So the flow is as follows:
> >>
> >> * FreeIPA node is provisioned.
> >>  - We'll appropriate credentials at this point.
> >>  - We register the undercloud as a FreeIPA client and get an OTP (one
> time password) for it
> >> - We add the OTP to the undercloud.conf and enable novajoin.
> >> * We trigger the undercloud install.
> >>  - after the install, we have novajoin running, which is the service
> that registers automatically the
> >> overcloud nodes to FreeIPA.
> >> * We trigger the overcloud deploy
> >>  - We need to set up a flag that tells the deploy to pass appropriate
> nova metadata (which tells
> >> novajoin that the nodes should be registered).
> >>  - profit!! we can now get certificates from the CA (and do other stuff
> that FreeIPA allows you to do,
> >> such as use kerberos auth, control sudo rights of the nodes' users,
> etc.)
> >>
> >> Since the nodes need to be registered to FreeIPA, we can't rely on
> FreeIPA being installed by
> >> TripleO, even if that's possible by doing it through a composable
> service.
> >> If we would use a composable service to install FreeIPA, the flow would
> be like this:
> >>
> >> * Install undercloud
> >> * Install overcloud with one node (running FreeIPA)
> >> * register undercloud node to FreeIPA and modify undercloud.conf
> >> * Update undercloud
> >> * scale overcloud and register the rest of the nodes to FreeIPA through
> novajoin.
> >>
> >> So, while we could install FreeIPA with TripleO. This really
> complicates the deployment to an
> >> unnecessary point.
> >>
> >> So I suggest keeping the current behavior, which treats FreeIPA as a
> separate node to be
> >> 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
> >> composable service, if people request it.
> >
> > I am now re-raising this to the group at large for discussion about
> > the merits of this approach vs deploying via TripleO itself.
>
> There are 3 approaches here:
>
> - Keep using Quickstart which is of course not the viable option since
> TripleO Quickstart is only used by CI and developers right now. Not by
> customers neither in production.
> - Deploy your own Ansible playbooks or automation tool to deploy
> FreeIPA and host it wherever you like. Integrate the playbooks in
> TripleO, as an external component (can be deployed manually between
> some steps but will be to be documented).
> - Create a composable service that will deploy FreeIPA service(s),
> part of TripleO Heat Templates. The way it works *now* will require
> you to have a puppet-freeipa module to deploy the bits but we're
> working toward migrating to Ansible at some point.
>

This approach is not ideal and will be quite a burdain as I described
above. I wouldn't consider this an option.


> I hope it helps, let me know if you need further details on a specific
> approach.
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-18 Thread Emilien Macchi
On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki  wrote:
> Greetings Stackers,
>
> Recently, I brought up a discussion around deploying FreeIPA via
> TripleO-Quickstart vs TripleO. This is part of a larger discussion
> around expanding security related CI coverage for OpenStack.
>
> A few months back, I added the ability to deploy FreeIPA via
> TripleO-Quickstart through three reviews:
>
> 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
> 2) Providing OOOQ with the ability to deploy a supplemental node
> (alongside the undercloud)[2]
> 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
>
>
> The reasoning behind this is as follows (copied from a conversation
> with jaosorior):
>
>> So the deal is that both the undercloud and the overcloud need to be 
>> registered as a FreeIPA client.
>> This is because they need to authenticate to it in order to execute actions.
>>
>> * The undercloud needs to have FreeIPA credentials because it's running 
>> novajoin, which in turn
>> executes requests to FreeIPA in order to create service principals
>>  - The service principals are ultimately the service name and the node name 
>> entries for which we'll
>> requests the certificates.
>> * 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
>> certificates.
>>
>> So the flow is as follows:
>>
>> * FreeIPA node is provisioned.
>>  - We'll appropriate credentials at this point.
>>  - We register the undercloud as a FreeIPA client and get an OTP (one time 
>> password) for it
>> - We add the OTP to the undercloud.conf and enable novajoin.
>> * We trigger the undercloud install.
>>  - after the install, we have novajoin running, which is the service that 
>> registers automatically the
>> overcloud nodes to FreeIPA.
>> * We trigger the overcloud deploy
>>  - We need to set up a flag that tells the deploy to pass appropriate nova 
>> metadata (which tells
>> novajoin that the nodes should be registered).
>>  - profit!! we can now get certificates from the CA (and do other stuff that 
>> FreeIPA allows you to do,
>> such as use kerberos auth, control sudo rights of the nodes' users, etc.)
>>
>> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA 
>> being installed by
>> TripleO, even if that's possible by doing it through a composable service.
>> If we would use a composable service to install FreeIPA, the flow would be 
>> like this:
>>
>> * Install undercloud
>> * Install overcloud with one node (running FreeIPA)
>> * register undercloud node to FreeIPA and modify undercloud.conf
>> * Update undercloud
>> * scale overcloud and register the rest of the nodes to FreeIPA through 
>> novajoin.
>>
>> So, while we could install FreeIPA with TripleO. This really complicates the 
>> deployment to an
>> unnecessary point.
>>
>> So I suggest keeping the current behavior, which treats FreeIPA as a 
>> separate node to be
>> 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
>> composable service, if people request it.
>
> I am now re-raising this to the group at large for discussion about
> the merits of this approach vs deploying via TripleO itself.

There are 3 approaches here:

- Keep using Quickstart which is of course not the viable option since
TripleO Quickstart is only used by CI and developers right now. Not by
customers neither in production.
- Deploy your own Ansible playbooks or automation tool to deploy
FreeIPA and host it wherever you like. Integrate the playbooks in
TripleO, as an external component (can be deployed manually between
some steps but will be to be documented).
- Create a composable service that will deploy FreeIPA service(s),
part of TripleO Heat Templates. The way it works *now* will require
you to have a puppet-freeipa module to deploy the bits but we're
working toward migrating to Ansible at some point.

I hope it helps, let me know if you need further details on a specific approach.
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO][CI] FreeIPA Deployment

2017-08-18 Thread Harry Rybacki
Greetings Stackers,

Recently, I brought up a discussion around deploying FreeIPA via
TripleO-Quickstart vs TripleO. This is part of a larger discussion
around expanding security related CI coverage for OpenStack.

A few months back, I added the ability to deploy FreeIPA via
TripleO-Quickstart through three reviews:

1) Adding a role to deploy FreeIPA via OOOQ_E[1]
2) Providing OOOQ with the ability to deploy a supplemental node
(alongside the undercloud)[2]
3) Update the quickstart-extras playbook to deploy FreeIPA[3]


The reasoning behind this is as follows (copied from a conversation
with jaosorior):

> So the deal is that both the undercloud and the overcloud need to be 
> registered as a FreeIPA client.
> This is because they need to authenticate to it in order to execute actions.
>
> * The undercloud needs to have FreeIPA credentials because it's running 
> novajoin, which in turn
> executes requests to FreeIPA in order to create service principals
>  - The service principals are ultimately the service name and the node name 
> entries for which we'll
> requests the certificates.
> * 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
> certificates.
>
> So the flow is as follows:
>
> * FreeIPA node is provisioned.
>  - We'll appropriate credentials at this point.
>  - We register the undercloud as a FreeIPA client and get an OTP (one time 
> password) for it
> - We add the OTP to the undercloud.conf and enable novajoin.
> * We trigger the undercloud install.
>  - after the install, we have novajoin running, which is the service that 
> registers automatically the
> overcloud nodes to FreeIPA.
> * We trigger the overcloud deploy
>  - We need to set up a flag that tells the deploy to pass appropriate nova 
> metadata (which tells
> novajoin that the nodes should be registered).
>  - profit!! we can now get certificates from the CA (and do other stuff that 
> FreeIPA allows you to do,
> such as use kerberos auth, control sudo rights of the nodes' users, etc.)
>
> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA 
> being installed by
> TripleO, even if that's possible by doing it through a composable service.
> If we would use a composable service to install FreeIPA, the flow would be 
> like this:
>
> * Install undercloud
> * Install overcloud with one node (running FreeIPA)
> * register undercloud node to FreeIPA and modify undercloud.conf
> * Update undercloud
> * scale overcloud and register the rest of the nodes to FreeIPA through 
> novajoin.
>
> So, while we could install FreeIPA with TripleO. This really complicates the 
> deployment to an
> unnecessary point.
>
> So I suggest keeping the current behavior, which treats FreeIPA as a separate 
> node to be
> 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
> composable service, if people request it.

I am now re-raising this to the group at large for discussion about
the merits of this approach vs deploying via TripleO itself.


[1] - https://review.openstack.org/#/c/436198/
[2] - https://review.openstack.org/#/c/451523/
[3] - https://review.openstack.org/#/c/453223/

/R

Harry Rybacki

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev