Back to the deprecation for a moment... My plan was to tell folks to use Traits to influence placement decisions, rather than capabilities.
We probably can't remove the feature till we have deploy templates, but it seems wrong not to warn our users to avoid using capabilities, when 80% of the use cases can be moved to traits today, and give you better performance, etc. Thoughts? On Mon, 1 Oct 2018 at 22:42, Eric Fried <openst...@fried.cc> wrote: > I do want to zoom out a bit and point out that we're talking about > implementing a new framework of substantial size and impact when the > original proposal - using the trait for both - would just work out of > the box today with no changes in either API. Is it really worth it? Yeah, I think the simpler solution deals with a lot of the cases right now. Personally, I see using traits as about hiding complexity from the end user (not the operator). End users are requesting a host with a given capability (via flavor, image or otherwise), and they don't really care if the operator has statically configured it, or Ironic dynamically configures it. Operator still statically configures what deploy templates are possible on what nodes (last time I read the spec). For the common cases, I see us adding standard traits. They would also be useful to pick between nodes that are statically configured one way or the other. (Although MarkG keeps telling me (in a British way) that is probably rubbish, and he might be right...) I am +1 Jay's idea for the more complicated cases (a bit like what jroll was saying). For me, the user (gets bad interop and) has no visibility into what the crazy custom trait means (i.e. the LAYOUT_Y in efried's example). A validated blob in Glare doesn't seem terrible for that special case. But generally that seems like quite a different use case, and its tempting to focus on something well typed that is disk configuration specific. Although, it is tempting not to block the simpler solution, while we work out how people use this for real. Thanks, John __________________________________________________________________________ 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
