#acumos-meeting: architecture committee

Meeting started by farheen at 14:05:38 UTC (full logs).

Meeting summary

  1. Licensing (farheen, 14:07:04)
    1. Michelle sharing two slides functional view for Clio and the API. (farheen, 14:07:54)
    2. 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. (farheen, 14:10:06)
    3. 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 (farheen, 14:13:35)
    4. Reviewing teh High level functional APis deck. (farheen, 14:14:19)
    5. 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. (farheen, 14:15:40)
    6. 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. (farheen, 14:17:08)
    7. API for supplier reporting or downstream processes. These are the LUM APIs. (farheen, 14:17:27)
    8. 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. (farheen, 14:18:29)
    9. these are the LUM and license manager apis that are there. (farheen, 14:19:11)
    10. ACTION: Michelle Martens put the deck under license manager wiki. (farheen, 14:19:26)

  2. ORAN Design wiki page (farheen, 14:19:40)
    1. because O-RAN wiki was not ready. I will move that information into the O-RAN wiki space. (farheen, 14:23:05)
    2. O-RAN intelligent controller is to improve the Radio access network. (farheen, 14:25:10)
    3. 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/ (farheen, 14:27:34)
    4. 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 (farheen, 14:29:43)
    5. 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. (farheen, 14:31:37)
    6. 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 (farheen, 14:33:45)
    7. are we storing the data anywhere? (farheen, 14:33:58)
    8. 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. (farheen, 14:35:45)
    9. when we collect the data and process it. Are we using Nifi or Flynk to send it back? (farheen, 14:36:13)
    10. we are not collecting data. They are running on the edge network so only certain models. (farheen, 14:37:13)
    11. context of collecting data will happen if the question arises regarding training then that will be done elsewhere. (farheen, 14:37:58)
    12. not on the edge network (farheen, 14:38:15)
    13. https://wiki.o-ran-sc.org/display/RICA/ML-based+xApp (talasila, 14:39:05)
    14. 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. (farheen, 14:39:24)
    15. person trying to create a RIC app will be able to create an xAPP ms without a lot of overhead. (farheen, 14:39:47)
    16. and people writing xApps will write it in Acumos and create the xApp without having to understand the rmr protocol. (farheen, 14:40:18)
    17. It will be easier to write it in Acumos rather than code it up myself. (farheen, 14:40:55)
    18. 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. (farheen, 14:42:34)

  3. ML Wb - CouchDB + k8 designs status (farheen, 14:44:39)
    1. we are adding nosql database to Acumos. We are adding another flavor. It can run on kubernetes (farheen, 14:45:27)
    2. 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 (farheen, 14:48:52)
    3. for now we are not trying to move data from mariadb. We are not writing new queries but using existing apis. (farheen, 14:49:33)
    4. is that LightCouch? Couch seems to be very lightly used from spring boot concerns. Yes, we are keeping it generic and not tightly coupled. (farheen, 14:50:32)
    5. What is our justification? One is proper license and nosql license. (farheen, 14:50:58)
    6. we analyzed a few. Couch is better because many of them come with a caveat. (farheen, 14:51:49)
    7. if our design is replaced with a nosql database has no or low impact. (farheen, 14:52:10)
    8. but if it's tightly coupled it may raise concerns. (farheen, 14:52:28)
    9. I agree we are keeping it lightly coupled. (farheen, 14:52:38)
    10. Acumos should not have any dependencies on the enterprise edition. (farheen, 14:56:44)
    11. 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. (farheen, 14:58:29)
    12. Google manage has one meeting per week. I'm not asking you to change but give it some thought. (farheen, 14:58:50)
    13. 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 (farheen, 15:00:31)
    14. 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. (farheen, 15:00:58)


Meeting ended at 15:01:19 UTC (full logs).

Action items

  1. Michelle Martens put the deck under license manager wiki.


People present (lines said)

  1. farheen (53)
  2. collabot` (3)
  3. talasila (1)


Generated by MeetBot 0.1.4.