15:01:59 <farheen_cefalu_a> #startmeeting Architecture Committee 15:01:59 <collabot`> Meeting started Thu Jan 24 15:01:59 2019 UTC. The chair is farheen_cefalu_a. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:59 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:59 <collabot`> The meeting name has been set to 'architecture_committee' 15:03:34 <farheen_cefalu_a> #topic Review of Training module and Plan 15:04:05 <farheen_cefalu_a> #info Michelle: We have Alex S. from AT&T to show the new design for license manager. 15:04:50 <farheen_cefalu_a> #topic Licensing Plan 15:07:54 <farheen_cefalu_a> #info Alex: We have a wiki page under License manager. License usage manager architecture. This is a draft and a work in progress. It's high level but is filling up with more details. High level overview intentions and concepts. What are the impacts on acumos and how we are going to interact. License usage manager we are using everywhere. The second piece we will get into details. the third part is license 15:09:54 <farheen_cefalu_a> #info 5. the API of the license usage manager. This is the api we expect acumos to use for license usage manager. This is high level intentions and talk. We want to keep moments here. We're have three big concepts. 1. Software and very fluid definition for the softwaer. We can have sotware id by licensing swid. It is like a version. 2. The second piece is license which is essentially default rules and lim 15:11:43 <farheen_cefalu_a> #info rules and limits will overwrite what's defined in the license and call also limit users or assets. 3. Assets are what the company is paying money for Asset is one specific copy of software. If you have a dvd it's a copy of the software and an asset. If you take the dvd and install it on a laptop then you have an asset in dvd and an installed software is a different state. Now this is the impact to acumos. 15:13:51 <farheen_cefalu_a> #info we want to limit the number of fields like software ids and license ids. These are 4 things we're talking about and we're going to have toagree on the lifecycle of all of them. Concept is we will touch the license usage manager to the state machine. We want acumos to interrupt its workflow and ask for license entitlements. We are going to work on limits and rules on state diagrams. How many actions and tra 15:15:32 <farheen_cefalu_a> #info we also expect acumos to upload the license and write to the usage manager. We have some defaults set. We also understand that acumos is trying to do the composition and training of the models and solutions. We have to track and acquire licenses for chained solutions. Acumos doesn't have to make decisions or tracking of the license usage. The license usage manager will do this. Any questions? 15:17:21 <farheen_cefalu_a> #info Michelle: I want to clarify that we are not referring to the state of the model is not private, company, or public. Alex: No. The state machine will be what happens in catalog to everything that can happen in deploy. Any action that happens with the software. It's a little bit like DOM. I think i covered right to use and license usage manager will merge them and figure out what are the rules. We talked a 15:19:15 <farheen_cefalu_a> #info this is a high level state machine. I was thinking acumos already has. We're going to have it in a generic way that adds to the state machine. there is a big piece of catalog deployment and download. i want to share and envision that is close enough i have some extra. The things that we want to find from state machine are 1. we want to know all the limits on each state. 2. State transitions require lice 15:21:17 <farheen_cefalu_a> #info blic and interrupt and ask license manager that is sent from state to state yes or no. Another similar but important is deploy is a copy of the software and LUM will have to assign a tag and LUID will send it back. We have two different assets with totally different lifecycle. You can ask for entitlement. You can ask for all the state diagrams of that vendor for that model. We can find the rules to entit 15:23:04 <farheen_cefalu_a> #info state diagram. for example if you're going from catalog to deployment state this is how we put rules and limits on the state diagrams with license usage. If this state requires acquisiton of the asset check or no check. Only one copy of this software piece is allowed to be deployed at one time. if something is deployed and released in the end the second deployment can happen. Entitlement will say you hav 15:24:45 <farheen_cefalu_a> #info can have this restrictions on every state. You can only have up to 5 assets. if it's federated in there is a role here and it's limit is zero then we do not allow to change the state. You will not go anywhere. It's still a work in progress and we can put rules. This is applicable to acumos and we can use. 15:26:47 <farheen_cefalu_a> #info Bryan: To clarify these wireframes are not for the user UI. Alex: There are three steps. state diagram can be used for each software piece. Second step we will put in default rules ok you're allowed to put it in catalog but you are not allowed to download or deploy. Step 3. if someone pays money then it overwrites all the default rules. 15:28:01 <farheen_cefalu_a> #info Alex: This is intention. I am not saying this will be ready for this release. We will get started. Michelle: In the first phase we are going to check that there is a default license there is a models. There is an entitlement that exists. It may not go through detailed constraints but perform a basic check. 15:29:26 <farheen_cefalu_a> #info Alex: Next slide start with inside of acumos. Key table where we are going to touch our license fields 15:31:43 <farheen_cefalu_a> #info Alex 3 software fields specific to software models. It is the primary key to the software id table which says it's a project developed by id. We are going to store that data in license usage manager and send it to get it on the federation step. 15:33:54 <farheen_cefalu_a> #info Bryan: At this point we dont have jira items to push artifacts to license usage manager. Alex: If that happens outside then we will look for software id. The second id is a license id for this software. It would be the same and a one to many relationship in software ids. Bring in the license info into LUM it will not be done by acumos then we don't need to have the second field. Bryan: There are two thing 15:36:37 <farheen_cefalu_a> #info for the right to use. Bryan: There will be rights to use that are assigned to the platform. Site admin. Alex: 3. Right to use. I was thinking it was about user. Acumos can decide. It's the rights to use. It's the first message that is sent when the asset is acquired. LUM will figure out what to use for that specific. As soon as LUM identifies. We're intterupting state machine. One important piece is 15:38:35 <farheen_cefalu_a> #info server inside of acumos. any piece in acumos can talk to license guard. Deliver back responses. Bryan: This is represented on a draft. Alex; this is what we did in ASD and CCD. And bottom table is when something is deployed. On deploy state we can return back the license keys. Extra data that is not for boreas but later. We are not sure how we will use license keys in general. Next slide onboarding p 15:40:22 <farheen_cefalu_a> #info license guard will talk back to license manager. This will happen at every state. See a glimpse of what is happening in license usage manager. It has licensing rights to use. look there. The last thing I have this swagger yaml for the API. It is very draft. We can talk about API when things are starting to freeze more. 15:41:56 <farheen_cefalu_a> #info Anwar: Michelle have we started implementation for boreas? M: We are aiming to put something into sprint 2. We haven't figured that out yet. Alex: Architecture is not yet finalized until we define the apis. Until then we are not going to start development until they have been identified. 15:42:25 <farheen_cefalu_a> #action Michelle: Let's capture in a line or two what is the plan to test in boreas. 15:45:23 <farheen_cefalu_a> #info Michelle: The basic is that the supplier provides default licenses and license manager. Anwar: Let's consider the 5G use case. Would Ericsson be able to federate licensed models? Alex; We will not do entitlements and put the tables for open source and some tracking information. Asset is acquired and released. Based on the collected data the supplier will put limits. That will happen after Boreas. For b 15:46:40 <farheen_cefalu_a> #action Michelle: Run the Boreas delivery functions to TSC, Jack will understand what you are implementing in the end. Check with Wen Ting. 15:47:19 <farheen_cefalu_a> #info Bryan: Do this on the release planning page so everyone in open source can see. We have the scope on that page and it needs to be updated. 15:48:01 <farheen_cefalu_a> #info Anwar: Make sure Michelle to tie down a use case to this so you can demonstrate. We need a working demonstration at the end of the release. 15:48:51 <farheen_cefalu_a> #info Anwar: Any update on your percentage increase of your boreas design and architecture. Keep it there for now. 15:49:07 <farheen_cefalu_a> #topic Resource allocation 15:50:07 <farheen_cefalu_a> #info Anwar: We have a core team we have identified. Let's sit down and review where we can move the resources. One place is portal. I want to see what are the portal plans for boreas. What are the other key big items for boreas. 15:51:30 <farheen_cefalu_a> #action Mukesh send Anwar the UI related big ticket items for resource allocation. 15:53:57 <farheen_cefalu_a> #info Phillippe: Model onboarding is 100% because functionality architecture design have been designed. From my side. 100% for onboarding. Anwar: And you are including ms minus docker release. P: Yes but we have to discuss. It is in the scope of onboarding. Catalog data model Chris: That is scheduled for sprint 2. I have no updates. Alex makes sure Chris gets apis for license. This has to be done in advance 15:55:08 <farheen_cefalu_a> #info We aren't ready. Anwar: Let's make sure the scope for Boreas release is agreed by the TSC. At the end of every release we have marketing announcments and acumos AI day. We have to make sure we know what we are going to deliver for boreas. Alex: We need time to scope. 15:55:41 <farheen_cefalu_a> #action Nat Get the TSC and release management can track Licensing. 15:55:50 <farheen_cefalu_a> #topic Training 15:56:53 <farheen_cefalu_a> #info Anwar: We'll have ML workbench Nifi, jupyterhub/zeppelin AccuCompose, Tensboard? Bryan: Yes, this is the scope. 15:57:30 <farheen_cefalu_a> #action Bryan: Set up a meeting with Anwar and Mukesh around training. 16:00:09 <farheen_cefalu_a> #info Design Studio, Kazi: What is included is jupyter notebook, nifi, pipelines, AccuCompose. AccuCompose is DS renamed under the ML workbench. Jupyter, pipelines, are not wholly contained within the DS. ML Workbench contains Design studio that has been renamed to AccuCompose. 16:04:56 <farheen_cefalu_a> #info Anwar: Which components is DS in scope for the Boreas release. Replace Design Studio with ML Workbench.Jupyter notebooks, Nifi pipelines, kubeflow moved to clio. Rapid miner? Adi will have to address. Deployment Bryan? We're making progress on whitebox and Nifi. Security? No change. Common Services: Guy we haven't moved. We have the same things from last time. We have to add the ONNX style generation. 16:05:41 <farheen_cefalu_a> #info model runner improvement. I expect a big change for next week. Anwar: That concludes. Nat set up a time for training and overlap with ml workbench. let's set up time. 16:05:54 <farheen_cefalu_a> #action Nat Set up time for a deep dive into training. 16:06:00 <farheen_cefalu_a> #endmeeting