<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I proposed a patch to remove the deprecation [0].<br>
<br>
[0] <a class="moz-txt-link-freetext" href="https://review.openstack.org/492694">https://review.openstack.org/492694</a><br>
<br>
<div class="moz-cite-prefix">On 06/28/2017 09:33 PM, Lance Bragstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b81bfed1-c718-81d6-1e08-652cd6736b08@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Cool - I'm glad this is generating discussion. I personally don't
see a whole lot of maintenance costs with `keystone-manage
domain_config_upload`. I was parsing deprecation warnings in the
code base and noticed it was staged for removal, but it wasn't
clear when or why. It also wasn't very clear if there was a desire
to move away from the file-based approach all together, but it was
something that came up in the meeting.<br>
<br>
Based on the responses and the reasons listed, I think removing
the deprecation to avoid confusion on where we stand would be a
good thing (especially since it's low maintenance).<br>
<br>
I appreciate the feedback!<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/28/2017 04:22 PM, Steve
Martinelli wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHc_MXGHQrPkswvH63uLfvAZoduAJaMx6HVn5FMzqDuhokgqPQ@mail.gmail.com">
<div dir="ltr">++ to what colleen said. I've always preferred
using the file-backed approach.
<div><br>
</div>
<div>I think we deprecated it for completeness and to only
have a single tool for configuring LDAP-backed domains. If
it's tested well enough and not much effort to support then
we should keep it around as an alternative method for
configuring LDAP-backed domains.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 28, 2017 at 4:53 PM,
Colleen Murphy <span dir="ltr"><<a
href="mailto:colleen@gazlene.net" target="_blank"
moz-do-not-send="true">colleen@gazlene.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">
<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="m_-4851745276207167921gmail-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"
moz-do-not-send="true">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="m_-4851745276207167921gmail-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" moz-do-not-send="true">http://eavesdrop.openstack.org<wbr>/meetings/keystone/2017/keysto<wbr>ne.2017-06-27-18.00.log.html#l<wbr>-167</a>
[1] <span class="m_-4851745276207167921gmail-m_-677896282506208392m_-4178995976040277127cmdline"><a class="m_-4851745276207167921gmail-m_-677896282506208392m_-4178995976040277127moz-txt-link-freetext" href="https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3" target="_blank" moz-do-not-send="true">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>
</span>
<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/<wbr>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>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Colleen</div>
</font></span></div>
</div>
</div>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank" moz-do-not-send="true">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" moz-do-not-send="true">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>