14:02:08 <farheen_att> #startmeeting Architecture Committee 14:02:08 <collabot> Meeting started Wed Oct 30 14:02:08 2019 UTC. The chair is farheen_att. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:08 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:08 <collabot> The meeting name has been set to 'architecture_committee' 14:02:19 <farheen_att> #topic agenda items 14:08:17 <farheen_att> #topic clio release update 14:19:05 <farheen_att> #info Acumos-3420 High issue will be addressed by Justin and Bryan 14:19:59 <farheen_att> #info reminder to team to add demeter release features to etherpad 14:20:43 <farheen_att> #info Ken - was able to onboard a spark model 14:21:56 <farheen_att> #info All PTLs, here is the ether pad link just FYI - https://etherpad.acumos.org/p/DemeterPlanningWorkshop 14:22:08 <farheen_att> #link https://etherpad.acumos.org/p/DemeterPlanningWorkshop 14:25:50 <farheen_att> #info Ken discovered that portal is not calling security verfication. Acuoms 3644 14:26:12 <farheen_att> #topic Clio port mapping 14:26:39 <farheen_att> #info Ken gave up on it. Whoever the governing body of standards to follow. 14:27:13 <farheen_att> #info Once the team comes up with a proposal 14:27:40 <farheen_att> #info Bryan - Ken is looking to Architecture committee for the principles. 14:28:25 <farheen_att> #action Architecture committee come up with a principle 14:28:39 <farheen_att> #info Manoop - We need to understand some general guidelines. 14:29:41 <farheen_att> #info If we need a list of focused issues such as port conflicts and how to handle them in case of docker compose style of requirements. 14:30:03 <farheen_att> #info Bryan - Name space management is an issue. It is a very complex for Ken. 14:30:15 <farheen_att> #info #2 is security 14:30:50 <farheen_att> #info there are services that are exposed that should not be exposed. We need to make sure all services are driven by the security issues of the platform. 14:32:53 <farheen_att> #info how about we review the standards 14:33:16 <farheen_att> #info if the team could review the security verfication and come to a decision. 14:33:31 <farheen_att> #info can we bring that discussion into the architecture call. 14:33:54 <farheen_att> #action Manoop schedule the review into the architecture committee's agenda. 14:34:41 <farheen_att> #info we should question other teams that when their port mapping and let them come back with a counter proposal. 14:36:19 <farheen_att> #info ideally we would have a set of architects to establish principles but in open source the community (architecture committee) is challenging 14:38:05 <farheen_att> #info Ken deployment has gaps that need to be addressed by TechM team 14:38:59 <farheen_att> #info Bryan when we have API changes we find we have to quickly restore the api contract. We need a way to detect automatically or a forced review regularly. 14:39:35 <farheen_att> #info Manoop - we ask for the apis to be delivered by M3 and must be consumed. 14:40:22 <farheen_att> #info that's a waterfall process. Changes are made at the last minute. We need tools that inspect the api calls and flag that the build fails. 14:41:12 <farheen_att> #info Sayee - we have to think about backwards compatibility and last minute changes have to be reviewed regularlyu. 14:41:39 <farheen_att> #info if we leave the apis to be delivered by the last minute then we fail. 14:43:47 <farheen_att> #info If APIs are not released then the entire release is at stake. 14:44:20 <farheen_att> #info if the apis are released at the last minute then the entire release is at stake. 14:44:50 <farheen_att> #info what if there is a need to change the api. What is the procedure? 14:45:18 <farheen_att> #info risk vs. reward and have the committees vote. 14:45:36 <farheen_att> #info what is the thing that says here is the change that kicks off the decision process. 14:45:55 <farheen_att> #info by nature the integration strategy where they will break. If the planned features are being delivered. 14:47:04 <farheen_att> #info trigger types: 1. we detect things when they break. 2. when a developer knows there will be an impact we put a flag or string that we can track. Then the architecture team can review the trigger. 14:47:40 <farheen_att> #info Manoop - yes these triggers are listed in M1 and M2 checklists. 14:48:01 <farheen_att> #info Bryan - thats documentation I'm talking about systematic automatic triggers. 14:48:46 <farheen_att> #info changing things after the face. We need to define the things that are going trigger after the M1 dates. 14:49:20 <farheen_att> #info two items that came out of this discussion the API handling their dependencies and the trigger points automation. 14:49:38 <farheen_att> #info Sayee - regarding namespace should we have all the components in the same cluster / name space? 14:50:03 <farheen_att> #info Sayee - we did not go into discussions yet. 14:50:19 <farheen_att> #action Manoop is setting up this topic and will pull Sayee into that discussion. 14:50:50 <farheen_att> #topic SOAJS 14:51:18 <farheen_att> #link https://www.soajs.org/ 14:52:06 <farheen_att> #info this can be used in and is advantageous to Acumos. It is up to this team to determine if it fits into the demeter requirements 14:53:21 <farheen_att> #info once a model is onboarded will be linked with a data set trained deployed for individual models. In that area we are exploring jenkins, nifi however complimentary to that SOAJS says if you provide service code it can pull the code and catalog a list of apis package and deploy. 14:53:29 <farheen_att> #info does it work in different languages? 14:54:21 <farheen_att> #info yes, i wanted to bring this to the deployment and test teams to see if this benefits us compared to jenkins and nifi pipelines. If it cataloging a list of apis. 14:54:38 <farheen_att> #info this tool is promising that it will have a us. Guy - I'm skeptical. 14:55:13 <farheen_att> #info Guy - protobuf is what we have in common and have SoAJS work with that. 14:57:33 <farheen_att> #info Manoop - if you have a ms you can manage from the code repo and deploy into mulitple environments. They have a design studio tool as well. There may be value in using it. I wanted to bring it to this teams attention. One if from onboarding and the other is from deployment. Soajs give a host port and a key to connect and now you are ready 14:57:33 <farheen_att> to deploy to your kubernetes environment. 14:58:40 <farheen_att> #info Bryan - there are others such as Argo and kubeflow. I suggest they also be looked at. 15:00:32 <farheen_att> #info Kubernetes and jenkins can be two different things. Keep in mind what you think you are getting and what you actually get are different. 15:00:41 <farheen_att> #topic K3 15:01:26 <farheen_att> #info will our models work a kubernetes edge? K3 claims it is light weight. If you package your model in K3 and work on rasberry pie. 15:02:03 <farheen_att> #info Bryan - as long as it's cloud native and backwards compatible and adhere to the k8 apis. But if is a variant of k8 it will be problematic. 15:02:27 <farheen_att> #info Manoop documented what is k3 and k8. Bryan support. 15:02:48 <farheen_att> #info is NXV still involved in Acumos? These are light weight. 15:03:01 <farheen_att> #info NFV is light weight 15:03:13 <farheen_att> #info so is raspberry pie 15:03:45 <farheen_att> #info this would be a great opportunity to use these lightweight boxes. 15:04:28 <farheen_att> #info in demeter we want to reduce the size and space for the models. 15:04:48 <farheen_att> #info ONAP community is also exploring. 15:04:54 <farheen_att> #endmeeting