<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-h5"><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 28, 2017 at 2:00 AM, Lance
          Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF">
              <p>Hi all,</p>
              <p>Keystone has deprecated the domain configuration upload
                capability provided through `keystone-manage`. We
                discussed it's removal in today's meeting [0] and wanted
                to send a quick note to the operator list. The ability
                to upload a domain config into keystone was done as a
                stop-gap until the API was marked as stable [1]. It
                seems as though file-based domain configuration was only
                a band-aid until full support was done. <br>
              </p>
              <p>Of the operators using the domain config API in
                keystone, how many are backing their configurations with
                actual configuration files versus the API?</p>
              <p><br>
              </p>
              <p style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">[0] <a class="gmail-m_-677896282506208392m_-4178995976040277127moz-txt-link-freetext" href="http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167" target="_blank">http://eavesdrop.openstack.org<wbr>/meetings/keystone/2017/keysto<wbr>ne.2017-06-27-18.00.log.html#<wbr>l-167</a>
[1] <span class="gmail-m_-677896282506208392m_-4178995976040277127cmdline"><a class="gmail-m_-677896282506208392m_-4178995976040277127moz-txt-link-freetext" href="https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3" target="_blank">https://github.com/openstack/k<wbr>eystone/commit/a5c5f5bce812fad<wbr>3c6c88a23203bd6c00451e7b3</a></span></p>
            </div>
            <span style="color:rgb(34,34,34)"></span></blockquote></div></div></blockquote></div></div></div></blockquote><div> I am not clear on why we need to deprecate and remove file-backed domain configuration. The way I see it:</div><div><br></div><div><div>* It's reflectve with the primary configuration, so I can copy over the chunks I need from keystone.conf into /etc/keystone/domains/keystone.domain.conf without thinking too hard about it</div><div>* It's convenient for deployment tools to just lay down config files</div></div><div>* It's not that much extra effort for the keystone team to maintain (is it?)</div><div><br></div><div>The use case for file-backed domain configs is for smaller clouds with just one or two LDAP-backed domains. There's not a real need for users to change domain configs so the file-backed config is plenty fine. I don't see a lot of gain from removing that functionality.</div><div><br></div><div>I don't particularly care about the keystone-manage tool, if that goes away it would still be relatively easy to write a python script to parse and upload configs if a user does eventually decide to transition.</div><div><br></div><div>As a side note, SUSE happens to be using file-backed domain configs in our product. It would not be a big deal to rewrite that bit to use the API, but I think it's just as easy to let us keep using it.</div><div><br></div><div>Colleen</div></div></div></div>