14:05:38 #startmeeting architecture committee 14:05:38 Meeting started Wed Aug 14 14:05:38 2019 UTC. The chair is farheen. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:05:38 The meeting name has been set to 'architecture_committee' 14:07:04 #topic Licensing 14:07:54 #info Michelle sharing two slides functional view for Clio and the API. 14:10:06 #info functional view License User Management (LUM) License manager is the client library inside of Acumos. The License Manager Client LIbrary talks to the LUM. Supplier Mgt. Processes will add the license profile. We had the name license in Boreas but was confusing. It was reference ifnormation about the license. From the supplier perspective. 14:10:06 14:13:35 #info If you are the subscriber and want a rite to use the supplier provides rite to use to the purchaser. Once you have the license agreement you can complete the RTU files who would then load it into their instance of LUM. When the model user wants to use a model Acumos client manager asks LUM if the action is allowed becuase LUM understands th 14:13:35 e rite to use. 14:14:19 #info Reviewing teh High level functional APis deck. 14:15:40 #info LUM needs to understand what the assets are in Acumos to manage activities for entitlements. License manager library will provide LUM model profile. Then another API loads into LUM the rite to use from the company's rite to use policy. 14:17:08 #info the next API is to entitle or deny based on the RTU rules that were provided. The LUM will check if it's OK to proceed. You need to call LUM to see if the action is entitled is denied on and off platform. Download and deploy. We are working with Guy regarding deploying to LUM off platform. 14:17:27 #info API for supplier reporting or downstream processes. These are the LUM APIs. 14:18:29 #info License manager APIs to support the portal function. One for the webform and iframe integration. Where you load your license profile but you need to retrieve license profile for storing the license artifact. 14:19:11 #info these are the LUM and license manager apis that are there. 14:19:26 #action Michelle Martens put the deck under license manager wiki. 14:19:40 #topic ORAN Design wiki page 14:23:05 #info because O-RAN wiki was not ready. I will move that information into the O-RAN wiki space. 14:25:10 #info O-RAN intelligent controller is to improve the Radio access network. 14:27:34 #info reviewed http://www.o-ran-sc.org and https://www.o-ran.org/ architecture page. Read up on the project at https://wiki.o-ran-sc.org/ 14:29:43 #info sometimes these computations have to be done quickly so there is a notion of a real time RIC and a slower one that is non real time RIC. eNB gNB diagram being sharing https://wiki.o-ran-sc.org/display/ORAN/O-RAN+Software+Community?preview=%2F65591%2F1179825%2FONS_RIC.pptx https://wiki.o-ran-sc.org/display/ORAN/O-RAN+Software+Community?previe 14:29:44 w=%2F65591%2F1179825%2FONS_RIC.pptx 14:31:37 #info xApp built using Acumos microservice diagram. nano messaging is unique protocol in RIC. Can Acumos communicate nano messaging? We want to communicator for the nano level protocol. 14:33:45 #info the idea is you can use a microservice adaptor to run in a k8 and speaks the rest like protocol on the rmr protocol a tare of the xApp speaking rmr. Controlled by a config file that tells it what messages to listen for on the RMR bus and how to map the messages to the calls to the functions of the microservice. When it receives a message it 14:33:46 formats a call to the standard rpc call and gets a response it knows to put the message on the bus of the comutation it performed. It 14:33:58 #info are we storing the data anywhere? 14:35:45 #info someone else will be listening for the call. Why not use Nifi? We want to use rmr to be quick and fast. We are also using this grc overhead. We have done measurements on what the overhead is. 14:36:13 #info when we collect the data and process it. Are we using Nifi or Flynk to send it back? 14:37:13 #info we are not collecting data. They are running on the edge network so only certain models. 14:37:58 #info context of collecting data will happen if the question arises regarding training then that will be done elsewhere. 14:38:15 #info not on the edge network 14:39:05 #info https://wiki.o-ran-sc.org/display/RICA/ML-based+xApp 14:39:24 #info The first approach is to get a hello world test. We have a few candidate applications we are looking for as a proof of concept. Automating the process of creating the configuration and having auto generating. 14:39:47 #info person trying to create a RIC app will be able to create an xAPP ms without a lot of overhead. 14:40:18 #info and people writing xApps will write it in Acumos and create the xApp without having to understand the rmr protocol. 14:40:55 #info It will be easier to write it in Acumos rather than code it up myself. 14:42:34 #info from the Acumos architecture perspective what are the impacted components? One is common services. Micro adaptor work will be done in microservices. Federation apis will be used if federated. If it's a direct link to RIC there is a direct path between Acumos and RIC. 14:44:39 #topic ML Wb - CouchDB + k8 designs status 14:45:27 #info we are adding nosql database to Acumos. We are adding another flavor. It can run on kubernetes 14:48:52 #info we are using open source couch lite that comes as a library used by ML Worbench. Couchlite provides Apache 2.0 license which is open source. It can integrate directly from the service to nosql CouchDB. It is more flexible and is scalable. There can be some duplication of data since it is not normalized. Use Couchlite to build your query a 14:48:52 nd the json object can be saved. If any of the microservice or portal UI have to pull user or model info from current CDS and link it to the nosql database. Will you use the existing apis to store ids or are you suggesting changes to existing CDS? 14:49:33 #info for now we are not trying to move data from mariadb. We are not writing new queries but using existing apis. 14:50:32 #info is that LightCouch? Couch seems to be very lightly used from spring boot concerns. Yes, we are keeping it generic and not tightly coupled. 14:50:58 #info What is our justification? One is proper license and nosql license. 14:51:49 #info we analyzed a few. Couch is better because many of them come with a caveat. 14:52:10 #info if our design is replaced with a nosql database has no or low impact. 14:52:28 #info but if it's tightly coupled it may raise concerns. 14:52:38 #info I agree we are keeping it lightly coupled. 14:55:35 rrprise version. If our flows depend on pipelines then you need to buy the license. Ou 14:56:44 #info Acumos should not have any dependencies on the enterprise edition. 14:58:29 #info a recommendation to have two meetings per week? The core TSC meetings can not be combined. PTL and Architecture meetings have focused agenda. PTL meetings are for blockers. Weekly we have three community calls Architecture, Community, and TSC call. 14:58:50 #info Google manage has one meeting per week. I'm not asking you to change but give it some thought. 15:00:31 #info we also have to track development delivery. Did the component deliver their final user story. Reviewing https://wiki.acumos.org/display/AR/Architecture+Reviews+Score+Card 15:00:58 #info From Tausif TechM to Everyone: (10:17 AM)
i have to drop at 10:30 EST.. Vasu will be covering me for Portal
From Nat - TechM to Everyone: (10:57 AM)
Can u post the comparison chart
on the chat windos
window
or on the Wiki page
From sg996a to Everyone: (10:59 AM)
https://camunda.com/enterprise/?__hstc=12929896.32e8befd88194679a688ee78982f762f. 15:00:59 1563459922955.1563459922955.1565794500081.2&__hssc=12929896.1.1565794500081&__hsfp=4117843994 15:01:19 #endmeeting