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
