Re: [openstack-dev] [tripleo] os-cloud-config retirement

[Emilien Macchi]

On Fri, Apr 7, 2017 at 2:27 PM, Andreas Jaeger  wrote:
> On 2017-04-07 18:55, Emilien Macchi wrote:
>> os-cloud-config has been retired in Infra and in the repo.
>> RDO packaging has also been updated.
>> Now waiting for final approval in Governance:
>> https://review.openstack.org/#/c/451096/
>>
>> If bug fixes has to happen, please submit to stable branches directly
>> and let us know on #rdo, we'll update the pin.
>
> Emilien, note that the repo is completely read only - on all branches.
> You cannot submit anything anymore,

Ok thanks for the reminder and sorry for the confusion I brought
(TIL). I don't think it's a problem for us.

Thanks!

> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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



-- 
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] os-cloud-config retirement

[Andreas Jaeger]

On 2017-04-07 18:55, Emilien Macchi wrote:
> os-cloud-config has been retired in Infra and in the repo.
> RDO packaging has also been updated.
> Now waiting for final approval in Governance:
> https://review.openstack.org/#/c/451096/
> 
> If bug fixes has to happen, please submit to stable branches directly
> and let us know on #rdo, we'll update the pin.

Emilien, note that the repo is completely read only - on all branches.
You cannot submit anything anymore,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] os-cloud-config retirement

[Emilien Macchi]

os-cloud-config has been retired in Infra and in the repo.
RDO packaging has also been updated.
Now waiting for final approval in Governance:
https://review.openstack.org/#/c/451096/

If bug fixes has to happen, please submit to stable branches directly
and let us know on #rdo, we'll update the pin.
Thanks,

On Mon, Apr 3, 2017 at 11:56 AM, Emilien Macchi  wrote:
> The retirement patch is ready whenever you are:
> https://review.openstack.org/#/c/450946/
>
> Please review.
>
> Thanks,
>
> On Mon, Apr 3, 2017 at 3:53 AM, Bogdan Dobrelya  wrote:
>> On 31.03.2017 13:58, Jiří Stránský wrote:
>>> On 30.3.2017 17:39, Juan Antonio Osorio wrote:
 Why not drive the post-config with something like shade over ansible?
 Similar to what the kolla-ansible community is doing.
>>>
>>> We could use those perhaps, if they bring enough benefit to add them to
>>> the container image(s) (i think we'd still want to drive it via a
>>> container rather than fully externally). It's quite tempting to just
>>
>> I hope we still want to decouple configuration from distribution. Wrt
>> versioning issue, custom entry points seem bound to versions of the heat
>> templates and data living there anyway. So it sounds reasonable to me to
>> ship and version entrypoints among templates as a single bundle and
>> please please please keep those out of images.
>>
>>> load a yaml file with the endpoint definitions and just iterate over
>>> them and let Ansible handle the actual API calls...
>>>
>>> However, currently i can't see endpoint management in the cloud modules
>>> docs [1], just service management. Looks like there's still a feature
>>> gap at the moment.
>>>
>>> Jirka
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> __
>> 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
>
>
>
> --
> Emilien Macchi



-- 
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] os-cloud-config retirement

[Emilien Macchi]

The retirement patch is ready whenever you are:
https://review.openstack.org/#/c/450946/

Please review.

Thanks,

On Mon, Apr 3, 2017 at 3:53 AM, Bogdan Dobrelya  wrote:
> On 31.03.2017 13:58, Jiří Stránský wrote:
>> On 30.3.2017 17:39, Juan Antonio Osorio wrote:
>>> Why not drive the post-config with something like shade over ansible?
>>> Similar to what the kolla-ansible community is doing.
>>
>> We could use those perhaps, if they bring enough benefit to add them to
>> the container image(s) (i think we'd still want to drive it via a
>> container rather than fully externally). It's quite tempting to just
>
> I hope we still want to decouple configuration from distribution. Wrt
> versioning issue, custom entry points seem bound to versions of the heat
> templates and data living there anyway. So it sounds reasonable to me to
> ship and version entrypoints among templates as a single bundle and
> please please please keep those out of images.
>
>> load a yaml file with the endpoint definitions and just iterate over
>> them and let Ansible handle the actual API calls...
>>
>> However, currently i can't see endpoint management in the cloud modules
>> docs [1], just service management. Looks like there's still a feature
>> gap at the moment.
>>
>> Jirka
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> 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



-- 
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] os-cloud-config retirement

[Bogdan Dobrelya]

On 31.03.2017 13:58, Jiří Stránský wrote:
> On 30.3.2017 17:39, Juan Antonio Osorio wrote:
>> Why not drive the post-config with something like shade over ansible?
>> Similar to what the kolla-ansible community is doing.
> 
> We could use those perhaps, if they bring enough benefit to add them to
> the container image(s) (i think we'd still want to drive it via a
> container rather than fully externally). It's quite tempting to just

I hope we still want to decouple configuration from distribution. Wrt
versioning issue, custom entry points seem bound to versions of the heat
templates and data living there anyway. So it sounds reasonable to me to
ship and version entrypoints among templates as a single bundle and
please please please keep those out of images.

> load a yaml file with the endpoint definitions and just iterate over
> them and let Ansible handle the actual API calls...
> 
> However, currently i can't see endpoint management in the cloud modules
> docs [1], just service management. Looks like there's still a feature
> gap at the moment.
> 
> Jirka


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] os-cloud-config retirement

[Jiří Stránský]

On 30.3.2017 17:39, Juan Antonio Osorio wrote:

Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.


We could use those perhaps, if they bring enough benefit to add them to 
the container image(s) (i think we'd still want to drive it via a 
container rather than fully externally). It's quite tempting to just 
load a yaml file with the endpoint definitions and just iterate over 
them and let Ansible handle the actual API calls...


However, currently i can't see endpoint management in the cloud modules 
docs [1], just service management. Looks like there's still a feature 
gap at the moment.


Jirka

[1] http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack



On 30 Mar 2017 16:42, "Jiří Stránský"  wrote:


On 30.3.2017 14:58, Dan Prince wrote:


There is one case that I was thinking about reusing this piece of code
within a container to help initialize keystone endpoints. It would
require some changes and updates (to match how puppet-* configures
endpoints).

For TripleO containers we use various puppet modules (along with hiera)
to drive the creation of endpoints. This functionally works fine, but
is quite slow to execute (puppet is slow here) and takes several
minutes to complete. I'm wondering if a single optimized python script
might serve us better here. It could be driven via YAML (perhaps
similar to our Hiera), idempotent, and likely much faster than having
the code driven by puppet. This doesn't have to live in os-cloud-
config, but initially I thought that might be a reasonable place for
it. It is worth pointing out that this would be something that would
need to be driven by our t-h-t workflow and not a post-installation
task. So perhaps that makes it not a good fit for os-cloud-config. But
it is similar to the keystone initialization already there so I thought
I'd mention it.



I agree we could have an optimized python script instead of puppet to do
the init. However, os-cloud-config also doesn't strike me as the ideal
place.

What might be interesting is solving the keystone init within containers
along with our container entrypoint situation. We've talked earlier that we
may have to build our custom entrypoints into the images as we sometimes
need to do things that the current entrypoints don't seem fit for, or don't
give us enough control over what happens. This single optimized python
script for endpoint config you mentioned could be one of such in-image
entrypoint scripts. We could build multiple different scripts like this
into a single image and select the right one when starting the container
(defaulting to a script that handles the usual "worker" case, in this case
Keystone API).

This gets somewhat similar to the os-cloud-config usecase, but even if we
wanted a separate repo, or even a RPM for these, i suppose it would be
cleaner to just start from scratch rather than repurpose os-cloud-config.

Jirka



Dan

On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:


Hi,

os-cloud-config was deprecated in the Ocata release and is going to
be
removed in Pike.

TripleO project doesn't need it anymore and after some investigation
in codesearch.openstack.org, nobody is using it in OpenStack.
I'm working on the removal this cycle, please let us know any
concern.

Thanks,




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
e
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





__
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] os-cloud-config retirement

[Jiří Stránský]

On 30.3.2017 18:02, Bogdan Dobrelya wrote:

On 30.03.2017 15:40, Jiří Stránský wrote:


What might be interesting is solving the keystone init within containers
along with our container entrypoint situation. We've talked earlier that
we may have to build our custom entrypoints into the images as we
sometimes need to do things that the current entrypoints don't seem fit
for, or don't give us enough control over what happens. This single
optimized python script for endpoint config you mentioned could be one
of such in-image entrypoint scripts. We could build multiple different


I'm concerned of having entry points in-image. Could it be mounted as a
hostpath instead, then executed? Custom entry-points could replace
existing ones this way. This would allow keep kolla or other images
clean from side changes.


That was actually my initial thought as well, but it means more 
entanglement between the containers and the bare-metal hosts, and 
creates some new issues.


E.g. it makes container image versioning harder. We'd need to implement 
additional logic to make sure we use the correct entrypoint version for 
a particular container image version (think rolling back to an older 
image but still using the newest entrypoint, perhaps those two not being 
fully compatible, and having the container crash because of this). This 
alone is quite disadvantageous IMO.


Jirka




scripts like this into a single image and select the right one when
starting the container (defaulting to a script that handles the usual


We could use a clean container and mount in that we need. Those entry
points looks similar to heat agent hooks, right? I think they should be
packaged as a separate artifacts.


"worker" case, in this case Keystone API).

This gets somewhat similar to the os-cloud-config usecase, but even if
we wanted a separate repo, or even a RPM for these, i suppose it would
be cleaner to just start from scratch rather than repurpose
os-cloud-config.

Jirka






__
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] os-cloud-config retirement

[Bogdan Dobrelya]

On 30.03.2017 15:40, Jiří Stránský wrote:
> 
> What might be interesting is solving the keystone init within containers
> along with our container entrypoint situation. We've talked earlier that
> we may have to build our custom entrypoints into the images as we
> sometimes need to do things that the current entrypoints don't seem fit
> for, or don't give us enough control over what happens. This single
> optimized python script for endpoint config you mentioned could be one
> of such in-image entrypoint scripts. We could build multiple different

I'm concerned of having entry points in-image. Could it be mounted as a
hostpath instead, then executed? Custom entry-points could replace
existing ones this way. This would allow keep kolla or other images
clean from side changes.

> scripts like this into a single image and select the right one when
> starting the container (defaulting to a script that handles the usual

We could use a clean container and mount in that we need. Those entry
points looks similar to heat agent hooks, right? I think they should be
packaged as a separate artifacts.

> "worker" case, in this case Keystone API).
> 
> This gets somewhat similar to the os-cloud-config usecase, but even if
> we wanted a separate repo, or even a RPM for these, i suppose it would
> be cleaner to just start from scratch rather than repurpose
> os-cloud-config.
> 
> Jirka


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] os-cloud-config retirement

[Alex Schultz]

On Thu, Mar 30, 2017 at 6:58 AM, Dan Prince  wrote:
> There is one case that I was thinking about reusing this piece of code
> within a container to help initialize keystone endpoints. It would
> require some changes and updates (to match how puppet-* configures
> endpoints).
>
> For TripleO containers we use various puppet modules (along with hiera)
> to drive the creation of endpoints. This functionally works fine, but
> is quite slow to execute (puppet is slow here) and takes several
> minutes to complete. I'm wondering if a single optimized python script
> might serve us better here. It could be driven via YAML (perhaps
> similar to our Hiera), idempotent, and likely much faster than having
> the code driven by puppet. This doesn't have to live in os-cloud-
> config, but initially I thought that might be a reasonable place for
> it. It is worth pointing out that this would be something that would
> need to be driven by our t-h-t workflow and not a post-installation
> task. So perhaps that makes it not a good fit for os-cloud-config. But
> it is similar to the keystone initialization already there so I thought
> I'd mention it.
>

Do we know why puppet is slow here? Since puppet is just executing the
openstack client, that usually is the culprit on these things.  While
it might be faster to write a python script to handle this, the
question becomes should we be using a different thing to accomplish
the same task as we're doing elsewhere?

Thanks,
-Alex

> Dan
>
> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>> Hi,
>>
>> os-cloud-config was deprecated in the Ocata release and is going to
>> be
>> removed in Pike.
>>
>> TripleO project doesn't need it anymore and after some investigation
>> in codesearch.openstack.org, nobody is using it in OpenStack.
>> I'm working on the removal this cycle, please let us know any
>> concern.
>>
>> Thanks,
>
> __
> 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] os-cloud-config retirement

[Juan Antonio Osorio]

Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.

On 30 Mar 2017 16:42, "Jiří Stránský"  wrote:

> On 30.3.2017 14:58, Dan Prince wrote:
>
>> There is one case that I was thinking about reusing this piece of code
>> within a container to help initialize keystone endpoints. It would
>> require some changes and updates (to match how puppet-* configures
>> endpoints).
>>
>> For TripleO containers we use various puppet modules (along with hiera)
>> to drive the creation of endpoints. This functionally works fine, but
>> is quite slow to execute (puppet is slow here) and takes several
>> minutes to complete. I'm wondering if a single optimized python script
>> might serve us better here. It could be driven via YAML (perhaps
>> similar to our Hiera), idempotent, and likely much faster than having
>> the code driven by puppet. This doesn't have to live in os-cloud-
>> config, but initially I thought that might be a reasonable place for
>> it. It is worth pointing out that this would be something that would
>> need to be driven by our t-h-t workflow and not a post-installation
>> task. So perhaps that makes it not a good fit for os-cloud-config. But
>> it is similar to the keystone initialization already there so I thought
>> I'd mention it.
>>
>
> I agree we could have an optimized python script instead of puppet to do
> the init. However, os-cloud-config also doesn't strike me as the ideal
> place.
>
> What might be interesting is solving the keystone init within containers
> along with our container entrypoint situation. We've talked earlier that we
> may have to build our custom entrypoints into the images as we sometimes
> need to do things that the current entrypoints don't seem fit for, or don't
> give us enough control over what happens. This single optimized python
> script for endpoint config you mentioned could be one of such in-image
> entrypoint scripts. We could build multiple different scripts like this
> into a single image and select the right one when starting the container
> (defaulting to a script that handles the usual "worker" case, in this case
> Keystone API).
>
> This gets somewhat similar to the os-cloud-config usecase, but even if we
> wanted a separate repo, or even a RPM for these, i suppose it would be
> cleaner to just start from scratch rather than repurpose os-cloud-config.
>
> Jirka
>
>
>> Dan
>>
>> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>>
>>> Hi,
>>>
>>> os-cloud-config was deprecated in the Ocata release and is going to
>>> be
>>> removed in Pike.
>>>
>>> TripleO project doesn't need it anymore and after some investigation
>>> in codesearch.openstack.org, nobody is using it in OpenStack.
>>> I'm working on the removal this cycle, please let us know any
>>> concern.
>>>
>>> Thanks,
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
__
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] os-cloud-config retirement

[Jiří Stránský]

On 30.3.2017 14:58, Dan Prince wrote:

There is one case that I was thinking about reusing this piece of code
within a container to help initialize keystone endpoints. It would
require some changes and updates (to match how puppet-* configures
endpoints).

For TripleO containers we use various puppet modules (along with hiera)
to drive the creation of endpoints. This functionally works fine, but
is quite slow to execute (puppet is slow here) and takes several
minutes to complete. I'm wondering if a single optimized python script
might serve us better here. It could be driven via YAML (perhaps
similar to our Hiera), idempotent, and likely much faster than having
the code driven by puppet. This doesn't have to live in os-cloud-
config, but initially I thought that might be a reasonable place for
it. It is worth pointing out that this would be something that would
need to be driven by our t-h-t workflow and not a post-installation
task. So perhaps that makes it not a good fit for os-cloud-config. But
it is similar to the keystone initialization already there so I thought
I'd mention it.


I agree we could have an optimized python script instead of puppet to do 
the init. However, os-cloud-config also doesn't strike me as the ideal 
place.


What might be interesting is solving the keystone init within containers 
along with our container entrypoint situation. We've talked earlier that 
we may have to build our custom entrypoints into the images as we 
sometimes need to do things that the current entrypoints don't seem fit 
for, or don't give us enough control over what happens. This single 
optimized python script for endpoint config you mentioned could be one 
of such in-image entrypoint scripts. We could build multiple different 
scripts like this into a single image and select the right one when 
starting the container (defaulting to a script that handles the usual 
"worker" case, in this case Keystone API).


This gets somewhat similar to the os-cloud-config usecase, but even if 
we wanted a separate repo, or even a RPM for these, i suppose it would 
be cleaner to just start from scratch rather than repurpose os-cloud-config.


Jirka



Dan

On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:

Hi,

os-cloud-config was deprecated in the Ocata release and is going to
be
removed in Pike.

TripleO project doesn't need it anymore and after some investigation
in codesearch.openstack.org, nobody is using it in OpenStack.
I'm working on the removal this cycle, please let us know any
concern.

Thanks,


__
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] os-cloud-config retirement

[Dan Prince]

There is one case that I was thinking about reusing this piece of code
within a container to help initialize keystone endpoints. It would
require some changes and updates (to match how puppet-* configures
endpoints).

For TripleO containers we use various puppet modules (along with hiera)
to drive the creation of endpoints. This functionally works fine, but
is quite slow to execute (puppet is slow here) and takes several
minutes to complete. I'm wondering if a single optimized python script
might serve us better here. It could be driven via YAML (perhaps
similar to our Hiera), idempotent, and likely much faster than having
the code driven by puppet. This doesn't have to live in os-cloud-
config, but initially I thought that might be a reasonable place for
it. It is worth pointing out that this would be something that would
need to be driven by our t-h-t workflow and not a post-installation
task. So perhaps that makes it not a good fit for os-cloud-config. But
it is similar to the keystone initialization already there so I thought
I'd mention it.

Dan

On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
> Hi,
> 
> os-cloud-config was deprecated in the Ocata release and is going to
> be
> removed in Pike.
> 
> TripleO project doesn't need it anymore and after some investigation
> in codesearch.openstack.org, nobody is using it in OpenStack.
> I'm working on the removal this cycle, please let us know any
> concern.
> 
> Thanks,

__
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] os-cloud-config

[Ladislav Smola]

Hello,

we call it from UI after the deployment 
https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overview/forms.py#L222 
.
There should be conversation on the summit whether to do the call from 
somewhere else (tuskar, template..).


Kind Regards,
Ladislav


On 10/30/2014 01:47 PM, LeslieWang wrote:

Dear all,

Seems like os-cloud-config is to initialise uncercloud or overcloud 
after heat orchestration. But I can not find how it is used in either 
tuskar, or tuskar-UI. So can anyone explain a little bit how it is 
used in TripleO projects? Thanks.


Best Regards
Leslie Wang


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Jiří Stránský]

(Removing [Heat] from the subject.)

So here are the steps i think are necessary to get the PKI setup done 
and safely passed through Jenkins. If anyone thinks something is 
redundant or missing, please shout:


1. Patch to os-cloud-config:

  * Generation of keys and certs for cases user doesn't want to
specify their own - mainly PoC deployments. (Generation happens
in-memory, which is better for Tuskar than having to write
keys/certs to disk - we might have different sets for different
overclouds.)

  * Implement also a function that will write the keys/certs to a
specified location on disk (in-memory generation is not well
suited for use within Devtest).

2. Patch to T-I-E:

  * os-cloud-config image element.

3. Patch to tripleo-incubator (dependent on patches 1 and 2):

  * Generate keys using os-cloud-config and pass them into heat-create
if the T-H-T supports that (this is to make sure the next T-H-T
patch passes). Keep doing the current init-keystone anyway.

4. Patch to T-H-T (dependent on patch 3):

  * Accept 3 new parameters for controller nodes: KeystoneCACert,
KeystoneSigningKey, KeystoneSigningCert. Default them to empty
string so that they are not required (otherwise we'd have to
implement logic forking also for Tuskar, because it's
chicken-and-egg there too).

5. Patch to tuskar (dependent on patch 4):

  * Use os-cloud-config to generate keys and certs if user didn't
specify their own, pass new parameters to T-H-T.

6. Patch to T-I-E (dependent on patch 5):

  * Add the certs and signing key to keystone's os-apply-config
templates. Change key location to /etc instead of
/mnt/state/etc. Devtest should keep working because calling
`keystone-manage pki_setup` on already initialized system does not
have significant effect. It will keep generating a useless CA key,
but that will stop with patch 7.

7. Cleanup patch to tripleo-incubator (dependent on patch 6):

  * Remove conditional on passing the 3 new parameters only if
supported, pass them always.

  * Remove call to pki_setup.


Regarding the cloud initialization as a whole, on monday i sent a patch 
for creating users, roles etc. [1]. The parts still missing are endpoint 
registration [2,3] and neutron setup [4].


If anyone is willing to spare some cycles on endpoint registration or 
neturon setup or make the image element for os-cloud-config (patch no. 2 
in above list), it would be great, as we'd like to have this finished as 
soon as possible.



Thanks

Jirka

[1] https://review.openstack.org/#/c/78148/
[2] 
https://github.com/openstack/tripleo-incubator/blob/4e2e8de41ba91a5699ea4eb9091f6ef4c95cf0ce/scripts/init-keystone#L111-L114
[3] 
https://github.com/openstack/tripleo-incubator/blob/4e2e8de41ba91a5699ea4eb9091f6ef4c95cf0ce/scripts/setup-endpoints
[4] 
https://github.com/openstack/tripleo-incubator/blob/4e2e8de41ba91a5699ea4eb9091f6ef4c95cf0ce/scripts/setup-neutron


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Clint Byrum]

Excerpts from Adam Young's message of 2014-03-12 06:19:47 -0700:
 On 03/11/2014 01:20 PM, Clint Byrum wrote:
  Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:
  On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
  For what it's worth in Sahara (former Savanna) we inject the second
  key by userdata. I.e. we add
  echo ${public_key}  ${user_home}/.ssh/authorized_keys
 
  to the other stuff we do in userdata.
 
  Dmitry
 
  2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:
  On 7.3.2014 14:50, Imre Farkas wrote:
  On 03/07/2014 10:30 AM, Jiří Stránský wrote:
  Hi,
 
  there's one step in cloud initialization that is performed over SSH --
  calling keystone-manage pki_setup. Here's the relevant code in
  keystone-init [1], here's a review for moving the functionality to
  os-cloud-config [2].
  You really should not be doing this.  I should never have written
  pki_setup:  it is a developers tool:  user a real CA and a real 
  certificate.
 
  This alludes to your point, but also says that keystone-manage can be used:
 
  http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki
 Yep.  And we need to get a better story for certificate management.
 
  Seems that some time should be spent making this more clear if for some
  reason pki_setup is weak for production use cases. My brief analysis
  of the code says that the weakness is that the CA should generally be
  kept apart from the CSR's so that a compromise of a node does not lead
  to an attacker being able to generate their own keystone service. This
  seems like a low probability attack vector, as compromise of the keystone
  machines also means write access to the token backend, and thus no need
  to generate ones' own tokens (you can just steal all the existing tokens).
 
 This is a pretty good explanation.  I would love to see it submitted as 
 part of the keystone configuration document above.
 

Thanks!

https://review.openstack.org/80819

 
  I'd like to see it called out in the section above though, so that
  users can know what risk their accepting when they use what looks like a
  recommended tool. Another thing would be to log copious warnings when
  pki_setup is run that it is not for production usage. That should be
  sufficient to scare some diligent deployers into reading the docs closely
  and mitigating the risk.
 Very good idea.
 
 
  Anyway, shaking fist at users and devs in -dev for using tools in the
  documentation probably _isn't_ going to convince anyone to spend more
  time setting up PKI tokens.
 
 The only one I am shaking my fist at is myself...and maybe those that 
 browbeat me into writing the utility.
 

I recommend we aim for less fist shaking and beating of all kinds in
OpenStack.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Adam Young]

On 03/11/2014 01:20 PM, Clint Byrum wrote:

Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:

On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:

For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key}  ${user_home}/.ssh/authorized_keys

to the other stuff we do in userdata.

Dmitry

2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:

On 7.3.2014 14:50, Imre Farkas wrote:

On 03/07/2014 10:30 AM, Jiří Stránský wrote:

Hi,

there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].

You really should not be doing this.  I should never have written
pki_setup:  it is a developers tool:  user a real CA and a real certificate.


This alludes to your point, but also says that keystone-manage can be used:

http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki

Yep.  And we need to get a better story for certificate management.


Seems that some time should be spent making this more clear if for some
reason pki_setup is weak for production use cases. My brief analysis
of the code says that the weakness is that the CA should generally be
kept apart from the CSR's so that a compromise of a node does not lead
to an attacker being able to generate their own keystone service. This
seems like a low probability attack vector, as compromise of the keystone
machines also means write access to the token backend, and thus no need
to generate ones' own tokens (you can just steal all the existing tokens).


This is a pretty good explanation.  I would love to see it submitted as 
part of the keystone configuration document above.




I'd like to see it called out in the section above though, so that
users can know what risk their accepting when they use what looks like a
recommended tool. Another thing would be to log copious warnings when
pki_setup is run that it is not for production usage. That should be
sufficient to scare some diligent deployers into reading the docs closely
and mitigating the risk.

Very good idea.



Anyway, shaking fist at users and devs in -dev for using tools in the
documentation probably _isn't_ going to convince anyone to spend more
time setting up PKI tokens.


The only one I am shaking my fist at is myself...and maybe those that 
browbeat me into writing the utility.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Jiří Stránský]

On 11.3.2014 15:50, Adam Young wrote:

On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:

For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key}  ${user_home}/.ssh/authorized_keys

to the other stuff we do in userdata.

Dmitry

2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:

On 7.3.2014 14:50, Imre Farkas wrote:

On 03/07/2014 10:30 AM, Jiří Stránský wrote:

Hi,

there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].


You really should not be doing this.  I should never have written
pki_setup:  it is a developers tool:  user a real CA and a real certificate.


Thanks for all the replies everyone :)

I'm leaning towards going the way Robert suggested on the review [1] - 
upload pre-created signing cert, signing key and CA cert to controller 
nodes using Heat. This seems like a much cleaner approach to 
initializing overcloud than having to SSH into it, and it will solve 
both problems i outlined in the initial e-mail.


It creates another problem though - for simple (think PoC) deployments 
without external CA we'll need to create the keys/certs 
somehow/somewhere anyway :) It shouldn't be hard because it's already 
implemented in keystone-manage pki_setup but we should figure out a way 
to avoid copy-pasting the world. Maybe Tuskar calling pki_setup locally 
and passing a parameter to pki_setup to override default location where 
new keys/certs will be generated?



Thanks

Jirka

[1] https://review.openstack.org/#/c/78148/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Dmitry Mescheryakov]

For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key}  ${user_home}/.ssh/authorized_keys

to the other stuff we do in userdata.

Dmitry

2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:
 On 7.3.2014 14:50, Imre Farkas wrote:

 On 03/07/2014 10:30 AM, Jiří Stránský wrote:

 Hi,

 there's one step in cloud initialization that is performed over SSH --
 calling keystone-manage pki_setup. Here's the relevant code in
 keystone-init [1], here's a review for moving the functionality to
 os-cloud-config [2].

 The consequence of this is that Tuskar will need passwordless ssh key to
 access overcloud controller. I consider this suboptimal for two reasons:

 * It creates another security concern.

 * AFAIK nova is only capable of injecting one public SSH key into
 authorized_keys on the deployed machine, which means we can either give
 it Tuskar's public key and allow Tuskar to initialize overcloud, or we
 can give it admin's custom public key and allow admin to ssh into
 overcloud, but not both. (Please correct me if i'm mistaken.) We could
 probably work around this issue by having Tuskar do the user key
 injection as part of os-cloud-config, but it's a bit clumsy.


 This goes outside the scope of my current knowledge, i'm hoping someone
 knows the answer: Could pki_setup be run by combining powers of Heat and
 os-config-refresh? (I presume there's some reason why we're not doing
 this already.) I think it would help us a good bit if we could avoid
 having to SSH from Tuskar to overcloud.


 Yeah, it came up a couple times on the list. The current solution is
 because if you have an HA setup, the nodes can't decide on its own,
 which one should run pki_setup.
 Robert described this topic and why it needs to be initialized
 externally during a weekly meeting in last December. Check the topic
 'After heat stack-create init operations (lsmola)':

 http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html


 Thanks for the reply Imre. Yeah i vaguely remember that meeting :)

 I guess to do HA init we'd need to pick one of the controllers and run the
 init just there (set some parameter that would then be recognized by
 os-refresh-config). I couldn't find if Heat can do something like this on
 it's own, probably we'd need to deploy one of the controller nodes with
 different parameter set, which feels a bit weird.

 Hmm so unless someone comes up with something groundbreaking, we'll probably
 keep doing what we're doing. Having the ability to inject multiple keys to
 instances [1] would help us get rid of the Tuskar vs. admin key issue i
 mentioned in the initial e-mail. We might try asking a fellow Nova developer
 to help us out here.


 Jirka

 [1] https://bugs.launchpad.net/nova/+bug/917850


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Adam Young]

On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:

For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key}  ${user_home}/.ssh/authorized_keys

to the other stuff we do in userdata.

Dmitry

2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:

On 7.3.2014 14:50, Imre Farkas wrote:

On 03/07/2014 10:30 AM, Jiří Stránský wrote:

Hi,

there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].


You really should not be doing this.  I should never have written 
pki_setup:  it is a developers tool:  user a real CA and a real certificate.




The consequence of this is that Tuskar will need passwordless ssh key to
access overcloud controller. I consider this suboptimal for two reasons:

* It creates another security concern.

* AFAIK nova is only capable of injecting one public SSH key into
authorized_keys on the deployed machine, which means we can either give
it Tuskar's public key and allow Tuskar to initialize overcloud, or we
can give it admin's custom public key and allow admin to ssh into
overcloud, but not both. (Please correct me if i'm mistaken.) We could
probably work around this issue by having Tuskar do the user key
injection as part of os-cloud-config, but it's a bit clumsy.


This goes outside the scope of my current knowledge, i'm hoping someone
knows the answer: Could pki_setup be run by combining powers of Heat and
os-config-refresh? (I presume there's some reason why we're not doing
this already.) I think it would help us a good bit if we could avoid
having to SSH from Tuskar to overcloud.


Yeah, it came up a couple times on the list. The current solution is
because if you have an HA setup, the nodes can't decide on its own,
which one should run pki_setup.
Robert described this topic and why it needs to be initialized
externally during a weekly meeting in last December. Check the topic
'After heat stack-create init operations (lsmola)':

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html


Thanks for the reply Imre. Yeah i vaguely remember that meeting :)

I guess to do HA init we'd need to pick one of the controllers and run the
init just there (set some parameter that would then be recognized by
os-refresh-config). I couldn't find if Heat can do something like this on
it's own, probably we'd need to deploy one of the controller nodes with
different parameter set, which feels a bit weird.

Hmm so unless someone comes up with something groundbreaking, we'll probably
keep doing what we're doing. Having the ability to inject multiple keys to
instances [1] would help us get rid of the Tuskar vs. admin key issue i
mentioned in the initial e-mail. We might try asking a fellow Nova developer
to help us out here.


Jirka

[1] https://bugs.launchpad.net/nova/+bug/917850


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Clint Byrum]

Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:
 On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
  For what it's worth in Sahara (former Savanna) we inject the second
  key by userdata. I.e. we add
  echo ${public_key}  ${user_home}/.ssh/authorized_keys
 
  to the other stuff we do in userdata.
 
  Dmitry
 
  2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:
  On 7.3.2014 14:50, Imre Farkas wrote:
  On 03/07/2014 10:30 AM, Jiří Stránský wrote:
  Hi,
 
  there's one step in cloud initialization that is performed over SSH --
  calling keystone-manage pki_setup. Here's the relevant code in
  keystone-init [1], here's a review for moving the functionality to
  os-cloud-config [2].
 
 You really should not be doing this.  I should never have written 
 pki_setup:  it is a developers tool:  user a real CA and a real certificate.
 

This alludes to your point, but also says that keystone-manage can be used:

http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki

Seems that some time should be spent making this more clear if for some
reason pki_setup is weak for production use cases. My brief analysis
of the code says that the weakness is that the CA should generally be
kept apart from the CSR's so that a compromise of a node does not lead
to an attacker being able to generate their own keystone service. This
seems like a low probability attack vector, as compromise of the keystone
machines also means write access to the token backend, and thus no need
to generate ones' own tokens (you can just steal all the existing tokens).

I'd like to see it called out in the section above though, so that
users can know what risk their accepting when they use what looks like a
recommended tool. Another thing would be to log copious warnings when
pki_setup is run that it is not for production usage. That should be
sufficient to scare some diligent deployers into reading the docs closely
and mitigating the risk.

Anyway, shaking fist at users and devs in -dev for using tools in the
documentation probably _isn't_ going to convince anyone to spend more
time setting up PKI tokens.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Clint Byrum]

Excerpts from Jiří Stránský's message of 2014-03-10 06:10:46 -0700:
 On 7.3.2014 14:50, Imre Farkas wrote:
  On 03/07/2014 10:30 AM, Jiří Stránský wrote:
  Hi,
 
  there's one step in cloud initialization that is performed over SSH --
  calling keystone-manage pki_setup. Here's the relevant code in
  keystone-init [1], here's a review for moving the functionality to
  os-cloud-config [2].
 
  The consequence of this is that Tuskar will need passwordless ssh key to
  access overcloud controller. I consider this suboptimal for two reasons:
 
  * It creates another security concern.
 
  * AFAIK nova is only capable of injecting one public SSH key into
  authorized_keys on the deployed machine, which means we can either give
  it Tuskar's public key and allow Tuskar to initialize overcloud, or we
  can give it admin's custom public key and allow admin to ssh into
  overcloud, but not both. (Please correct me if i'm mistaken.) We could
  probably work around this issue by having Tuskar do the user key
  injection as part of os-cloud-config, but it's a bit clumsy.
 
 
  This goes outside the scope of my current knowledge, i'm hoping someone
  knows the answer: Could pki_setup be run by combining powers of Heat and
  os-config-refresh? (I presume there's some reason why we're not doing
  this already.) I think it would help us a good bit if we could avoid
  having to SSH from Tuskar to overcloud.
 
  Yeah, it came up a couple times on the list. The current solution is
  because if you have an HA setup, the nodes can't decide on its own,
  which one should run pki_setup.
  Robert described this topic and why it needs to be initialized
  externally during a weekly meeting in last December. Check the topic
  'After heat stack-create init operations (lsmola)':
  http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html
 
 Thanks for the reply Imre. Yeah i vaguely remember that meeting :)
 
 I guess to do HA init we'd need to pick one of the controllers and run 
 the init just there (set some parameter that would then be recognized by 
 os-refresh-config). I couldn't find if Heat can do something like this 
 on it's own, probably we'd need to deploy one of the controller nodes 
 with different parameter set, which feels a bit weird.
 
 Hmm so unless someone comes up with something groundbreaking, we'll 
 probably keep doing what we're doing. Having the ability to inject 
 multiple keys to instances [1] would help us get rid of the Tuskar vs. 
 admin key issue i mentioned in the initial e-mail. We might try asking a 
 fellow Nova developer to help us out here.
 

I think the long term idea is to run a separate CA and use Barbican for
key distribution, as that is precisely what it is designed to do.

For now SSH'ing in one time to bootstrap a cloud seems an acceptable
risk, and the scope of that SSH key can be ratcheted down to just running
pki_setup, which may be a good idea.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Jiří Stránský]

On 7.3.2014 14:50, Imre Farkas wrote:

On 03/07/2014 10:30 AM, Jiří Stránský wrote:

Hi,

there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].

The consequence of this is that Tuskar will need passwordless ssh key to
access overcloud controller. I consider this suboptimal for two reasons:

* It creates another security concern.

* AFAIK nova is only capable of injecting one public SSH key into
authorized_keys on the deployed machine, which means we can either give
it Tuskar's public key and allow Tuskar to initialize overcloud, or we
can give it admin's custom public key and allow admin to ssh into
overcloud, but not both. (Please correct me if i'm mistaken.) We could
probably work around this issue by having Tuskar do the user key
injection as part of os-cloud-config, but it's a bit clumsy.


This goes outside the scope of my current knowledge, i'm hoping someone
knows the answer: Could pki_setup be run by combining powers of Heat and
os-config-refresh? (I presume there's some reason why we're not doing
this already.) I think it would help us a good bit if we could avoid
having to SSH from Tuskar to overcloud.


Yeah, it came up a couple times on the list. The current solution is
because if you have an HA setup, the nodes can't decide on its own,
which one should run pki_setup.
Robert described this topic and why it needs to be initialized
externally during a weekly meeting in last December. Check the topic
'After heat stack-create init operations (lsmola)':
http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html


Thanks for the reply Imre. Yeah i vaguely remember that meeting :)

I guess to do HA init we'd need to pick one of the controllers and run 
the init just there (set some parameter that would then be recognized by 
os-refresh-config). I couldn't find if Heat can do something like this 
on it's own, probably we'd need to deploy one of the controller nodes 
with different parameter set, which feels a bit weird.


Hmm so unless someone comes up with something groundbreaking, we'll 
probably keep doing what we're doing. Having the ability to inject 
multiple keys to instances [1] would help us get rid of the Tuskar vs. 
admin key issue i mentioned in the initial e-mail. We might try asking a 
fellow Nova developer to help us out here.



Jirka

[1] https://bugs.launchpad.net/nova/+bug/917850

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[James Slagle]

On Mon, Mar 10, 2014 at 6:10 AM, Jiří Stránský ji...@redhat.com wrote:
 On 7.3.2014 14:50, Imre Farkas wrote:

 On 03/07/2014 10:30 AM, Jiří Stránský wrote:

 Hi,

 there's one step in cloud initialization that is performed over SSH --
 calling keystone-manage pki_setup. Here's the relevant code in
 keystone-init [1], here's a review for moving the functionality to
 os-cloud-config [2].

 The consequence of this is that Tuskar will need passwordless ssh key to
 access overcloud controller. I consider this suboptimal for two reasons:

 * It creates another security concern.

 * AFAIK nova is only capable of injecting one public SSH key into
 authorized_keys on the deployed machine, which means we can either give
 it Tuskar's public key and allow Tuskar to initialize overcloud, or we
 can give it admin's custom public key and allow admin to ssh into
 overcloud, but not both. (Please correct me if i'm mistaken.) We could
 probably work around this issue by having Tuskar do the user key
 injection as part of os-cloud-config, but it's a bit clumsy.


 This goes outside the scope of my current knowledge, i'm hoping someone
 knows the answer: Could pki_setup be run by combining powers of Heat and
 os-config-refresh? (I presume there's some reason why we're not doing
 this already.) I think it would help us a good bit if we could avoid
 having to SSH from Tuskar to overcloud.


 Yeah, it came up a couple times on the list. The current solution is
 because if you have an HA setup, the nodes can't decide on its own,
 which one should run pki_setup.
 Robert described this topic and why it needs to be initialized
 externally during a weekly meeting in last December. Check the topic
 'After heat stack-create init operations (lsmola)':

 http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html


 Thanks for the reply Imre. Yeah i vaguely remember that meeting :)

 I guess to do HA init we'd need to pick one of the controllers and run the
 init just there (set some parameter that would then be recognized by
 os-refresh-config). I couldn't find if Heat can do something like this on
 it's own, probably we'd need to deploy one of the controller nodes with
 different parameter set, which feels a bit weird.

 Hmm so unless someone comes up with something groundbreaking, we'll probably
 keep doing what we're doing.

Agreed,  I think what you've done here is fine.

As you keep churning through init-keystone, keep in mind that there
are some recent changes in review[1] that switch that script over to
use openstack-client instead of keystoneclient. That was needed due to
the required use of the keystone v3 api to create a domain for the
heat stack user. A fallback backwards compatibility was added to Heat
to allow the existing behavior to still work, but I don't see a reason
for you to reimplement the old way of doings things in
os-cloud-config. There is a helper script[2] in Heat that shows how
the domain should be created.

[1] https://review.openstack.org/#/c/78020/
[2] http://git.openstack.org/cgit/openstack/heat/tree/tools/create_heat_domain

 Having the ability to inject multiple keys to
 instances [1] would help us get rid of the Tuskar vs. admin key issue i
 mentioned in the initial e-mail. We might try asking a fellow Nova developer
 to help us out here.


 Jirka

 [1] https://bugs.launchpad.net/nova/+bug/917850


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
-- James Slagle
--

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

[Imre Farkas]

On 03/07/2014 10:30 AM, Jiří Stránský wrote:

Hi,

there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].

The consequence of this is that Tuskar will need passwordless ssh key to
access overcloud controller. I consider this suboptimal for two reasons:

* It creates another security concern.

* AFAIK nova is only capable of injecting one public SSH key into
authorized_keys on the deployed machine, which means we can either give
it Tuskar's public key and allow Tuskar to initialize overcloud, or we
can give it admin's custom public key and allow admin to ssh into
overcloud, but not both. (Please correct me if i'm mistaken.) We could
probably work around this issue by having Tuskar do the user key
injection as part of os-cloud-config, but it's a bit clumsy.


This goes outside the scope of my current knowledge, i'm hoping someone
knows the answer: Could pki_setup be run by combining powers of Heat and
os-config-refresh? (I presume there's some reason why we're not doing
this already.) I think it would help us a good bit if we could avoid
having to SSH from Tuskar to overcloud.


Yeah, it came up a couple times on the list. The current solution is 
because if you have an HA setup, the nodes can't decide on its own, 
which one should run pki_setup.
Robert described this topic and why it needs to be initialized 
externally during a weekly meeting in last December. Check the topic 
'After heat stack-create init operations (lsmola)': 
http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html


Imre


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev