Open Stack

On 02/15/2015 02:56 AM, Clint Byrum wrote:
> Excerpts from Thomas Goirand's message of 2015-02-14 16:48:01 -0800:
>> Hi,
>>
>> I've seen messages in the logs telling that we should move to the
>> identity_uri.
>>
>> I don't really like the identity_uri which contains all of the
>> information in a single directive, which means that a script that would
>> edit it would need a lot more parsing work than simply a key/value pair
>> logic. This is error prone. The fragments don't have this issue.
>>
>> So, could we decide to:
>> 1/ Not remove the auth fragments
>> 2/ Remove the deprecation warnings
>>
> 
> Automation has tended away from parsing and editing files in place for
> a long time now. Typically you'd have a source of truth with all the
> values, and a tool to turn that into a URL during file generation. This
> isn't error prone in my experience.

That's truth for Chef / Puppet based deployments. But for what I do with
debconf, I do insist on editing only what's needed to a pre-existing
configuration file. And yes, it should be up to the packages to maintain
configuration files, not stuff like puppet / chef. If everyone is doing
what you wrote above, it's precisely because, up to now, packages were
not doing a good enough (configuration maintenance) work, which I intend
to fix in the near future.

As of right now, I'm able to deploy a full all-in-one server using only
debconf to configure the packages. This works pretty well! And I'm now
using that to run my tempest CI (with which I am having very decent
results).

My next step is to do do multi-nodes setups using preseed as well. When
done, I'm also confident that using a preseed debian installer will also
work, and probably a custom Debian CD will also be possible (and then,
in the long run, make it a Debian pure blend, and integrate myself in
Tasksel).

I'm really hoping that, on the long run, hard-wiring configuration
management in packages directly, will be better than puppet hacks.

> I don't really know why the single URL is preferred, but I don't think
> the argument that "it makes parsing and editting the config file with
> external tools" is strong enough to roll this deprecation back.

On 02/15/2015 06:02 AM, Morgan Fainberg wrote:
> Thomas, Can you be more specific about what use-case you’re running
> into that makes the fragments better (instead of a URI form such as
> the SQL connection string would be)?

Let me describe what's done currently in my Debian packages.

What I do in my debian package, is that I use my shell script function
"pkgos_inifile" (available inside the openstack-pkg-tools package) which
has get / set as 2nd argument, then the config file, the section and
finally the directive, plus the new value in case of set. This function
gets included in the .config and .postinst scripts of all core projects
of openstack.

Then on top of that utility function, for the configuration part of the
package, I wrote a pkgos_read_admin_creds() function, which reads the
existing configuration (let's say in /etc/cinder/cinder.conf), and
populate the debconf cache with the values sets there. Then questions
are prompted to the user.

Then in the .postinst script, values are written to the cinder.conf,
thanks to the call: "pkgos_write_admin_creds ${CINDER_CONF}
keystone_authtoken cinder".

All of this currently uses the auth_token fragments, rather than the
URI. While I could write code to parse the URI, the only bit which needs
to be edited is the auth_host directive, so I find it silly to have to
parse (when reading) to extract the host value only, and parse again
(when writing) to only modify the host field. Also, the URI doesn't even
contain the admin_user, admin_tenant_name and admin_password (correct me
if I'm wrong here), so it's not even self contained like a DSN would.

Last, removing the support of the auth fragments would mean that I would
have to write some configuration maintenance code that would go in both
the config and postinst scripts, which is always annoying and dangerous
to write.

So, finally, I'd prefer to have the auth fragments to stay. But if they
have to go, please let me know *EARLY* when they really do, as it will
impact me a lot.

I hope this gives more insights,
Cheers,

Thomas Goirand (zigo)