Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding contact information to status.yml #293

Open
DSchrupert opened this issue Sep 19, 2018 · 3 comments
Open

Adding contact information to status.yml #293

DSchrupert opened this issue Sep 19, 2018 · 3 comments
Assignees
Labels
enhancement Issue: Enhancement help wanted Issue: Help Wanted

Comments

@DSchrupert
Copy link
Member

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
Copy link
Contributor

stevehu commented Sep 19, 2018

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
Copy link
Contributor

ddobrin commented Sep 19, 2018

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
Copy link
Contributor

ddobrin commented Sep 21, 2018

@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.

@stevehu stevehu added enhancement Issue: Enhancement help wanted Issue: Help Wanted labels Feb 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issue: Enhancement help wanted Issue: Help Wanted
Projects
None yet
Development

No branches or pull requests

4 participants