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

[Thomas Goirand]

On 12/06/2016 06:30 PM, Turbo Fredriksson wrote:
> On 6 Dec 2016, at 17:08, Thomas Goirand <zigo at debian.org> wrote:
> 
>>> Well, you’re asking for that information AND you’re writing that information
>>> into the config file(s).
>>
>> The point of asking for the information is precisely to be able to write
>> it in the configuration file.
> 
> Indeed.
> 
>>> It stands to reason, in my opinion, that that user should also be/have been
>>> created.
>>
>> In which case shall we then create the user? Should we add another
>> prompt to ask if we should create the user or not?
> 
> If the user don’t already exists, yes. A ‘no’ answer here would indicate that
> the user have decided to take responsibility of that themselves (such as
> going through LDAP or something else).
> 
> But a question would be good.
> 
>> 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.

>> Well, I'm not sure how you're doing the preseeding. Why don't you use
>> the preseed lib which is provided by openstack-meta-packages?
> 
> Because it’s not versatile enough. And it doesn’t quite suite my need.

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?

>> dpkg-reconfigure dbconfig-common -plow makes it so it's possible to keep
>> the root password. Though the root password isn't even needed in case
>> you're just using a local server.
> 
> 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.

>> With all of the above, it looks like I can close all of the bugs you
>> filled about db issues. Can you confirm?
> 
> I think that would be premature. The error is there, they happened and it
> will continue to happen. Next time it won’t be an experienced Linux admin
> that deals with this. It’s going to be someone that’ll end up completely stumped
> about the errors..
> 
> But I guess it’s all about how interested you are in making these packages
> “perfect”..

The thing is, rather than spending (wasting?) time on removing the
possibility to use SQLite, I'd prefer working with upstream to fix these
migration scripts. Most of the times, the fixes aren't that hard to
produce. I did fix a few of those for Neutron in the past.

Cheers,

Thomas Goirand (zigo)