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 <jaypi...@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 <jaypi...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev