Folks, Perhaps this discussion is going a bit more detailed than the issue itself. Jozef's change was to let the topology ID be a config option with the default of "openflow" instead of "flow" - which necessitated a weather report as applications would have needed to change from the hardcoded value of "flow:1" to "openflow:1". In the OpenFlow plugin meeting it was decided that the default option remain as "flow" - but can be changed via a config option. This means apps do not need to change - so the weather report becomes more of an advice than mandatory action: you can continue to use the current value "flow" but it would be good to not use a hard code value.
I think that is all there is to this. Jozef feel free to correct me. Thanks, Abhijit On Thu, Nov 10, 2016 at 11:38 AM, Robert Varga <[email protected]> wrote: > 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 > > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
