Add link to generated CRD doc

[upodroid]

Fixes: #432

[ravindk89]

@harshavardhana @dvaldivia there was a discussion a while back about reducing the size of the CRD by removing some descriptor fields. Is that still a concern, where the generated docs might be inaccurate (or partial)?

[harshavardhana]

@harshavardhana @dvaldivia there was a discussion a while back about reducing the size of the CRD by removing some descriptor fields. Is that still a concern, where the generated docs might be inaccurate (or partial)?

There doesn't seem to be the case, I have generated with the CRDs in master @ravindk89 and they seem to generate fine.

[dvaldivia]

@harshavardhana yes it's still a concern, the kubernetes API will reject the CRD if it's too large which happens with the two versions in a single CRD

[harshavardhana]

@harshavardhana yes it's still a concern, the kubernetes API will reject the CRD if it's too large which happens with the two versions in a single CRD

does it still happen? @dvaldivia

[dvaldivia]

@harshavardhana yes if we add the descriptions

[harshavardhana]

@harshavardhana yes if we add the descriptions

the crd.adoc is generated with whatever crd is in master - I am assuming this issue is handled in master @dvaldivia

[ravindk89]

So based on @dvaldivia 's post, my assumption here is that eventually the CRD generation will not include the description fields, because we intend to (or already have) removed them.

We might still be able to use the CRD generation as just high-level fields. I can parse the adoc and compare it to what I've already documented so I can at least track changes to the CRD as they come. That way we can try to mix a best-of-two-worlds approach, with programmatic generation of the skeleton, but comprehensive reference docs that don't bog down the CRD size.

Thoughts @harshavardhana @dvaldivia

[harshavardhana]

So based on @dvaldivia 's post, my assumption here is that eventually the CRD generation will not include the description fields, because we intend to (or already have) removed them.

We might still be able to use the CRD generation as just high-level fields. I can parse the adoc and compare it to what I've already documented so I can at least track changes to the CRD as they come. That way we can try to mix a best-of-two-worlds approach, with programmatic generation of the skeleton, but comprehensive reference docs that don't bog down the CRD size.

Thoughts @harshavardhana @dvaldivia

if we haven't removed them - can we remove them?

[ravindk89]

@harshavardhana https://github.com/minio/operator/blob/master/resources/base/crds/minio.min.io_tenants.yaml the desc fields are already removed in master from what i can see

[harshavardhana]

@harshavardhana https://github.com/minio/operator/blob/master/resources/base/crds/minio.min.io_tenants.yaml the desc fields are already removed in master from what i can see

Then generating doc is fine @ravindk89 its automatically able to add generic descriptions

[nitisht]

Can we take this @ravindk89 @harshavardhana @dvaldivia

[ravindk89]

Yeah @nitisht I think we're OK. My big action item is to migrate the independent work I've done on documenting these fields into the code base so the autogenerated CRD has more useful details. This will take time, but in the short term linking to the generated docs is still our route forward.