On 11/10/2016 07:40 PM, Ryan Goulding wrote: > What they should be doing is probably far from what they actually are > doing. Is this expectation actually written anywhere? Otherwise, how > are consumers supposed to know? Lets not punish people for trying to > use our product.
I agree on the 'not punishing' part. Being an API nerd (and author of the base model), I have to say, that the network topology model is very explicit about saying that the name of the topology is a completely opaque identifier, which has no meaning whatsoever. The actual semantics of the topology is advertized by its types. MD-SAL is explicitly advertised as being a microservice architecture, which (in my book) means that it is a composition of services which consume some input and produce some output. From this perspective, anyone relying on 'flow:1' is violating both of the above by 1) assuming semantics from name and 2) by hard-coding its input (or output) to a particular instance. It also means that piece of code is not reusable (i.e. I cannot instantiate multiple isolated instances within the same instance of MD-SAL). No, these are not documented as design and architecture guidelines, simply because no one has created a comprehensive architecture and design manual. On a project of comparable complexity, this took 6 months of full-time engagement for a team of 5 architect-level people to complete. An interesting question is how do we specify public contract here, as I do not believe there is an API-level promise saying 'the set of directly-connected switches who have connected to IP 1.2.3.4 under this topology instance' -- and all consumers are doing is coding against behavior. I am not aware of any technical reason why it should not be possible to instantiate two instances of OFP, one tied to flow:1 and other to flow:2 (assuming they bind to specific IPs) -- except all the hard-coded users will simply refuse to work with the second one.This is perfectly possible to do with BGP. Now, to take this even further, network topology identifier is a cluster-global namespace, which we have absolutely no governance for and it is a free-for-all. This is true for most of namespaces we use (YANG model namespaces, Java package names, etc.). We usually carve these out by saying the prefix should be org.opendaylight.<projectname> and the rest of this is under project governance -- but even that will not work here. So I really see only two options here: 1) we ignore this issue for a few more years and deal with it once nobody can actually tell what the namespace use is, or 2) we agree on namespace allocation rules, document them and start walking the painful road towards consistency. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
