#acumos-meeting: Architecture Committee
Meeting started by farheen_att at 14:02:08 UTC
(full logs).
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)
- 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)
- 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
(full logs).
Action items
- Architecture committee come up with a principle
- Manoop schedule the review into the architecture committee's agenda.
- Manoop is setting up this topic and will pull Sayee into that discussion.
People present (lines said)
- farheen_att (68)
- collabot (3)
Generated by MeetBot 0.1.4.