Open Stack

On February 15, 2015 at 3:16:04 PM, Thomas Goirand (zigo at debian.org) wrote:
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). 

So, let me just say that while I do not have a timeline on the removal of auth fragments, since it is deprecated assume that this should no longer be used if there is an alternative (which there is). I am willing to continue with the discussion on reversing course, but consider the deprecation notice the “far in advance” warning that they are going away (isn’t that what deprecation is?). 

—Morgan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150215/7c693a44/attachment.html>