14:03:45 <farheen> #startmeeting Architecture Committee
14:03:45 <collabot`> Meeting started Wed Jul 10 14:03:45 2019 UTC.  The chair is farheen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:45 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:03:45 <collabot`> The meeting name has been set to 'architecture_committee'
14:07:16 <farheen> #topic Agenda
14:10:03 <farheen> #info Design review for License Management: Any issues with design?  Michelle: I have reached out to other PTLs so they are aware of who will be impacted by licensing.  I have reached out to PTLs.  Manoop: If the PTLs have issues with your design have them discuss in this forum.  Or if there are no issues then we can review your design when you are
14:10:03 <farheen> ready.  Michelle: So far no issues.
14:10:25 <farheen> #action Michelle prepare for a design review discussion next week.
14:11:24 <farheen> #topic Portal Team Design
14:12:02 <farheen> #info Mukesh: we had a discussion with Michelle around licensing.  OA&M Vinayak was working on wireframe resources for the system.
14:18:58 <farheen> #action Mukesh make a list by the end of this week for the changes for licensing.  With the new template you should be able to respond to a template error or not.  It is a new requirement.  There is a requirement for templating.  A template is for the license profile and have a generic template instead of a web form.  Stored in glum or CDS.  Simila
14:18:59 <farheen> r to the github UX.  Display on the portal the user to choose from and scanned.  The user takes the teamplate fills out and then gets loaded back up we typically scan.  Bryan: That scan already happens.  when you update a license is immediately scanned.  That upload license invokes a scan.  when I upload the template it will land in the Nexus repo
14:18:59 <farheen> then we will invoke the scan.  Are you sure the results will come back immediately?  Bryan: Fast but not immediately.  It varies on the complexity of item being scanned.  It is an asynchronous call.  We need to be cautious around this ux.  Mukesh: Assume we have a valid SV scanned license.  The next time I scan will I be notified immediately about
14:19:00 <farheen> the validation of the second license.  Bryan: On the wiki under security verfification.  Look at the list of use cases.  Each build is verified through SV.  If anyone sees an issue and with the matrix then ask Bryan Sullivan.  He is varifying all the use cases.
14:20:08 <farheen> #action Mukesh update Bryans matrix about security verfication.
14:26:38 <farheen> #info OA&M is a house keeping step.  BE process is ready but the FE UI needs to be developed.  Manoop: Backup and purge will run weekly or monthly?  Mukesh: Is it a cron job, syncrhonous, asynch.  call?  It is a threshold monitored call.  Manoop: Is the BE service for backup and purge.  Is it yes/no?  Or are you looking for a UI?  Parichay: Cronjob
14:26:39 <farheen> needs to be done through UI.  Let us get closure on the design.
14:28:09 <farheen> #info In sprint we are planning for improving the search design.  I reviewed in the wiki.
14:28:12 <farheen> #link https://wiki.acumos.org/display/MOB/Clio+Release
14:31:06 <farheen> #info locality / internationalization and design has been done also.  #action Manoop send Mukesh an email regarding locality and internationalization.  #action Manoop target design reviews for localization / internationalization on the next meeting.
14:32:30 <farheen> #info Nat we should lower the priority of this item.  We should be reviewing the design of the higher priority items.  Keep this design review as a lower priority.
14:33:02 <farheen> #topic Security Verification and Deployment Bryan Sullivan
14:34:24 <farheen> #info reviewed #link https://wiki.acumos.org/display/DEP
14:40:22 <farheen> Monitoring.  We need clear monitoring and assessing the resources being used across the platform.  Users want to deploy their platform according to their needs.  One proposal prototype can eliminate several hundred mG of RAM by eliminating the zool proxy and use K8 instead.  We want to remove the memory impact of java components.  Minimum is 16 Gb.
14:40:23 <farheen> Every component takes a gig or more.  The java components memory usage it adds up.  If you look at the Boreas architecture picture.  This is just the core.  We've added licensing to this.  We have to minimize the RAM impact and eliminate component where we can by making the zool routes the ingress routes.  Justing Early from Ericsson demonstrated
14:40:23 <farheen> this.  Mukesh: EngineX is mandatory? B: in this release there will be no focus on Docker from System integration perspective.  Yes, we need an ingress controller whether it's Kong or EngineX.  Mukesh: We use springboot everywhere.  B: I didn't say we should take spring boot out we should optimize.  Mukesh: I meant zool proxy not spring boot.  #act
14:40:24 <farheen> ion Mukesh talk to Justin about using the ingress controller instead of zool proxy.  B: If you're going to deploy this on the Docker implementation you will need a FE.
14:42:24 <farheen> #info Bryan Back to sharing deployment-clio.xml.  Why do we need multiple clusters?  Under shared services certain things have to be separated for security or  resource management systems.  Nifi and jupyterhub containers.  Asked by stake holders not to be deployed just for the Acumos platorm.  We have a VM in this release.  I have deployed jenkins
14:42:25 <farheen> as a prototype way.  We will be working on nifi as well so the weight of the core will be lighter.  We provide options.
14:45:57 <farheen> #info You may spin up a jenkins container for every job you want to execute.  Likely use case.  The amount of resources can vary widely depending on volume.  Separate them out of the cluster support is an architectural design.  We can break this further apart using K8 it's easier.  That will be an explicit object to demon that I  can across several
14:45:57 <farheen> servers.  Mukesh: Latency implications?  Bryan: Yes, but for security upgrade and maintanance.  For deployment this is what we reviewed is #link https://wiki.acumos.org/display/DEP/Meetings
14:46:52 <farheen> #info Present: Bryan, Vaibhav, Santosh, Raman, Phillipe, Senthil, EugenGoal for sprint 1: deploy a simple model using Jenkins driven by Java APIs/client functions added to the k8s-client, per a seed that is patterned on those used by the AT&T platform.What is a seed: a seed is a set of files (e.g. as you would find in a git repo), that contains at
14:46:52 <farheen> minimum a "jenkinsfile", .e.g. a jenkins instruction set. Other files may be source (python, Java), and the process may involve artifact retrieval from other repositories.This weekJenkins will be stood up in the techm VM. A script will be provided for others to test.The API needs to be prototyped/deploy/solutionSimilar to existing k8s-client code,
14:46:53 <farheen> e.g. determine if the solution is simple or composite/deploy/pipelinenew, based upon what the training project needs...how a deployed object relates to a seed will beprototype a configuration capabilityto start, through Spring envsimple: seed1python model: seed 1a...composite: seed2pipeline: seed3Bryan will provide a jenkinsfile that can deploy a s
14:46:53 <farheen> imple solutionconvert the deploy.sh script for use by Jenkinsprovision the script as a job under jenkinscreate a seed that invokes the jobprovide a k8s cluster where that job can be executedA simple model, e.g. padd, and deploy it into the k8s cluster using the k8s-client, seed, and JenkinsBryan will provide Jenkins credentials to Santosh
14:51:22 <farheen> #info Bryan: For this first week we will deploy a simple solution and connecting pipes together in an end to end flow.  By the end of the sprint we will do this with an actual seed with the AT&T platform.  We'll have a see with a sprint repo.  We have to figure out where these seeds live.  They can be further developed therefor needs a repo.  We ca
14:51:23 <farheen> n treat these as things that live in other Docker or Maven repos.  For the sake of intitial we will use one VM for the core and VM for these targets.  It will not include all the pieces that are in the illustration.  That's the sprint 1 plan for deployment.  Stand up a thing that has those core pieces.  We will be documenting the API in the core wi
14:51:23 <farheen> ki.
15:00:54 <farheen> #info Manoop Sprint 2?  Bryan: It's dependent on he outcome from the AT&T team.  Right now deployment client doesn't plan anything to Azure or Openstack.  Critical item is getting input from Sayee's team about what are the use cases?  We have a deployment of a solution and a deployment of training features.  Such as nifi, kafka, lynx.  Then we have
15:00:55 <farheen> run time views such as predictor in the workbench.  Key performance criterial for what is running.  That will be information that will be predicted by the UI of the workbench.  Do we do it through the client? Log system? or reports?  We have to answer these questions.  Manoop: MS generation as a model.  In this flow the docker image is not built y
15:00:55 <farheen> et we need CDS calls.  Are you assuming MS generation is already done.  B: Assumed that ms generation is already done.  For ONAP the VNF manager.  You are reporting from that application VES client to deliver to a listener just as we do for ONAP.  How do we monitor run time?  Do we use Prometheus, logging system, K8?  These decisions have to be mad
15:00:56 <farheen> e.  We need CMLP input.  Manoop: We'll need at least logging.  We'll ned logging for performance and license management.  Manoop: Other PTL concerns?  Guy is not on the call this week.  I would ask him how this impacts.  In this deployment flow of the models we are assuming that the models docker image is already generated using common services.  I
15:00:56 <farheen> s that acceptable or where are the triggers for ms generation.  Philippe These are triggered manually.  UX would be better to automate this process.  It would be best if ms generation and deployment are done automatically.  I do not perceive that we will achieve this for Clio.  To speed up deployment.
15:02:13 <farheen> #info Nat - we are looking at k8 for clio so we have to have IST and development environments.  Bryan: We have two VMs that are hosting on what we are doing right now.  Nat - this needs to be communicated to the team and coordinate.
15:02:35 <farheen> #action Michelle have a design review ready for the next meeting.
15:02:57 <farheen> #action Mukesh have a design review for UI design in the next meeting
15:04:28 <farheen> #info Michelle we are not sure whether we will use CDS for licensing
15:06:18 <farheen> #info Chris Lott: For CDS not more than a few items for Clio.  eNum value support.  Manoop: is the enum value impacting other components.  Chris: no.  The caveat is anyone who wants to start using the eNum value.  If they are in agreement fine.
15:06:23 <farheen> #endmeeting