<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Sep 29, 2018 at 12:02 PM Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sep 28, 2018, at 12:19 PM, Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>> wrote:<br>> I don't think placement should be concerned about temporal aspects<br>
> of traits. If we can't write a web service that can handle setting<br>
> lots of traits every second of every day, we should go home. If<br>
> clients of placement want to set weird traits, more power to them.<br>
> <br>
> However, if clients of placement (such as nova) which are being the<br>
> orchestrator of resource providers manipulated by multiple systems<br>
> (neutron, cinder, ironic, cyborg, etc) wish to set some constraints<br>
> on how and what traits can do and mean, then that is up to them.<br>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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. :-)</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br></div></div>