Date


Agenda: Round 2 of the discussion for Fabric Operator in Bevel


Attendees-

Sownak Roy (SR)

Arun S M (ASM)

David Enyeart (DE)

David Viejo Pomata (DV)

Hart Montgomery (HM)

Josh (JM)

Ratnakar Asara  (RA)

Suvajit Sarkar (SS)


Discussion items–

  1. SR: Summary of previous call and action items from it.
  2. DV: hlf-operator architecture and list of its features.
  3. DV: hlf-operator uses operator sdk written in golang and internal helm charts for HL Fabric components deployment on Kubernetes cluster.
  4. DV: hlf-operator has fabric operation console integrated as read-only.
  5. DV: External CA integration and new HL Fabric features are on current roadmap for hlf-operator.
  6. RA: fabric-operator introduction and features.
  7. RA: fabric-operator supports deployment on Kubernetes and OCP and use ingress and routes respectively.
  8. RA: fabric-operator uses API calls to k8s cluster plane for the resource deployments.
  9. RA: Operation Console UI can be used to generate CRDs for the fabric operator deployment using the operation console’s deployer code.
  10. Both hlf-operator and fabric-operator uses multiple controllers.


Summary-

 

DV: hlf-operator and fabric-operator has different approaches and caters to their respective customers; it would be better to continue separately and learn for each other.

JM: Would like to see what the consumers and community says is required for the operators. An operator should be only responsible for deploying nodes and exposing them. Existing operator should continue to serve their current customers and keep backward compatibility. Existing operators should do only deployment, start and stop of fabric nodes and all other admin operations (channel creation, channel update, chaincode deployment etc.) should be done by using fabric-admin sdk.

DE: Agreed on JM comments, and mentioned that with exiting customer commitments there would not be enough people to work on the 3rd operator from scratch.

ASM: Agreed on JM comments. We should work towards single effort. Existing hlf-operator should be under bevel.

SR: Admin SDK to do fabric operations makes sense keeping the deployment operator simple. Both hlf-operator and fabric operator team should participate in fabric admin sdk discussions and shape their product roadmap.


Action Items-

  1. RA, DV and SS to participate in fabric admin sdk discussions.
  2. hlf-operator to be merged under bevel as bevel-operator-fabric.