* Srini Seetharaman (srini.seetharaman@...) wrote:

I started out as a beginner user of the ODL platform and put together the
tutorial at sdnhub.org/tutorial/opendaylight a few months ago, mostly by
poking through the code and learning about the workflow of different
modules. We also conducted live tutorials and a hackathon using the ODL
platform. Based on my interactions with many beginner SDN programmers, I
realize the platform is not yet their friend.

Here's my high-level feedback.

Thank you for the feedback, it's very useful (and mirrors some of the
feedback I've heard too).

I wanted to kick off a discussion about how
to make the controller platform easier to use by the average beginner:

- With platforms like ODL that combines OSGi, Eclipse and Maven, there
are too many places where configurations are inspected. Beginners need
clear guides to show the workflow of the compiler and the interpreter.
Madhu explained us the workflow. It will help to have this written in a
user guide of sorts.

What do you consider the audience? This, to me, sounds like a
developer, not a user. I'd expect a user to get a prebuilt controller
and use that. IOW, OSGi, Eclipse and Maven seem out of scope for an
average beginner.

And, put another way, are you interested in helping with this kind of
documentation? It's a big gap right now, ready to be filled with
awesome volunteers ;)

- Why not leave out the tests for the modules from the basic edition?
User != Platform developer. It doesn't make sense for someone building apps
for a platform to run (or even have to load in eclipse) test cases that are
to do with the core module (e.g., topo manager) testing. The latter is more
of the job of the platform developer and not the app developer.

I think this is the right mindset (app dev != platform dev). This should
be possible already if you build your app separately from the controller.
As one extreme, imagine an app written in python using REST API only.
A Java app can build and load into the controller w/out building the
controller.

- It will help to have several primitives that make it easier to perform
frequent operations (like flow setup, match definition, action creation).
For instance, in POX one can define the match from an incoming packet. This
is simple, yet rarely offered in other platforms.

Are you thinking of helper application libraries?

- Coding style is too anal about the trailing space. This is the most
common error that beginners have during compilation.
- It is essential to show how beginners can avoid unnecessary logs that
show up on the screen at run time on the console, and also provide them
pointers to Eclipse usage (debugging, quick compilation etc).

We have a little bit of this in the wiki and can certainly use more/better
doco, but debugging and compilation, again, are more developer oriented.
Having clear command line (I dunno, maybe example for run.sh -debug) and
details on log files, etc. make great sense for users.

- Using eclipse + running consumes quite a bit of memory and computing
resources. I feel most of that is because of loading the full edition from
the git. Maybe loading and using the base-edition won't be so bad.

thanks,
-chris