======================================= #acumos-meeting: Architecture Committee ======================================= Meeting started by farheen_att at 14:02:08 UTC. The full logs are available at http://ircbot.wl.linuxfoundation.org/meetings/acumos-meeting/2019/acumos-meeting.2019-10-30-14.02.log.html . Meeting summary --------------- * agenda items (farheen_att, 14:02:19) * clio release update (farheen_att, 14:08:17) * Acumos-3420 High issue will be addressed by Justin and Bryan (farheen_att, 14:19:05) * reminder to team to add demeter release features to etherpad (farheen_att, 14:19:59) * Ken - was able to onboard a spark model (farheen_att, 14:20:43) * All PTLs, here is the ether pad link just FYI - https://etherpad.acumos.org/p/DemeterPlanningWorkshop (farheen_att, 14:21:56) * LINK: https://etherpad.acumos.org/p/DemeterPlanningWorkshop (farheen_att, 14:22:08) * Ken discovered that portal is not calling security verfication. Acuoms 3644 (farheen_att, 14:25:50) * Clio port mapping (farheen_att, 14:26:12) * Ken gave up on it. Whoever the governing body of standards to follow. (farheen_att, 14:26:39) * Once the team comes up with a proposal (farheen_att, 14:27:13) * Bryan - Ken is looking to Architecture committee for the principles. (farheen_att, 14:27:40) * ACTION: Architecture committee come up with a principle (farheen_att, 14:28:25) * Manoop - We need to understand some general guidelines. (farheen_att, 14:28:39) * 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. (farheen_att, 14:29:41) * Bryan - Name space management is an issue. It is a very complex for Ken. (farheen_att, 14:30:03) * #2 is security (farheen_att, 14:30:15) * 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. (farheen_att, 14:30:50) * how about we review the standards (farheen_att, 14:32:53) * if the team could review the security verfication and come to a decision. (farheen_att, 14:33:16) * can we bring that discussion into the architecture call. (farheen_att, 14:33:31) * ACTION: Manoop schedule the review into the architecture committee's agenda. (farheen_att, 14:33:54) * we should question other teams that when their port mapping and let them come back with a counter proposal. (farheen_att, 14:34:41) * ideally we would have a set of architects to establish principles but in open source the community (architecture committee) is challenging (farheen_att, 14:36:19) * Ken deployment has gaps that need to be addressed by TechM team (farheen_att, 14:38:05) * 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. (farheen_att, 14:38:59) * Manoop - we ask for the apis to be delivered by M3 and must be consumed. (farheen_att, 14:39:35) * 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. (farheen_att, 14:40:22) * Sayee - we have to think about backwards compatibility and last minute changes have to be reviewed regularlyu. (farheen_att, 14:41:12) * if we leave the apis to be delivered by the last minute then we fail. (farheen_att, 14:41:39) * If APIs are not released then the entire release is at stake. (farheen_att, 14:43:47) * if the apis are released at the last minute then the entire release is at stake. (farheen_att, 14:44:20) * what if there is a need to change the api. What is the procedure? (farheen_att, 14:44:50) * risk vs. reward and have the committees vote. (farheen_att, 14:45:18) * what is the thing that says here is the change that kicks off the decision process. (farheen_att, 14:45:36) * by nature the integration strategy where they will break. If the planned features are being delivered. (farheen_att, 14:45:55) * 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. (farheen_att, 14:47:04) * Manoop - yes these triggers are listed in M1 and M2 checklists. (farheen_att, 14:47:40) * Bryan - thats documentation I'm talking about systematic automatic triggers. (farheen_att, 14:48:01) * changing things after the face. We need to define the things that are going trigger after the M1 dates. (farheen_att, 14:48:46) * two items that came out of this discussion the API handling their dependencies and the trigger points automation. (farheen_att, 14:49:20) * Sayee - regarding namespace should we have all the components in the same cluster / name space? (farheen_att, 14:49:38) * Sayee - we did not go into discussions yet. (farheen_att, 14:50:03) * ACTION: Manoop is setting up this topic and will pull Sayee into that discussion. (farheen_att, 14:50:19) * SOAJS (farheen_att, 14:50:50) * LINK: https://www.soajs.org/ (farheen_att, 14:51:18) * 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 (farheen_att, 14:52:06) * 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. (farheen_att, 14:53:21) * does it work in different languages? (farheen_att, 14:53:29) * 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. (farheen_att, 14:54:21) * this tool is promising that it will have a us. Guy - I'm skeptical. (farheen_att, 14:54:38) * Guy - protobuf is what we have in common and have SoAJS work with that. (farheen_att, 14:55:13) * 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 (farheen_att, 14:57:33) * Bryan - there are others such as Argo and kubeflow. I suggest they also be looked at. (farheen_att, 14:58:40) * Kubernetes and jenkins can be two different things. Keep in mind what you think you are getting and what you actually get are different. (farheen_att, 15:00:32) * K3 (farheen_att, 15:00:41) * 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. (farheen_att, 15:01:26) * 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. (farheen_att, 15:02:03) * Manoop documented what is k3 and k8. Bryan support. (farheen_att, 15:02:27) * is NXV still involved in Acumos? These are light weight. (farheen_att, 15:02:48) * NFV is light weight (farheen_att, 15:03:01) * so is raspberry pie (farheen_att, 15:03:13) * this would be a great opportunity to use these lightweight boxes. (farheen_att, 15:03:45) * in demeter we want to reduce the size and space for the models. (farheen_att, 15:04:28) * ONAP community is also exploring. (farheen_att, 15:04:48) Meeting ended at 15:04:54 UTC. People present (lines said) --------------------------- * farheen_att (68) * collabot (3) Generated by `MeetBot`_ 0.1.4