[openstack-dev] [placement] The "intended purpose" of traits
Ed Leafe
ed at leafe.com
Sat Sep 29 16:01:35 UTC 2018
On Sep 28, 2018, at 12:19 PM, Chris Dent <cdent+os at anticdent.org> wrote:
>
> I don't think placement should be concerned about temporal aspects
> of traits. If we can't write a web service that can handle setting
> lots of traits every second of every day, we should go home. If
> clients of placement want to set weird traits, more power to them.
>
> However, if clients of placement (such as nova) which are being the
> orchestrator of resource providers manipulated by multiple systems
> (neutron, cinder, ironic, cyborg, etc) wish to set some constraints
> on how and what traits can do and mean, then that is up to them.
This.
It is up to the clients to determine how to use Placement. But it is up to Placement to give guidance as to how to best use it. If a client wants to hack trait names, then they certainly can, and it might work out just fine.
> On Sep 28, 2018, at 8:25 AM, Eric Fried <openstack at fried.cc> wrote:
>
> Bubble wrap was originally intended as a textured wallpaper and a
> greenhouse insulator. Can we accept the fact that traits have (many,
> many) uses beyond marking capabilities, and quit with the arbitrary
> restrictions?
The crux here is what one considers "arbitrary". If we as a project state "sure, go ahead and use this however you like", we are going to be complicit in the technical debt they accumulate, as Jay has referenced with regards to Nova's ComputeCapabilities filter.
We want consumers of Placement to write good, solid code that doesn't encourage technical debt accumulation. We have no way to prevent bad decisions by others, but we should never document that such usages are fine.
-- Ed Leafe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180929/5d45cb95/attachment.sig>
More information about the OpenStack-dev
mailing list