Codegen Template variety in the generated go code that has the interfaces definitions

[guptasu]

Adapter developers mainly just look at the documentation associated with the generated interface in the generated go file. Consider having a constant or a Comment generated in that file that describes the template variety associated with the mesh function. Otherwise it is tricky for Adapter developer to know a particular mesh function is a CHECK/REPORT/QUOTA kind. They will have to look at the proto file.

@geeknoid @mandarjog @ZackButcher @douglas-reid WDYT ?

[geeknoid]

I think this is a reasonable addition, it can't hurt.

On a related topic, given an adapter, how do we expect an operator to know the kind of instance to send to this adapter? Does the adapter doc simply point to the repo location of the template?

[guptasu]

@geeknoid What mesh functions an adapter supports are runtime concepts. I would imagine, exactly what you proposed, every adapter to have a README.md that lists, at the top of its doc, directory locations of all the mesh functions it's implementation supports.

The overall discovery story will be based on directory location and README.md in those directories.

• mixs lists all the directories for adapters and supported mesh functions
  sample output of mixs --show_adapters_and_mesh_functions

---

Supported Adapters

• iostio.io/mixer/adapter/prometheus
  ..
  ..
• iostio.io/mixer/adapter/statsd

Supported Mesh functions

• iostio.io/mixer/template/metric
  ..
  ..
• iostio.io/mixer/template/quota

---

This information is sufficient for Adapter developers and operator to go find all the README they are suppose to read to get their work done.