configuration management / monitoring

[pnispero]

configuration management / monitoring

This description is tentative, still thinking about what exactly were going to implement For pushing to production, we want this global configuration list for everything. For IOC apps, it'd be similar to cram ls, but written out in a list. And this list will be used by ansible configuration management. Expectation vs reality comparison for confirmation. Essentially its a list of what I want deployed, and ansible can deploy that and check that its there. And the end-goal is to get rid of write permissions on the production release directories to prevent any unchecked changes/fixes on prod, any new changes/fixes should be a new deployment not done manually.

But for dev, we still want user to specify in CLI.

[pnispero]

Update

Researching

• look into logging techs, although may be just through backend since it tocuhes most of the steps promethius grafana - loki look into kubernetes if they have their own

Another thing to tackle

• beef up backend to do issue management (annotations on issues/pull requests, etc). We may want to extract this logic out of the backend, or keep backend the way it is and get invested in learning the codebase

look into how we implement

• Preferred bug tracking system
• How similar the APIs are for Jira and Github Issues
  • TEMP: Both JIRA and Github issues can use OAuth for authentication for clients using their rest API's. For JIRA, OAuth is recommended through JIRA apps or OAuth standalone. For Github, we already have our ad-build-test organization authrozied the core-build-system backend as a Github App which utilizes OAuth.
  • JIRA documentation for OAuth apps: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/
  • JIRA Rest API: https://docs.atlassian.com/software/jira/docs/api/REST/4.4.5/#resources
  • JIRA types of 'apps' you can build to access the API: https://developer.atlassian.com/developer-guide/cloud-development-options/