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 <coll...@gazlene.net >> <mailto:coll...@gazlene.net>> wrote: >> >>> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad >>> <lbrags...@gmail.com <mailto:lbrags...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
