Re: Telling our users about what is in Helium


Phil Robb
 

1) OK, ARP Handler is gone.
2) I reduced the GBP Renderers box to now only cover half of the OF and OVSDB boxes
3) No better phrase that I know of and that's what we used in the Hydrogen diagram as well, so it's still in.

Attached is the latest and hopefully final version.  Let me know your thoughts ASAP. 

Thanks,

Phil.

On Tue, Sep 23, 2014 at 5:03 PM, Colin Dixon <colin@...> wrote:
A few questions/suggestions:
1.) can we remove the ARP Handler or move it into the l2switch where I think it resides now. That will actually save space.
2.) If anyone has a suggestion for how to make it seem less like the only way to access OpenFlow and OVSDB southbounds is via Group Based Policy, I'd like to hear it.
3.) I had to look up what we mean by "capability abstraction", do we have a better phrase for that?

--Colin



On Tue, Sep 23, 2014 at 5:50 PM, Phil Robb <probb@...> wrote:
Hello again TSC and members of the Helium Release:

Thanks to all for the great feedback on the Helium diagram.  It has all been incorporated into the pretty version of the diagram you see attached.

Please let me know what you think.

Phil.

On Tue, Sep 16, 2014 at 10:39 AM, Phil Robb <probb@...> wrote:
Hello TSC and members of the Helium Release:

Please find attached an architectural diagram describing the components that make up Helium.  This diagram is in the same format as the one we used to describe Hydrogen so users familiar with the former can have a frame of reference.  This diagram is not pretty and please spend no effort in trying to make it so.  Once the technical content is verified, I'll send if off to folks in the LF that are masters at making it look pretty.  For now, I'm just looking for accuracy and completeness.  So please review it with that in mind and provide me any feedback that you have by Friday (9/19).

Given that we are going out with a karaf-based, user-selectable set of features for Helium, the attached diagram is not sufficient in explaining to our users what is available (ie what they can select) and the features/functionality they get from each potential selection.  So I believe we need another diagram, or set of diagrams, and concise, descriptive text for each user visible feature.  What are your thoughts on this?  Are there other/better ways of representing the user-visible features within ODL?  If nothing better is proposed, I'll reach out to each project contact for that short, concise feature description.

Thanks,

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb



--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc





--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

Join TSC@lists.opendaylight.org to automatically receive all group messages.