Date: Fri, 29 Mar 2024 12:51:53 +0000 (UTC) Message-ID: <298266099.1531.1711716713640@b9607565de67> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1530_1660025512.1711716713640" ------=_Part_1530_1660025512.1711716713640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
lighty
lighty
lighty is designed as a simple, lightweight a= nd easy-to-use set of ODL components.
lighty is NOT a framework. It is a set of reu=
sable libraries and/or components. That is why it can be easily integrated =
with various libraries and frameworks in the vast Java ecosystem. The end-u=
ser has to have a possibility to re-use lighty components as separate libraries, or as a whole pre-assemb=
led stack.
lighty components are ready to be used in mic= ro-service deployments.
The lighty project starts a= nd provides services from core ODL projects (like controller, MD-SAL, YANG Tools) in a way, where they can be used without the depende= ncy on OSGi frameworks like Karaf and Blueprint DI. The main benefi= ts of using lighty to get thes= e services, instead of OSGi, are:
All services/beans from these core ODL projects are created and started in=
a common and simple Java way - by creating instances with constructors. By default, no dependency injection framework is u=
sed. Services created this way are exposed to other projects/modules via si=
mple get methods.
A base building block of applications, based on li= ghty, is called a LightyModule. Lig= htyModule is an interface that provides start/stop methods to this module. Implementations, or extensions= of LightyModule, may expose started services for use in another LightyModu= le if needed.
One LightyModule represents one comprehensive functionality. There can b= e one or more LightyModules per project - if it makes sense from a function= ality perspective.
Dependencies of the implementation of LightyModule are specified in its = Java constructor. This constructor specifies, which services must be starte= d, before this LightyModule.
All LightyModules should be fully configurable.
Runnable applications based on lighty&n= bsp;(so-called LightyApplication), consist of multiple LightyModules= . These modules should be created and started in an order, which is defined= by the dependencies of the LightyModules (by services required in construc= tors of LightyModules). A simple Java main= method, used as a LightyApplication, is sufficient.
LightyApplications can be distributed as .zip= archive, that can be generated by the Maven parent l= ighty-app-parent. This .zip distribution will contain a runnable .jar = file of the application, a configuration and all necessary dependencies (as= .jar files).
Projects creating their LightyModules (and LightyApplication), cannot us= e OSGi libraries in their code (import org.osgi.*) and all of thei= r ODL dependencies (for example MD-SAL, RESTCONF, etc.) must be already int= egrated with lighty.
There are a number of unresolved questions, which need to be addressed b= efore we move into execution and rollout of this project. These are summari= zed in this section.
Current implementation assumes it is downstream of all projects that are= integrated. This lays the onus of ensuring integration and compliance into= this project, with little in the way of validating whether a particular up= stream is compliant with the requirements and can actually be integrated.= p>
Furthermore this means there is an unclear governance around use-case pa= ckaging. We certainly do not want for this project to become an architectur= al hotspot the way controller's 'odl-mdsal-broker' feature is a hotspot for= current Karaf packaging.
Current Lighty approach assumes all services present in odl-mdsal-broker= are required for a particular deployment. This is not actually required --= and is perhaps detrimal to actual use cases -- for example there are use c= ases which do not need Entity Ownership Service, and hence it should be pos= sible to create a use case package without those components. This has a dir= ect tie-in into how services are injected, below.
Current ODL approach is centered around OSGi Service Registry being pres= ent, with some amount of leakage from ODL-simple, where there are some JSR2= 50-annotated classes and generated BluePrint bindings. The ODL-simple appro= ach here is to introduce a hard dependency on Guice/Mycila as a replacement= for dynamic/BP services. Mycila is a dead project, so any attempt to reuse= this approach should re-visit the integration to use an actively-maintaine= d upstream.
The overall approach here need to be well defined, so as not to tie us t= o a single DI framework, as there is a number of different frameworks avail= able:
Components leveraging Entity Ownership Service and Cluster Singleton Ser= vice have an inherently dynamic lifecycle which, at least in the case of BG= PCEP, involves instantiating services in OSGi Service Registry and having c= omponents react to them. In the case of BGPCEP this is the case of RIB inst= ance becoming master and Topology Manager starting local node processing. W= e need to have a solid answer on how to migrate these use cases without hav= ing each project sprout their own dynamic lifecycle API/implementation comp= onent, as those are bound to be buggy.
A number of our components currently rely on OSGi Config Admin interface= to provide deployment-specific 'static' configuration. This configuration = would typically be read once during ODL startup although Karaf does have pr= ovisions for updating this at runtime. A static wiring component should pro= vide a well-standardized interface, so that individual projects do not end = up rolling their own "solution", wreaking havoc to users being able to inte= grate this ability.
Some components rely on dynamic configuration, which is typically held i= n MD-SAL, but there are also separate mechanisms invented to deal with some= other requirements -- for example BGPCEP's config-loader components and NE= TCONF's model side-loading capability. These should be analyzed and strict = guidelines on lifecycle should be created, so that interactions with persis= tence are clearly defined, especially in terms of lifecycle interaction.
Karaf provides a CLI infrastructure, which is deemed useful for a number= of projects. The need for a CLI in cloud-native deployments is to be deter= mined and this item needs to be addressed.
Samuel Kontri=C5=A1 - samuel.kontris= @pantheon.tech
R=C3=B3bert Varga - robert.varga@panth= eon.tech
Martin Bob=C3=A1k - martin.bobak@panth= eon.tech
Tejas Nevrekar - tejas.nevrekar@gmail.co= m
Balaji Varaaraju "bvaadar@luminanetworks.com"
Jamo Luhrsen "jluhrsen@luminanetworks.com"
Samuel Kontri=C5=A1 - samuel.kontris= @pantheon.tech
R=C3=B3bert Varga - robert.varga@panth= eon.tech
Martin Bob=C3=A1k - martin.bobak@panth= eon.tech
Current codebase - github.com/PantheonTechnologies/lighty-core=
License is compatible (Eclipse Public License - v 1.0) and packages will= be renamed from io.lighty.* t= o org.opendaylighty.lighty.*