On Thu, Sep 3, 2015 at 6:46 AM, Steven Hardy <[email protected]> wrote: > On Wed, Sep 02, 2015 at 08:32:25PM -0400, James Slagle wrote: >> On Wed, Sep 2, 2015 at 4:22 PM, Dan Prince <[email protected]> wrote: >> > We had an IRC discussion today about the 'heat-admin' user in #tripleo. >> > >> > Upstream Heat recently reverted the 'instance_user' config file option >> > which we relied on in TripleO to standardize the default (admin) user >> > on our nodes. It is my understanding that Heat would prefer not to >> > maintain this option because it causes subtle compatibility issues >> > across the OpenStack and AWS APIs and the interactions between cloud >> > -init version, etc. So it was deprecated in Icehouse... and recently >> > removed in [1]. >> > >> > We could just go with the default distro user (centos, fedora, ubuntu, >> > etc.) but it would be really nice to standardize on a user name for >> > maintenance should anyone every spin up a cloud using multiple distros >> > or something. >> > >> > So a couple of options. We could just go on and update our templates >> > like this [2]. This actually seems pretty clean to me, but it would >> > require anybody who has created custom firstboot scripts to do the same >> > (we have proposed docker patches with firstboot scripts that need >> > similar updates). >> >> Yea, that's the main reason I'm not fond of this approach. It really >> feels like cluttering up the firstboot interface, in that anyone who >> wants to plugin in their own config there has to remember to also >> include this snippet. It leads to copying/pasting around yaml, which I >> don't think is a great pattern going forward. > > Yeah, I agree, so I proposed an alternative approach: > > https://review.openstack.org/#/c/220057/ > > This leaves the existing NodeUserData interface intact, and introduces a > new NodeAdminUserData interface (which is specifically for injecting the > admin user, and leaves the existing interface alone).
This looks like a nice solution, and it addresses the concern. Thanks for pulling it together. > >> It would be nice to have a cleaner separation between the interfaces >> that we offer to users and those that need to be reserved/used for >> TripleO's own purposes. > > Agreed, that's what I was aiming for with my patch above, we should > probably work towards more clearly documenting what's supported "external" > vs internal interfaces tho. > >> I'm not sure of a better solution though other than a native >> SoftwareDeployment resource in the templates directly that creates a >> known user and reads the ssh keys from the user data (via a script). > > I think it's better to avoid using SoftwareDeployment resources for this > if possible, because you really want the user configured as early as > possible for easier debugging e.g when credentials or network are broken > and SoftwareDeployments don't work because occ can't reach heat. > >> Or, what about baking in some static configuration for cloud-init into >> our images that creates the known user? > > That could work, but you'd still need a user-data script to collect the SSH > key from the nova metadata server, because we won't know that at > image-build time. > > You're right tho, this probably could be built into the image, it just > seems a little more flexible to expose it in the templates. > >> > Alternately, we could propose that Heat revert the instance_user >> > feature or some version of it. We've been using that for a year or two >> > now and it has actually been fairly nice to set the default that way. >> >> I really liked having the one consistent user no matter the cloud >> image you deployed from as well. I'm not sure we could successfully >> persuade it to go back in though given it was deprecated in Icehouse. > > So, I don't think this is impossible, but let me try to explain/remember > the reasons for removing it: > > 1. Many users disliked that we injected a non-default user and wanted > transparency, e.g just let them configure the users they want via > cloud-init vs "hidden" configuration injected via heat. This actually > originated with Clint, back in 2013[1] and was also flagged as impacting > TripleO back in 2014. > > 2. We have historically to maintain code to inject this user which works > over a wide range of cloud-init versions [2] This has proven to be very > difficult, for various reasons, including: > - It's impossible to find a cloud-config syntax which works over all > versions of cloud-init we (heat) expect to support (e.g Ubuntu 12.04 LTS > still ships 0.6.3 which doesn't support cloud-config syntax *at all*, > and it's expected to be supported until 2017). > - The alternative to cloud-config was an approach which injects a boothook > to create the user, but this ran into issues on systems with selinux > which were difficult/impossible to resolve in a way compatible with > 0.6.3. > > So, IIRC, we reached the conclusion that it made sense to just punt the > decision of what users to create, and how to create them to the template > author, who will presumably know if they want a user created, and if so > what version of cloud-init they expect to support in their images > (something the deployers and/or template authors know but heat maintainers > can't possibly know with any confidence). > > There are other advantages to the config-via-template approach too, e.g > what if you wanted to create a different admin user per cloud when TripleO > supports deploying multiple overclouds? Or if a deployer wanted to inject > some additional user configuration such as SSH keys or group membership, > sudo rules, whatever. All of this is easy via templates and impossible via > the hard-coded instance_user option. > > On balance, I think we're best to let the removal of instance_user stand, > and go with the template approach I proposed above, but I'm still open to > discussing it if folks feel strongly otherwise :) Yea, makes sense, thanks for the recap. I think the patch you've proposed will work out. -- -- James Slagle -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
