Add available storage amounts documentation

[jrhastro]

In the Storage Resources section under the Fornax Console Capabilities section of the documentation, we have not listed how much storage is available for the shared EFS storage and long term S3 storage. There is also no information about policy (e.g., how long data will be stored; are data backed up; etc.).

[troyraen]

This should be covered by the User Resource Allotments doc but we'll have to double check once we get that doc. See #147.

[jrhastro]

Can we include the amounts in both places? I realize duplication means keeping track of values in multiple places, but putting basic information like storage quotas/amounts in an obscure, potentially hard-to-find document seems like folks will not find it. This is the kind of very basic user information that needs to be front and center.

[troyraen]

The User Resource Allotments doc will be linked to from the current Fornax Console Capabilities page so users can find it. I'm sorry but we can't duplicate this content. The User Resource Allotments doc will be under strict change control that occurs outside of this repo which is the reason the doc will exist here as a PDF rather than adding the content directly to the markdown files. This was discussed in the User Support meeting this morning.

[bsipocz]

The User Resource Allotments doc will be under strict change control that occurs outside of this repo

I don't see why those change cannot happen in the repo, we can add extra branch protection to make sure mandatory sign-off is happening from a well defined group of people (who now write the document outside of VC at a separate location) to any changes done to certain files.

That we way we could have both, tracking this info in one place and provide good user facing docs as well as keeping the integrity those docs files.

[troyraen]

It would be great if we could set up something like that in this repo that satisfies all requirements. It was proposed in the meeting this morning but one blocker was that folks didn't think it was possible to do that for only a limited set of files. The set of people who need to sign off on these docs is quite different from the set of people who work in this repo. There may be other blockers/requirements that I'm not thinking of right now. @bsipocz if you think you have a solution that can enforce the requirement that this set of change-controlled docs cannot be changed without approval by the appropriate set of people without requiring those folks to approve changes to other files in this repo, please post at https://discourse.fornax.sciencecloud.nasa.gov/t/feedback-wanted-on-best-way-to-incorporate-two-new-documents-into-our-documentation-area/386/8.

[bsipocz]

It was proposed in the meeting this morning but one blocker was that folks didn't think it was possible to do that for only a limited set of files.

Module level codeowners does just that, and there can be branchprotection rules that require a codeowner's PR approval for merging something.
I don't normally use these rulesets, but astropy itself has module level codeowners set up. The only caveat that org owners will have the power to override, but OTOH it's only 3 of us and we can know not to override.

[troyraen]

Awesome! I looked at codeowners briefly and it looks promising. There's some details I'm not sure about but can experiment to learn more.

[glr2024]

Gail here - If I can chime in with some concrete details, the things that need to be under change control are the "configuration" of the Science Console, e.g., the list of compute types that are offered, the types of storage (physical types), how much storage a user gets initially, initial credit allotment, etc. I'd like those items to be in an area where Core team and the Sys. Engineer (me) and the Project Scientist (or Science Team rep) can sign off and make sure the listed information correctly reflects the current, running Science Console. This will serve as a single-point reference that anyone on the team can check when they want to know the current operational parameters, and Core team will know where to submit changes when they are instituting a change in the Console or user accounts.

The information can be separate pieces, like a table for the instances, a separate table listing types of available storage, etc. Documentation could grab whatever table was needed for that part of the document. The User Resource Allotment document could grab the same info. Troy and were planning to meet and discuss how this might work after Busy Week, I believe.