In future native Heat templates, we should leave the image users alone on servers

[Clint Byrum]

Right now we always force the user to the instance_user. https://bugs.launchpad.net/heat/+bug/1229825 suggests that we also allow overriding that per server, which would be a backward compatible change.

At some point though, we should introduce a new heat template version which deprecates the assumption that instance_user will be set up on the host, and lets image defaults dictate the user to create/configure.

[Steven Hardy (shardy)]

There are a few other ways to approach this which wouldn't require a new template version:

- global conf option "instance_user = None"
- optional additional instance_user_disable flag property to OS::Nova::Server
- better cloud-init integration, which allows the user to specify the users: default option to cloud-config via instance UserData

[Pavlo Shchelokovskyy (pshchelo)]

Related (and fixed) bug https://bugs.launchpad.net/heat/+bug/1257410

instance_user is long declared deprecated already. We should have removed in in Juno, but missed the time. The patch removing this option is on review

https://review.openstack.org/#/c/103928/

though needs an accompanying Tempest change first, on review

https://review.openstack.org/#/c/120749/

[Clint Byrum (clint-fewbar)]

This is something that is being deprecated, so we need to react quickly. We'll end up with per-OS users instead of 'heat-admin', which is an incompatible interface change for SSH-based interactions.

[James Polley (tchaypo)]

It's not immediately clear to me what needs to happen here. It sounds like we either need a map of distro->user, or instance->user, or we need to rework our templates to be injecting a special tripleo user into everything we touch. I'm not sure which is preferable, so I'll follow up in channel.

[Steven Hardy (shardy)]

Clint: If this feature is actually useful/needed to TripleO, would it be better for Heat to not remove instance_user, but instead just flip the default to not create any user?

Then the instance_user=heat-admin in tripleo-image-elements/elements/heat/os-apply-config/etc/heat/heat.conf would still work, but we'd achieve (AIUI) the objective of the deprecation, which was to stop creating default users on native server resources?

[James Polley (tchaypo)]

I had a chat to shardy and shadower after today's meeting about this.

If we want to avoid using heat-admin, it looks like we should be able to set a property on the images as we load them into glance (--property instance_user=ubuntu). Then we can simply query nova to find the image an instance is using, and query glance to find the instance_user for that image. It's probably nicer if the tool we use to do this can cache the lookups (at least the image->user mapping) to save time.

However, while I was writing this, I started wondering if Glance will allow us to delete an image that is still used by >-1 instance? If so, we could end up with instances for which we can't map to an instance_user because the image has been updated

[Clint Byrum (clint-fewbar)]

Re the old feature of making a single stable user: I think it was a crutch and we need to walk on our own.

This goes way back to what TripleO is supposed to be: OpenStack deployed like a cloud application. Users expect that the management user will be OS specific. So Ubuntu users expect 'ubuntu', and Fedora users expect 'fedora', etc. etc.

If we really do want to, we can bake in an 'openstack' user into our images and tell cloud-init to install the authorized_keys for it, set it up with sudo, etc. But I'd rather we just use the image default, and react accordingly in the very few places we need to SSH in (os-cloud-config, CI, anywhere else?)

[James Polley (tchaypo)]

With some help from greghaynes last night we had a quick dig and only found one place where the heat-admin user is referenced - and that's in a call to init-keystone, which we think is either already not using the credential, or will be switched to not use it very shortly.

The only other use we're aware of is that the account comes in handy for humans to use to connect to running instances. Fortunately humans are somewhat adaptable and should be able to adjust to using a different username with just a small amount of documentation changing.

On this basis I'm dropping the priority down to medium; it seems likely we won't need to do any work specifically to fix this, as init-keystone should either be already fixed or fixed very soon.

[Gregory Haynes (greghaynes)]

To further clarify - currently, we do not ssh into hosts to initialize keystone. Unfortunately, there is a bug as a result of this (https://bugs.launchpad.net/tripleo/+bug/1401300) which might cause us to resurrect our dependency on ssh in the near future.

Long term, we should be using barbican or a similar secret store to transfer TLS keys to the hosts they belong on, at which point this problem can go away for good.

+1 on lowering priotity for now. If/when this becomes a bigger issue we can raise it.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/219861

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/220057

[Steven Hardy (shardy)]

The patch I just posted allows for template level configuration of the required additional user.

By default it reinstates the heat-admin user, since the instance_user option has now been removed from heat, but if that isn't desired it's as simple as changing one line in the environment to either disable the user or do some other cloud-init config.

I think this gives the best of both worlds - we can have the heat-admin user for CI convenience (getting logs etc with a known user) and we can allow deployers to make a choice about configuring admin access however they want, without heat doing anything hidden via boothooks etc.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dan Prince (<email address hidden>) on branch: master
Review: https://review.openstack.org/219861

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/220057
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=d578cf1ac057643428eba77c3c0a0d31b9db6ad3
Submitter: Jenkins
Branch: master

commit d578cf1ac057643428eba77c3c0a0d31b9db6ad3
Author: Steven Hardy <email address hidden>
Date: Thu Sep 3 10:38:59 2015 +0100

    Add NodeAdminUserData interface for "heat-admin" user

    Reinstates the heat-admin user via template user-data, which
    replaces the previous boothook injected user provided by the
    (deprecated now removed) heat instance_user option.

    This has some advantages over the heat.conf option, e.g it allows
    for much easier customzation of the user configuration (additional
    SSH keys, adding groups etc), and also in future if we support
    deploying more than one overcloud you could specify a different
    user per deployment.

    Co-Authored-By: Dan Prince <email address hidden>
    Change-Id: I2235b9690c01542d8a28ec1c1a4607de751aea29
    Closes-Bug: #1229849