Improvements for init.d, upstart, and systemd-based systems

1. Change ownership of /onos/apps

onos-service needs write access to onos/apps/foo in order to activate
an app. This also means that ONOS itself could also activate/deactivate,
modify, or reinstall apps, which seems a bit dodgy but is probably
intended.

2. Fix sudo command line

The -b option was in the wrong place, breaking sudo on systems where
we use sudo to start onos (e.g. older debian or centos.)

3. Redirect stderr of 'type daemon' command

We want to detect whether the 'daemon' function/script is available
in init.d enviroments that support it, and we do so using the type
command. Previously we didn't redirect stderr, so this resulted
in a confusing error message being sent to stderr of whoever is
invoking the script.

4. onos.conf has changed to be more consistent with onos.initd

Previously onos.conf ignored $ONOS_GROUP and had a slightly different
structure.

5. onos.service has been added for systemd-based systems

This initial version of onos.service calls /etc/init.d/onos to start
and stop ONOS. In the future we may be able to call onos-service
directly, but we will need to make sure that permissions are set up
correctly so that onos-service can activate apps and so that ONOS
itself can write its log files.

6. A README has been added

7. Update the onos-install and onos-uninstall scripts

Related Jira issue: ONOS-5550

Change-Id: Ie72775f1d0a4082af9c5ea9b13999c427c15ffe0
6 files changed
tree: 761ebd344fb443a22acdb71d1da6c5db6e889fa4
  1. .buckconfig
  2. .dockerignore
  3. .gitignore
  4. .gitreview
  5. BUCK
  6. Dockerfile
  7. LICENSE.txt
  8. README.md
  9. apps/
  10. buck-tools/
  11. bucklets/
  12. cli/
  13. core/
  14. docs/
  15. drivers/
  16. features/
  17. incubator/
  18. lib/
  19. modules.defs
  20. onos.defs
  21. pom.xml
  22. protocols/
  23. providers/
  24. tools/
  25. utils/
  26. web/
README.md

ONOS : Open Network Operating System

What is ONOS?

ONOS is a new SDN network operating system designed for high availability, performance, scale-out.

Top-Level Features

  • High availability through clustering and distributed state management.
  • Scalability through clustering and sharding of network device control.
  • Performance that is good for a first release, and which has an architecture that will continue to support improvements.
  • Northbound abstractions for a global network view, network graph, and application intents.
  • Pluggable southbound for support of OpenFlow and new or legacy protocols.
  • Graphical user interface to view multi-layer topologies and inspect elements of the topology.
  • REST API for access to Northbound abstractions as well as CLI commands.
  • CLI for debugging.
  • Support for both proactive and reactive flow setup.
  • SDN-IP application to support interworking with traditional IP networks controlled by distributed routing protocols such as BGP.
  • IP-Optical use case demonstration.

Checkout our website and our tools