Adding contact information to status.yml

[whoamnick]

Hi Steve,

Wondering about your thoughts on adding a contact mailbox or pager number to the status.yml in order to support alerts.

Right now I see a few options here;

• We could have contact information per whole status.yml file, and support multiple status.yml files where the information is applied at build or runtime.
• Contact information per error, which seems like it would be a fair bit of overhead when teams are building out..

What do you think? This seems like it's becoming an urgent issue on our end

[stevehu]

Contact per error code is a little overkill. Per file makes sense. I was also thinking to add a link which is pointing to light-portal with more explanations. We definitely need to support multiple files and there is a light-bot task @ddobrin is working on. Let's discuss it here to sort out the details.

[ddobrin]

We have discussed the link to the portal for an "explanation" of the different statuses.
It will make a lot of sense to allow each API, with its own runbook, to have a link to the runbook, or a link where the statuses provide more information.

This link needs to be set on the final version of the status.yml, the version which gets built into the API.

There are statuses being merged from multiple locations:

1. light-4j
2. XCCs from a specific domain
3. the actual API

Now, as the "aggregation" of the multiple files will be done via light-bot, we need to agree where we wish to have a link. I suggest that we do it on the status.yml in light-4j, with the understanding that this location will be updated by DevOps teams at the time of deployment to Production.

[ddobrin]

@NicholasAzar , @chenyan71 :
Steve and I have discussed this yesterday and here's our thinking at this time:

• each API has a yml file for its own configuration
• this yml file can be generated by the light-codegen
• the file will be provisioned with a link to the location of the **more detailed explanation ** of the statuses.
• the link will be updated by DevOps teams for Prod and non-Prod environments
• the status file, which is aggregated for each API, as mentioned in this trail, will remain limited to statuses, and their description, severity, message.

If all of you guys agree, I'll create the appropriate issue in light-codegen, light-bot has its issue already and there is this issue listed here.