Yes - hard coding it is a bad idea - and should be changed. Hence in my opinion (as I mentioned earlier), while not a mandatory action the weather report is now really an advice action - that the hard coding done previously was a bad idea. We may want to give dependent projects a clear set of instructions what they need to do to avoid the hard coding. Feel free to add your suggestions on this.
On Mon, Nov 14, 2016 at 1:01 AM, Jozef Bacigál <[email protected]> wrote: > 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 <openflowplugin-dev@lists. > opendaylight.org>; 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]> 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 > > > > 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 > > [image: logo] > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
