Usability: Config subsystem - "How do I know what values to use in the Yang / XML to get MD-SAL services?"

A usability was pointed out - when we changed the name of the data broker in the config sub system people were not clear on how to even start figuring out what the correct values are.

It would be great if we can try to answer this question in a quick, distinct way. Here is the e-mail snippet from the controller-dev list.

==========

Does anyone know the answer to this? What do I need to put in my yang files and config files to get the new API? I have no idea how I'd even figure this out.

There's a million yang files and everything has the same name as everything else.

-Rob

On Mon, Jun 30, 2014 at 3:26 PM, Rob Adams <readams@readams.net> wrote:
Also, what is the magic incantation I would need in order to use this? In terms of what I need to put into the config XML file, pom file, etc.
The old one looks like this:

container data-broker {
uses config:service-ref {
refine type

{ mandatory true; config:required-identity mdsal:binding-data-broker; }

}
}

and
<data-broker>
<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
<name>binding-data-broker</name>
</data-broker>

On Mon, Jun 30, 2014 at 3:07 PM, Rob Adams <readams@readams.net> wrote:
Thanks, so it looks like in the new API there is a way to do this. This is much better.

One thing to ask though, based on the design of the new API: are we committing to notifications always and forever more being single threaded? The current API design is not threadsafe if you can get notifications on multiple threads. Given that the design of MD-SAL depends on these update notifications for potentially performance-critical paths, this may not be a good idea.

-Rob