Abhijit, yes you right. I make this changeable but leave “flow:1” because of the “legacy”. Therefore everything should work as before.
But still I disagree with this hard-coded practice and I still think this should be changed. Jozef From: Abhijit Kumbhare [mailto:[email protected]] Sent: Friday, November 11, 2016 4:03 AM To: Robert Varga <[email protected]> Cc: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; openflowplugin-dev <[email protected]>; Release ([email protected]) <[email protected]> Subject: Re: [openflowplugin-dev] [release] [WEATHER] - topology id in openflowplugin 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]<mailto:[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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev JozefBacigál Software Engineer Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia +421 908 766 972 / [email protected] reception: +421 2 206 65 114 / www.pantheon.sk [logo]
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
