Open Stack

Hi All,

I'm quite late to the discussion, because I'm on vacation and I missed
the beginning of this thread, but let me share a few thoughts.

On Fri, Sep 28, 2018 at 6:13 PM Jay Pipes <jaypipes at gmail.com> wrote:
> * Does the provider belong to physical network "corpnet" and also
> support creation of virtual NICs of type either "DIRECT" or "NORMAL"?

I'd like to split this question into two, because I think modeling
vnic_types and physnets as traits are different. I'll start with the
simpler: vnic_types.

I may have missed some of the arguments in this very long thread, but
I honestly do not see what is the problem with vnic_type traits. These
are true capabilities of the backend - not binary though. When it
comes to DIRECT and NORMAL the difference is basically if the backend
can do SR-IOV or not.

On the other hand I have my reservations about physnet traits. I have
an item on my todo list to look into Placement aggregates and explore
if those are better representing a physnet. Before committing to using
aggregates for physnets I know I should fully discover the aggregates
API though. And mention one concern which could lead to a usability
problem today: aggregates seem to have no names. I think they should.
The operator is helpless without them.

On Fri, Sep 28, 2018 at 11:51 PM Jay Pipes <jaypipes at gmail.com> wrote:
> That's correct, because you're encoding >1 piece of information into the
> single string (the fact that it's a temperature *and* the value of that
> temperature are the two pieces of information encoded into the single
> string).
>
> Now that there's multiple pieces of information encoded in the string
> the reader of the trait string needs to know how to decode those bits of
> information, which is exactly what we're trying to avoid doing [...].

Technically Placement traits today can be used as a covert
communication channel. And doing that is tempting. One component
encodes information into a trait name. Another reads it (ie. the trait
on the allocated RP) and decodes it. Maybe that trait wasn't
influencing placement at all. This is the metadata use case. (If it is
a use case at all.) I think the most problematic is when we
unknowingly mix placement-influencing info and effectless-metadata
into a single blob (as a trait name). One good way to avoid this is to
fully and actively discourage the use of traits as a covert
communication channel. I can totally support that.

I want to mention that in the work-in-progress implementation of the
minimum guaranteed bandwidth we considered and then conciously avoided
using this covert communication channel. Neutron agents and servers
use their usual communication channels to share resource information
between them. None of them ever decodes a trait name. All we ever ask
of them after allocation is this: Are you responsible for this RP
UUID? (For example see https://review.openstack.org/574783.)

Cheers,
Bence