Follow up for Add automated documentation for metrics

[avlitman]

This Issue will detail the follow up suggestions that need to be implemented and/or discussed:

Follow up for: #6114:

1. Add link to the metrics doc to the main README.
2. Add condition to the log message to be more specific, like "webhook and metrics" where apt, or just "with webhooks".
3. Update metricsdocs file to use Go template instead of creating a whole bunch of constants. Example template:

const metricsTemplate = `# Operator Metrics
This document aims to help users that are not familiar with metrics exposed by this operator.
The metrics documentation is auto-generated by the utility tool \"monitoring/metricsdocs\" and reflects all of the metrics that are exposed by the operator.

## Operator Metrics List
{{range .}}
### {{.Name}}
**Description:** {{.Description}}

**Type**:  {{.Type}}
{{end}}

## Developing new metrics
After developing new metrics or changing old ones, please run \"make generate-metricsdocs\" to regenerate this document.

If you feel that the new metric doesn't follow these rules, please change \"monitoring/metricsdocs\" according to your needs.

Then you can render this template by running something like:

tmpl := template.New("Operator metrics")

tmpl, err := tmpl.Parse(metricsTemplate)
// handle error

out := &bytes.Buffer{}
mList := metricList{}
err = tmpl.Execute(out, mList)
// handle error

4. Moving the common generator code to a library. The generator should live in the operator project, but its helpers can still can be moved to a common place.

[varshaprasad96]

@avlitman is this issue being worked on? Would we able to get this in by next release (1.28). If not, please let us know, we can move it to the next one. Thanks!

[avlitman]

@avlitman is this issue being worked on? Would we able to get this in by next release (1.28). If not, please let us know, we can move it to the next one. Thanks!

As we discussed in private. Postponed to the next version (1.29.0).

[varshaprasad96]

@avlitman any inputs or discussion on this issue. If so, could you please update it with nay action items which need to be done to close it. We were triaging this issue for 1.29 (scheduled to release on May 31, 2023), please let us know you would like to have the issue in there.

[oceanc80]

@avlitman Do you think this will land for 1.30 (scheduled to release on Monday June 26, 2023)? If not, we can push this to the 1.31 milestone.

[sradco]

@oceanc80 Please push this, We had to also postpone working on this due to other obligations.

[avlitman]

@oceanc80 Please push this, We had to also postpone working on this due to other obligations.

+1 Thanks @sradco.

@oceanc80 sorry for the late response, do we know the date for 1.31? so I will make sure to update here if this is ready.

Thanks a lot.

[oceanc80]

@avlitman Date for 1.31 is so far scheduled for July 24.

[varshaprasad96]

@avlitman Just following up here. Would it possible to close this issue before 1.31 release? Thanks for working on this!

[avlitman]

@varshaprasad96 Hi, we have additional improvements for operator-sdk and we prefer to do it with this issue together. Please postpone to 1.32, thanks!

[varshaprasad96]

@avlitman Moving this issue to backlog. Once we have the PR ready, we can move it back to milestone. Does that sound fine?

[avlitman]

Yes, thank you and sorry we couldn't work on this.

[avlitman]

@varshaprasad96 Hi created the pr again, can review: #6588.
Sorry it took so long just the team was focused on other projects.

[everettraven]

#6588 has merged - closing this issue