Open Stack

On Thu, Sep 3, 2015 at 6:46 AM, Steven Hardy <shardy at redhat.com> 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 <dprince at redhat.com> 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
--