[PKG-Openstack-devel] No admin/service users is created

[Turbo Fredriksson]

On 7 Dec 2016, at 08:13, Thomas Goirand <zigo at debian.org> wrote:

>>> Should we then ask for tenant, login and pass, to be able to create the user?
>> 
>> We already have that information. You’ve already asked it..
> 
> We don't. We only have the IP/hostname address of Keystone and what we
> intend to write in the config file as tenant/username/pass, but not the
> tenant/username/pass of an admin user able to add new accounts.

These are the questions you ask for for EVERY package!

	*/mysql/admin-user		=> MySQL root account
	*/mysql/app-pass		=> MySQL root account password

	*/db/app-user			=> MySQL service account
	*/mysql/app-pass		=> MySQL service account password

	*/admin-user			=> Openstack service user
	*/admin-password		=> Openstack service user password

	*/admin-tenant-name	=> Openstack tenant name

	*/keystone-auth-token	=> Openstack authentication token
	*/endpoint-ip			=> Openstack Keystone IP

That’s all you need. Except possibly with, possibly a -plow, ask if to create
the (service) user. IMO, that question isn’t necessary though. Just document
“somewhere” that if someone specifies a specific user and password in those
‘*/admin-{user,password}’ questions, a user WILL be created.

This isn’t such a biggie really. If the user later want to use LDAP, they’re advanced
and knowledgeable enough to realise that they need to (possibly!) delete that user
first.


If you look at "cinder-api.config:pkgos_write_admin_creds()” for example, it
reads those values from debconf, then writes it into the config file.

What I’m suggesting is that either before or after it have done this (in that same
function, written into the config file), it creates a new Openstack service user
[something] like this:

            openstack [—os-* options] user create --domain Default \
		--project-domain Default --enable --password "${pass}” \
		--project “${tenant}" “${user}"
            openstack [—os-* options] role add --project “${tenant}" --user “${user}” admin

Of course this can/should be created as a API function, WITH (!!) the appropriate
checks - does the user already exist, did the add work etc, etc.

If you create that once, in the "openstack-pkg-tools” package, you’re golden. 


PS. From testing, I realised that the user needs also be part of the ‘admin’ role.

> I don't understand why it's not versatile enough. If you look into
> src/preseed-lib (installed in /usr/share/openstack-deploy/pressed-lib if
> you apt install openstack-deploy), there are functions you can use for
> the preseeding. These are quite generic, and proven to work. Have you
> even tried to used these functions?

I did in the very beginning, but I couldn’t make heads or tails of it, so I decided to
just do my pre-seeding in one gulp. For me that was simpler, than spend hours/days
on trying to figure out what those libs actually do.

I also (very vaguely!!) remember seeing “something” I didn’t really like, but for the
life of me I can’t remember.

>> But the postinst still calls db_unregister() to unregister all service user passwords.
> 
> Which is fine, because the .config scripts are filling dbc_password with
> the value from the .conf files of services. So as long as the initial
> setup is done correctly, it shouldn't prompt for this password again.

Two things here: “someone” is then purging it from the dbconfig files and to, “as long as
the initial setup is done correctly” - famous last words! :). That’s the clincher here as
i see it. That’s why _I_ (!!) want control of when/if that happens!

I really don’t like it when install scripts etc try to _anticipate_ what I want and/or need.