Running ONOS locally

249 views
Skip to first unread message

Thomas Vachuska

unread,
Apr 22, 2015, 3:28:06 PM4/22/15
to onos-dev, Thomas Vachuska
Hi everyone,

With the change of the builtin sample applications and OpenFlow providers to be deployed using the *.oar file mechanism, it is now required to run onos-setup-karaf tool as a form of ‘packaging’ ONOS for  running locally. This will make sure that the latest application bits have been properly pre-installed into the local ONOS karaf instance. Note that if you re making changes to an application, you do not need to stop/start the entire Karaf, you can simply build the app and then use the onos-app reinstall! command to uninstall/install/activate it all in one go.

Full build & full remote ONOS deployment:
onos-build && onos-package && onos-install -f

Full build & full local ONOS karaf deployment:
onos-build && onos-setup-karaf <local-ip> && karaf clean 

Application build & remote redeployment:
cd <app-base-dir> && mvn clean install && onos-app $OCI reinstall! <app-name> target/*.oar

Application build & local redeployment:
cd <app-base-dir> && mvn clean install && onos-app localhost reinstall! <app-name> target/*.oar

Note the level of symmetry between running remotely vs on local Karaf.

While this may seem inconvenient compared to just building and starting karaf, please remember that the *.oar file deployment results in simpler and more robust treatment of applications for the distributed cluster operation, which is the primary deployment use-case. Once we drop-kick Hazelcast, we will be able to drop the local-ip parameter from the onos-setup-karaf shell script and provide onos-karaf shell utility to setup and launch karaf in one step.

I hope that this helps bring some clarify on why this change was made and on how to work in the revised context.

Cheers…

Thomas

Saurav Das

unread,
Apr 23, 2015, 1:11:02 AM4/23/15
to Thomas Vachuska, onos-dev
For local onos karaf deployment, 'obs' seems flaky - sometimes it does not pick up the change and I need to do 'mci'. Anyone else seen this?

Thanks
Saurav

--
You received this message because you are subscribed to the Google Groups "ONOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+u...@onosproject.org.
To post to this group, send email to onos...@onosproject.org.
Visit this group at http://groups.google.com/a/onosproject.org/group/onos-dev/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/63F7BB48-A3B5-40E5-9CB6-9F0E4185D8A0%40onlab.us.



--
The will MUST be stronger than the skill -- Ali

Jonathan Hart

unread,
Apr 23, 2015, 1:51:54 AM4/23/15
to Saurav Das, Thomas Vachuska, onos-dev
Yes, I've seen this with the new application framework when changing application code. If an application is comprised of multiple modules, obs will only build modules whose java code has changed, and in some cases a different module needs to be built in order to regenerate the oar file (one module will have the necessary xml in its pom file to build the oar archive). If you can figure out which module this is you can build this one separately after you've compiled the java code, otherwise I don't know if there is a better solution apart from using 'mci' in these cases.

Cheers,
Jono

Reply all
Reply to author
Forward
0 new messages