Open Stack

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/20170628/6c23a265/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170628/6c23a265/attachment.sig>