Re: [openstack-dev] [tripleo] os-cloud-config retirement
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
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
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
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
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
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
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
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
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
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
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
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
[openstack-dev] [tripleo] os-cloud-config retirement
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, -- 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] os-cloud-config 6.0.0.0rc1 (ocata)
Hello everyone, A new release candidate for os-cloud-config for the end of the Ocata cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/os-cloud-config/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Ocata release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/ocata release branch at: http://git.openstack.org/cgit/openstack/os-cloud-config/log/?h=stable/ocata Release notes for os-cloud-config can be found at: http://docs.openstack.org/releasenotes/os-cloud-config/ __ 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
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
[openstack-dev] [Tripleo] os-cloud-config
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 RegardsLeslie Wang ___ 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
(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
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ý : > 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
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ý : 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
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ý : 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
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
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ý : > >> 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
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ý : 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
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ý : > 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
On Mon, Mar 10, 2014 at 6:10 AM, Jiří Stránský 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
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
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
[openstack-dev] [TripleO] os-cloud-config ssh access to cloud
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. Thanks Jirka [1] https://github.com/openstack/tripleo-incubator/blob/4e2e8de41ba91a5699ea4eb9091f6ef4c95cf0ce/scripts/init-keystone#L85-L86 [2] 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