Expand user stories for AmSC-IRO functionalities

[xi-yang]

Added detailed user stories supporting AmSC Infrastructure Resource Orchestration functionalities, including Resource Information Model and job submission processes.

[bjoernenders]

These aren't user stories but a list of requirements the interfaces need to report. If you want to phrase it more as a user story then it has to capture intend and how the information is interpreted to make a decision.

I don't know what this means:

• Compute Job Management resources information, including
  • membership with clusters or resource groups (if multiple clusters or resource groups)
  • capabilities (per-cluster or resource group)
  • aggregate availability (per-cluster or resource group)
    Like that job is a member of cluster/resoruce groups? Also aggregate availability is what exactly?

and what is your intent with these:

• IRI Facility File System resources information, including
  • membership with clusters or resource groups (if multiple clusters or resource groups)
• capabilities (per-cluster or resource group)
• network mountable volumes and sizes (per-cluster or resource group)
  Is this per user? or just global values?

I'm not going to expand on the last. This "user story" has a fairly fixed mental model.

A user story would be more like: "User X just wants to run a job X, the job is bla, the data for this job is at facility X, the user doesn't care where the job is run but needs the data to be colocated with the job"

[xi-yang]

@bjoernenders In case you haven't seen my message in Slack, I copied it here.

I want to point out that, with AmSC, we do not only have the end customers but also middleware services as the IRI API users. We do not only consider “job submission related” functions but also “resource information modeling” functions. For the latter, the AmSC-IRO (orchestrator) is “the user” and the information describing how compute, storage and network resources are related each other is a “use story” on its own. Who and how those provided resource information will be used by the AmSC-IRO for the end customers is may not be relevant here. But if we have to talk about that, the above example should provide some context.

AmSC has a huge dependency on what we are doing here. If this "fairly fixed mental model" does not help, it has less value to meet the AmSC requirements. If you don't believe the "user stories" is the right place to intake those requirements, you (and also @jmacauley @pmrich @gabor-lbl) may suggest other channels.