Open Stack

> So from a code perspective _placement_ is completely agnostic to
> whether a trait is "PCI_ADDRESS_01_AB_23_CD", "STORAGE_DISK_SSD", or
> "JAY_LIKES_CRUNCHIE_BARS".

Right, but words have meanings, and everyone is better off if that
meaning is common amongst everyone doing the talking. So if placement
understands traits as "a unitary piece of information that is either
true or false" (ex: HAS_SSD), but nova understands it as "multiple
pieces of information, all of which are either true or false" (ex:
HAS_PCI_DE_AD_BE_EF), then that's asking for trouble. Can it work out?
Probably, but it'll be more by accident that by design, sort of like
French and Spanish sharing certain words, but then having some similar
sounding words mean something completely different.

> However, things which are using traits (e.g., nova, ironic) need to
> make their own decisions about how the value of traits are
> interpreted.

Well... if placement is saying "here's the primitives I can work with
and can expose to my users", but nova is saying "well, we like this
one primitive, but what we really need is this other primitive, and
you don't have it, but we can totally hack this first primitive that
you do have to do what we want"... That's ugly. From what I
understand, Nova needs *resources* (not resources providers) to have
*quantities* of things, and this is not something that placement can
currently work with, which is why we're having this flamewar ;)

> I don't have a strong position on that except to say
> that _if_ we end up in a position of there being lots of traits
> willy nilly, people who have chosen to do that need to know that the
> contract presented by traits right now (present or not present, no
> value comprehension) is fixed.
>
> > I *do* see a problem with it, based on my experience in Nova where this kind
> > of thing leads to ugly, unmaintainable, and incomprehensible code as I have
> > pointed to in previous responses.
>
> I think there are many factors that have led to nova being
> incomprehensible and indeed bad representations is one of them, but
> I think reasonable people can disagree on which factors are the most
> important and with sufficient discussion come to some reasonable
> compromises. I personally feel that while the bad representations
> (encoding stuff in strings or json blobs) thing is a big deal,
> another major factor is a predilection to make new apis, new
> abstractions, and new representations rather than working with and
> adhering to the constraints of the existing ones. This leads to a
> lot of code that encodes business logic in itself (e.g., several
> different ways and layers of indirection to think about allocation
> ratios) rather than working within strong and constraining
> contracts.
>
> From my standpoint there isn't much to talk about here from a
> placement code standpoint. We should clearly document the functional
> contract (and stick to it) and we should come up with exemplars
> for how to make the best use of traits.
>
> I think this conversation could allow us to find those examples.
>
> I don't, however, want placement to be a traffic officer for how
> people do things. In the context of the orchestration between nova
> and ironic and how that interaction happens, nova has every right to
> set some guidelines if it needs to.
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
--
Artom Lifshitz
Software Engineer, OpenStack Compute DFG