Jump to: navigation, search

CrossProject:Integration Group:About User Facing Features

Creating user-facing features

This wiki is just a summary of some of the conversations we have had in the past regarding user facing feature so this is more a recommendation than a mandate (at least in this release).

User-facing Features

We understand user-facing features those exposed through Karaf console (if it is a karaf feature) and we expect users to turn on/off regularly.

Essential Functionality

Projects having user-facing features could define at least 1 base or essential-functionality made of other small features that most users (90/10) will consume via java, REST or GUI so it seems logical to define something like:

  • odl-<project>-<essential-functionality> <- Java interfaces only
  • odl-<project>-<essential-functionality>-rest <- Java + REST
  • odl-<project>-<essential-functionality>-ui <- Java + REST +UI

for example:

  • odl-openflowplugin-flow-services <- base openflow service
  • odl-openflowplugin-flow-services-rest <- base openflow service + REST
  • odl-openflowplugin-flow-services-ui <- base openflow service + REST + UI

Other examples in case you do not find a good name for your essential functionality :

  • odl-<project>-plugin (if your project implements a plugin)
  • odl-<project>-service (if your project looks more like a service)
  • odl-<project>-core (if you plan to build other features on top)

Additional Essential Functionalities

A project can provide additional essential-functionalities that are logically separated and users can enable independently, we can treat them the same way:

  • odl-<project>-<essential-functionality-2> <- Java interfaces only
  • odl-<project>-<essential-functionality-2>-rest <- for developers/users
  • odl-<project>-<essential-functionality-2>-ui <- for users

As guideline asking "would a non-developer network operator want to turn this functionality on and off independently of other functionality?" will result in projects making the right choice.

Functionality on Top

A project can also have functionality on top of the essential that users would really like to turn on and off regularly (otherwise we can use more hidden features for that):

  • odl-<project>-<essential-functionality>-<extra-functionality-1>
  • odl-<project>-<essential-functionality>-<extra-functionality-2>

Note that in this case we do not recommend to have -rest -ui in addition but more if a user wants to have both REST and extra functionalities enable:

  • odl-<project>-<essential-functionality>-rest
  • odl-<project>-<essential-functionality>-<extra-functionality-1>
  • odl-<project>-<essential-functionality>-<extra-functionality-2>

for example:

  • odl-openflowplugin-flow-services-rest <- base openflow service + REST
  • odl-openflowplugin-flow-services-tme <- base openflow service + table miss enforcer app
  • odl-openflowplugin-flow-services-nx <- base openflow service + nx extensions

If you have defined your main functionality as odl-<project>-core, perhaps it makes sense to define your extra features as:

  • odl-<project>-<extra-functionality-1>
  • odl-<project>-<extra-functionality-2>

Things to avoid

And these are the things we do not recommend.

odl-<project>-all feature

During helium release we asked projects to define odl-<project>-all karaf feature containing all available features for test purposes, in particular to facilitate the “all-features"on kind of test we do in the integration group to identify bundle conflicts. The problem with this is: 1) nobody really understands what all means and 2) end-users normally prefer to enable something that is called -all even when this involves a lot of overhead and undesired SW. So for feature clarity and user experience we recommend to avoid defining odl-<project>-all feature.