CCSDK team, The bridge is open now for our weekly CCSDK call: https://zoom.us/j/311272079
Dan Dan Timoney Principal Technical Staff Member AT&T Email : [email protected]<mailto:[email protected]> Office : +1 (732) 420-3226 Mobile : +1 (201) 960-1211 200 S Laurel Ave, Rm E2-2A03 Middletown, NJ 08873 From: "TIMONEY, DAN" <[email protected]> Date: Monday, July 15, 2019 at 9:25 AM To: Samuel Kontriš <[email protected]>, onap-discuss <[email protected]> Cc: Štefan Kobza <[email protected]>, Miroslav Mikluš <[email protected]> Subject: Re: #ccsdk Proposal to remove OSGi dependencies from the CCSDK project Samuel, Thank you very much for the contribution! One of the problems that we want to address in CCSDK as a priority is our rather tight coupling with a specific OpenDaylight release. Downstreams that need to use CCSDK with a different OpenDaylight release (not just major release – even a different SR) are forced to do a local compile of CCSDK against the appropriate ODL release mostly due to dependencies in the OSGi feature.xml files. We’ve discussed this on a number of our recent weekly calls , and I think lighty.io could be extremely helpful in this regard. I’ll be sure to reserve time on our CCSDK weekly call this Friday to discuss this further, but this looks very, very promising. Thanks! Dan Dan Timoney Principal Technical Staff Member AT&T Email : [email protected]<mailto:[email protected]> Office : +1 (732) 420-3226 Mobile : +1 (201) 960-1211 200 S Laurel Ave, Rm E2-2A03 Middletown, NJ 08873 From: Samuel Kontriš <[email protected]> Date: Monday, July 15, 2019 at 9:15 AM To: onap-discuss <[email protected]> Cc: "TIMONEY, DAN" <[email protected]>, Štefan Kobza <[email protected]>, Miroslav Mikluš <[email protected]> Subject: #ccsdk Proposal to remove OSGi dependencies from the CCSDK project Hello, I'm forwarding you more information about the migration of ODL based projects to a more lightweight framework - about removing the OSGi dependencies. Two weeks ago I sent this email to the SDNC mailing-list and now I'm reaching to the wider audience, because we would like to hear your opinions on this. Original email: I would like to propose a way how to remove dependencies on the OSGi Framework and Karaf from the CCSDK project while still maintaining same ODL services like Restconf. It is done by integrating the CCSDK with the lighty.io (https://github.com/PantheonTechnologies/lighty-core<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PantheonTechnologies_lighty-2Dcore&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=4EP5yEWIXWHK6tYzli3SD0uoR_-sq2-MqyZ0i_i9L9U&e=>). We would like to see your feedback about these changes. In our opinion the result is much smaller, more nimble package, which is also easier to grasp by developers and easier to develop with and debug as opposed to with the Karaf version. We would like to present the idea, concept, and proposal on your regular weekly meeting next week. More info regarding the first implementation draft below. Links to gerrit changes: core - https://gerrit.onap.org/r/c/ccsdk/sli/core/+/84048<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_ccsdk_sli_core_-2B_84048&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=6-H8j-RIHt7rJ6gdVA4WjWuTHo32c1aer9oVtiFsSNk&e=> adaptors - https://gerrit.onap.org/r/c/ccsdk/sli/adaptors/+/84049<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_ccsdk_sli_adaptors_-2B_84049&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=ERR63CwhCizzOh5BJOzmhfNvq6wb7nNEiCRGux4ZxeE&e=> northbound - https://gerrit.onap.org/r/c/ccsdk/sli/northbound/+/84090<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_ccsdk_sli_northbound_-2B_84090&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=K-pZoj-_XjJQUbbXLBUqT-etPUjXvsk-cS1Zv5-a4YY&e=> plugins - https://gerrit.onap.org/r/c/ccsdk/sli/plugins/+/84202<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_ccsdk_sli_plugins_-2B_84202&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=7Mb2L1iwia_ANNqSzF1M8D7A3vRE2kXnp6SoUVGFnJg&e=> distribution - https://gerrit.onap.org/r/c/ccsdk/distribution/+/84050<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_ccsdk_distribution_-2B_84050&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=FPBp33r99Y56vDAoaZIZQscskXqYKq_HvLByJNNIraM&e=> lighty.io is basically a toolkit that utilizes main OpenDaylight components, which are available as a set of libraries. It removes the dependency on the OSGi framework Apache Karaf together with the Apache Aries Blueprint dependency injection from the OpenDaylight. Instead of these frameworks the lighty.io uses just plain java - for example good old main method for running the application (.jar file) or plain java constructors to inject necessary instances. In fact, the resulting app is easier to integrate with any modern and concurrent Java frameworks of your choice (Spring e.g.). Biggest benefit for the developers is in my opinion much faster and easier development and debugging since they do not have to deal with issues coming from the OSGi frameworks and most of the work is done in java (not the xml configuration files). In addition, building the project and starting/stopping the application is faster and with smaller footprint and the startup is deterministic. Another great thing is that lighty.io is open-source so you can see exactly how it works (together with a few examples in GitHub repository). Official lighty.io web-page - https://lighty.io<https://urldefense.proofpoint.com/v2/url?u=https-3A__lighty.io_&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=X9WpXWdLc5cPG8xSGuwAr13miGJQoO_hNTYx7apJB1o&e=> GitHub repository - https://github.com/PantheonTechnologies/lighty-core<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PantheonTechnologies_lighty-2Dcore&d=DwMFBA&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=ivupdN4E7Vs0QupCgpAdybZgN4khWcuSdHkbaJqE99E&s=4EP5yEWIXWHK6tYzli3SD0uoR_-sq2-MqyZ0i_i9L9U&e=> I have created so called lighty.io modules (implementations of the LightyModule interface) for parts of the CCSDK project that were exposing services using blueprint. These services are started in the lighty.io modules and can be accessed via get methods of the respective module (instead of Blueprint DI). Every repository has one "aggregator" lighty.io module that groups all other modules from that repository. This allows to start/stop all modules from one repository at once just with a few lines of code. Repository distribution contains artifact that creates distribution of the CCSDK lighty.io application packaged as a zip. It contains CCSDK lighty.io application jar file and necessary libraries. This zip distribution is then used in the docker image and the docker-compose file. Those are very similar to the original ones. For example in the docker-compose file is changed only the docker image of the CCSDK. For more information about this see the README.md file located in the lighty/docs directory in the distribution repository. If you want to see it in action try the example described in the mentioned README.md file. During the integration I encountered some problems. Mostly with hard dependencies on the OSGi libraries, which cannot be used together with the lighty.io (since we are getting rid of them). Because of this I had to create copies of some classes and remove these dependencies from them. Some of them can be fixed in the original code easily and some of them are harder. So far I did not touch the original code. Most of the code duplicity (copied classes) can be fixed by creating interfaces for some classes that have the OGSi dependencies (if you want I can elaborate this in the next email). Another problem was for example cyclic dependency between the core repository and the adaptors repository - one class from the core repository needs an instance from the adaptors repository but the adaptors repository is dependent on the instances from the core repository. Please, if you have any questions or feedback just reply to my email. We would like to get feedback from the community. Regards Samuel -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18216): https://lists.onap.org/g/onap-discuss/message/18216 Mute This Topic: https://lists.onap.org/mt/32478122/21656 Mute #ccsdk: https://lists.onap.org/mk?hashtag=ccsdk&subid=2740164 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
