Open Stack

I proposed a patch to remove the deprecation [0].

[0] https://review.openstack.org/492694

On 06/28/2017 09:33 PM, Lance Bragstad wrote:
> 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.
>
> 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).
>
> I appreciate the feedback!
>
>
> On 06/28/2017 04:22 PM, Steve Martinelli wrote:
>> ++ to what colleen said. I've always preferred using the file-backed
>> approach.
>>
>> 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.
>>
>> On Wed, Jun 28, 2017 at 4:53 PM, Colleen Murphy <colleen at gazlene.net
>> <mailto:colleen at gazlene.net>> wrote:
>>
>>>         On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad
>>>         <lbragstad at gmail.com <mailto:lbragstad at gmail.com>> wrote:
>>>
>>>             Hi all,
>>>
>>>             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.
>>>
>>>             Of the operators using the domain config API in
>>>             keystone, how many are backing their configurations with
>>>             actual configuration files versus the API?
>>>
>>>
>>>             [0]
>>>             http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167
>>>             <http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167>
>>>             [1]
>>>             https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>>             <https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3>
>>>
>>      I am not clear on why we need to deprecate and remove
>>     file-backed domain configuration. The way I see it:
>>
>>     * 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
>>     * It's convenient for deployment tools to just lay down config files
>>     * It's not that much extra effort for the keystone team to
>>     maintain (is it?)
>>
>>     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.
>>
>>     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.
>>
>>     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.
>>
>>     Colleen
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170810/4ceaabbe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170810/4ceaabbe/attachment.sig>