Open Stack

On Sat, Sep 29, 2018 at 12:02 PM Ed Leafe <ed at leafe.com> wrote:

> 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.
> 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.
>

It is only up to the clients to determine how to use Placement, if the
Placement team specifies this as an intent. It's very important for users
of the system to be in alignment with the providers of the system to avoid
surprise and complications. Yes, users can hang themselves with enough rope
- but this is a reckless position to hold. Let us say that Placement and
Nova evolve traits according to a roadmap that ends up causing the users to
get stuck on an old release because they have no migration path because
they used the API in a way that was never intended, and never acknowledged.

I'm reading along with interest, and the main issue I see here is what Jay
referred to, which is that there is a process to get well formulated ideas
agreed upon and incorporated, and it does seem like this is a threat to do
something that works without following this process, not because it is
smart, but because it is possible.

I have a similar dilemma on a different system which has to do with the
proper use of labels in a system like Jira. Jira issue labels are intended
to be more flexible and defined according to user requirements to meet
needs not envisioned by the designers of the issue field schemes. They work
well well for certain ad-hoc uses, but they had side effects and
limitations which make them very poor for many uses. A key one is related
to this discussion, in that you can't easily evaluate only part of a label,
so if you did non-advisable things like to use labels instead of priority,
and you had multiple label values to indicate each priority, you end up
with rather silly evaluations like "label in ('priority_high',
'priority_medium', 'priority_low')". This gets more complex over time and
ends up being a huge burden for whoever inherits such a system. Yes, it was
to solve an original problem - but the smart person would have addressed
this with the issue field scheme and would have prevented this technical
debt burden from existing in the first place.

I think you should push Jay to propose what he thinks a good solution would
be, and start discussing these options. I'm interested in reading more
about these options.

I really don't like the idea of embedding data bits into a single string
that effectively includes both a "key" and a "value" as my own experience
suggests this is a very bad idea.

Myself, I think "traits" are not necessarily boolean. I see "brown hair" as
a human trait. However, if they are not boolean than this invites the need
to evaluate with comparison operators, and this would morph into a much
more complex system.

The idea of passing configuration data in might solve a subset of the cases
- and it might solve your subset. But, I do think there is a more general
solution possible if the requirements warranted the development.

I also want to add that I think traits should not be dynamic things that
change from second to second. The idea of passing temperature information
via traits sounded somewhat ridiculous to me. I think that might have been
the intent of the original poster to present a ridiculous example and hope
people understood. I hope nobody was taking it seriously. :-)

-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180929/9a46e584/attachment.html>