<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On February 15, 2015 at 3:16:04 PM, Thomas Goirand (<a href="mailto:zigo@debian.org">zigo@debian.org</a>) wrote:</div> <div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div></div><div>On 02/15/2015 02:56 AM, Clint Byrum wrote:<span class="Apple-converted-space"> </span><br>> Excerpts from Thomas Goirand's message of 2015-02-14 16:48:01 -0800:<span class="Apple-converted-space"> </span><br>>> Hi,<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> I've seen messages in the logs telling that we should move to the<span class="Apple-converted-space"> </span><br>>> identity_uri.<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> I don't really like the identity_uri which contains all of the<span class="Apple-converted-space"> </span><br>>> information in a single directive, which means that a script that would<span class="Apple-converted-space"> </span><br>>> edit it would need a lot more parsing work than simply a key/value pair<span class="Apple-converted-space"> </span><br>>> logic. This is error prone. The fragments don't have this issue.<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> So, could we decide to:<span class="Apple-converted-space"> </span><br>>> 1/ Not remove the auth fragments<span class="Apple-converted-space"> </span><br>>> 2/ Remove the deprecation warnings<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Automation has tended away from parsing and editing files in place for<span class="Apple-converted-space"> </span><br>> a long time now. Typically you'd have a source of truth with all the<span class="Apple-converted-space"> </span><br>> values, and a tool to turn that into a URL during file generation. This<span class="Apple-converted-space"> </span><br>> isn't error prone in my experience.<span class="Apple-converted-space"> </span><br><br>That's truth for Chef / Puppet based deployments. But for what I do with<span class="Apple-converted-space"> </span><br>debconf, I do insist on editing only what's needed to a pre-existing<span class="Apple-converted-space"> </span><br>configuration file. And yes, it should be up to the packages to maintain<span class="Apple-converted-space"> </span><br>configuration files, not stuff like puppet / chef. If everyone is doing<span class="Apple-converted-space"> </span><br>what you wrote above, it's precisely because, up to now, packages were<span class="Apple-converted-space"> </span><br>not doing a good enough (configuration maintenance) work, which I intend<span class="Apple-converted-space"> </span><br>to fix in the near future.<span class="Apple-converted-space"> </span><br><br>As of right now, I'm able to deploy a full all-in-one server using only<span class="Apple-converted-space"> </span><br>debconf to configure the packages. This works pretty well! And I'm now<span class="Apple-converted-space"> </span><br>using that to run my tempest CI (with which I am having very decent<span class="Apple-converted-space"> </span><br>results).<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><div><br></div><div>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?). </div><div><br></div><div>—Morgan</div><div><br></div></body></html>