On February 15, 2015 at 3:16:04 PM, Thomas Goirand (z...@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 

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?). 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to