On 5/23/2017 4:43 PM, Dean Troyer wrote:
In this particular case it may not be necessary, but I think early implementation of composite features in clients is actually the right way to prove the utility of these things going forward. Establish and document the process, implement in a way for users to opt-in, and move into the services as they are proven useful.
A slight disadvantage of this approach is that the resulting incongruence between the client and the API is obfuscating. When an end user can make accurate inferences about the API based on how the client works, that's a form of transparency that can pay dividends.
Also in terms of the "slippery slope" that has been raised, putting small bits of orchestration into the client creates a grey area there as well: how much is too much?
OTOH I don't disagree with you. This approach might be the best of several not-so-great options, but I wish I could think of a better one.
-- Michael Glasgow __________________________________________________________________________ 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
