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 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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev