Hi Michael,

On Wed, Apr 4, 2018 at 6:41 AM, Michael Vorburger <[email protected]>
wrote:

> On Tue, Apr 3, 2018 at 10:31 PM, Abhijit Kumbhare <[email protected]>
> wrote:
>
>> >> Not sure all of these are wonderful ideas so feel free to critique.
>>
>> Thanks Ranga - these are wonderful ideas. The issue usually has been
>> developers with cycles to spend on updating these wikis. It will be great
>> if you can perhaps join the documentation call. While historically it has
>> been not well attended - I believe Jamo, Luis, Daniel, etc. were planning
>> to start attending this week onwards.
>>
>> https://wiki.opendaylight.org/view/Documentation/Meetings
>> <https://wiki.opendaylight.org/view/Documentation/Meetings>
>> Just a note - it seems the docs call has changed from Wednesdays to
>> Tuesdays - so it seems to be over for this week. You should be able to
>> attend next week though.
>>
>> Also if you notice any issues on the wiki (like references being release
>> specific as you mentioned) - please feel free to update the wiki.
>>
>> On Tue, Apr 3, 2018 at 12:43 PM, M. Ranganathan <[email protected]> wrote:
>>
>>>
>>>
>>> On Tue, Apr 3, 2018 at 2:51 PM, Abhijit Kumbhare <[email protected]>
>>> wrote:
>>>
>>>> +1 to what Michael said.
>>>>
>>>> On Tue, Apr 3, 2018 at 11:30 AM, Michael Vorburger <
>>>> [email protected]> wrote:
>>>>
>>>>> +Cc documentation project mailing list:
>>>>>
>>>>> Hello Ranga,
>>>>>
>>>>> great meeting you face to face last week at ONS. Thank you for jumping
>>>>> in on a mailing list re. this. Some thoughts:
>>>>>
>>>>> On Tue, Apr 3, 2018 at 6:19 PM, M. Ranganathan <[email protected]>
>>>>> wrote:
>>>>>
>>>>> When I first started hacking with open daylight, I was confused by the
>>>>>> number of releases and the fact that the "getting started" wiki pages did
>>>>>> not match the latest release. I had a hard time finding a complete,
>>>>>> documented "hello world" on wiki (perhaps I was looking in the wrong 
>>>>>> place).
>>>>>>
>>>>>
>>>>> you probably did not look in the wrong place, but you are rightfully
>>>>> IMHO pointing out that we as a community can do better in this regard.
>>>>>
>>>>> May I suggest the following:
>>>>>>
>>>>>> A "release" is not a release until all the web pages and user level
>>>>>> documentation is up to date with the release code. By this I mean the 
>>>>>> wiki
>>>>>> docs and "how to" guides. Otherwise, it really confuses the user 
>>>>>> community.
>>>>>>
>>>>>
>>>>> the best way to help is to jump and help on some end! For example,
>>>>> feel free to simply start editing the https://wiki.opendaylight.org !
>>>>>
>>>>> also you can contribute to http://docs.opendaylight.org via
>>>>> https://wiki.opendaylight.org/view/Documentation; I'm sure they would
>>>>> love to see you.
>>>>>
>>>>>
>>>>>> Perhaps it would be good to expend some energy there.  Is there a
>>>>>> "samples project" where users like me could contribute?
>>>>>>
>>>>>
>>>>> specifically re. code, there are at least 2 things you may be
>>>>> interested in:
>>>>>
>>>>> https://wiki.opendaylight.org/view/Archetypes to get the Maven
>>>>> archetype starter into a new project and properly automatically self
>>>>> tested. That is work in progress which just FYI should actually
>>>>> proceed later this and next week; I spoke with Anil from LF about next
>>>>> steps re. this F2F at ONS last week. Your contributions to this project to
>>>>> extend the archetype will be most welcome.
>>>>>
>>>>> https://wiki.opendaylight.org/view/Controller_Core_Functiona
>>>>> lity_Tutorials:Main this has not moved much recently, but I'm sure
>>>>> your contributions would be welcome here as well.
>>>>>
>>>>> Thanks to the contributors for great work.
>>>>>>
>>>>>
>>>>> Looking forward to counting you as part of the contributors! ;-)
>>>>>
>>>>

Thanks. I will start chipping away at the wiki. A little concerned about
misguiding people as a result of my own superficial grasp of the
technologies involved but I trust you guys won't be shy about reeling me in.

Ranga.



>
>>>>> Tx,
>>>>> M.
>>>>> --
>>>>> Michael Vorburger, Red Hat
>>>>> [email protected] | IRC: vorburger @freenode | ~ =
>>>>> http://vorburger.ch
>>>>>
>>>>>
>>>>> Regards,
>>>>>>
>>>>>> Ranga
>>>>>>
>>>>>>
>>>>>> --
>>>>>> M. Ranganathan
>>>>>>
>>>>>
>>> Thanks for the suggestions. The wiki page below :
>>>
>>> https://wiki.opendaylight.org/view/Controller_Core_Functiona
>>> lity_Tutorials:Main
>>>
>>> Is very useful to beginners. Exactly what is needed! Some issues I had
>>> were due to my unfamiliarity with Karaf.  (While I had written a lot of
>>> Java I had never done anything with Karaf.)
>>>
>>> Here are some suggestions (I'd like to hear your opinion on these) :
>>>
>>> 1. A mini tutorial on reactive flow rule pushing - i.e. push a flow rule
>>> when a switch connects.
>>>
>>> 2. Developer hints and tricks. Even simple stuff like packet parsing
>>> routines ( so you don't have to roll your own) would be handy to point to.
>>> They exist but are hard to find.  Even a curated set of stackoverflow how
>>> to links would be a great resource. How do you include a third party jar ?
>>> ( again more of a Karaf question but useful to know).
>>>
>>> 3. A multi-application tutorial would be handy (karaf is all about
>>> micro-services and application composition). Specifically, I had questions
>>> like: What is the threading model when you have multiple MDSAL
>>> listeners? Does each event handler run concurrently? How do event handlers
>>> communicate with each other? In this connection, I'd like to suggest that
>>> we consider a more architecturally consistent way of application
>>> composition whereby applications can declare their table space so different
>>> applications can co-exist but this is a different thread.
>>>
>>> 4. The following is also very useful for beginners:
>>>
>>> https://wiki.opendaylight.org/view/OpenDaylight_Controller:M
>>> D-SAL:MD-SAL_Document_Review:Architecture
>>>
>>> However, I'd like to add a few things to the document above (and remove
>>> some references to specific release versions).
>>>
>>
> as Abhijit said, just go ahead and edit the Wiki - it literally is as easy
> as that to contribute!
>
> And if you are feeling extra generous, then raise Gerrits against the
> documentation project to move some of the content from the Wiki into the
> RST format used in the documentation project; see
> https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=
> tree;f=docs/developer-guide;h=6e5925cf42f1c8064205b0c912f2ea
> 81bb70dfce;hb=refs/heads/master ... (and then replace the content on the
> Wiki with links to http://docs.opendaylight.org !
>
>
>>   In particular, trace a packet coming out of a switch on a flow miss,
>>> being sent to the controller. What are all the interactions (shown as a
>>> sequence diagram). Not sure I could do this diagram myself or I'd volunteer.
>>>
>>> 5. How to write a new southbound plugin ( a simple do-nothing southbound
>>> --I love the architecture of ODL. I think one could do a lot more than
>>> OpenFlow with it ).
>>>
>>> 6. List of background reading material - RFCs, Yang tutorial, Karaf
>>> book, Maven for aspiring students / developers who want to use this
>>> technology.
>>>
>>> I really like the Ryu book. A similar, how to approach would be a huge
>>> hit with the user community (especially with students). A single place
>>> where you could step through the architecture and implementation of an
>>> increasingly complex set of applications would be terrific. Maybe a
>>> wikibook along those lines would be a nice community effort.
>>>
>>
> Perhaps having https://wiki.opendaylight.org and
> http://docs.opendaylight.org (which FYI is built from
> https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=tree) we don't
> need WikiBook ?
>
> Not sure all of these are wonderful ideas so feel free to critique.
>>>
>>
> Ranga, I think all this is great stuff! Now it just takes people to help
> start working on such material - you? ;-)
>
> While reading through your different ideas a thought crossed my mind: How
> about you open JIRA issues in the documentation project for each of these
> "documentations requirements" ? Then the detailed discussion for each point
> can happen in each such JIRA, anyone interested in contributing can
> self-assign such JIRAs to themselves to signal "I'm intending to work on
> this", Gerrits with RST on the documentation project can be raised against
> such JIRAs - just like for code. Do people think this is a good idea?
>
>
>> Best regards
>>>
>>> Ranga
>>>
>>> --
>>> M. Ranganathan
>>>
>>>
>>
>


-- 
M. Ranganathan
_______________________________________________
Discuss mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/discuss

Reply via email to