Chatops
Description
To achieve chatops through GitLab, the integration points and depth we can provide out of the box is not sufficient. You should be able to manage access, users, rights, VMs, containers, clusters etc etc.
Yet, we believe (and have learned internally) that there is a need for something that is maintained easily as part of GitLab, yet still provides the same depth of customization and power.
To do this, we need to be able to provide support for custom scripts that can be used by our Chatops commands. We can do this through executing these scripts on a Runner.
Because we'll be creating this from our own need and the fact that Cog is not being developed further. Feedback from our own team is vital here.
Would love to get your feedback @pcarranza and team.
Proposal
To be discussed, some ideas:
- Chatops scripts can be included in a repository under
.gitlab/ - follow a similar pattern / same to the
.gitlab-ci.yml. or use the cog style? - They should be able to use (protected) variables
- How would we do relays? Can we use runners for this?
Questions
- how to execute these?
- SOLVED
is a bot necessary? or do slash commands suffice?Slash commands should suffice. Build on top of existing functionality
Links / references
Documentation blurb
Overview
What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?
Use cases
Who is this for? Provide one or more use cases.
Feature checklist
Make sure these are completed before closing the issue, with a link to the relevant commit.
- Feature assurance
- Documentation
- Added to features.yml
Others-built bundles (features) used by production team
| Bundle | Usage | Potential alternative |
|---|---|---|
| Tweet status updates during deployments, unplanned outages, and other maintenance operations | Use a Slack app, such as BirdyBot | |
| PagerDuty | PagerDuty | Use direct Slack-PagerDuty integration |
| net | ? | ? |
| format | ? | ? |
| consul | ? | ? |
| operable | Manage Cog itself | Not applicable |
Custom-built bundles (features) used by production team
| Bundle | Usage | Potential alternative |
|---|---|---|
| gitlab-admin (new features blocked) | Admin gitlab.com | - |
| chef (blocked) | - | - |
| postgres (blocked) | Run read-only ad-hoc queries on gitlab.com's database | Connect to production database safely in another way. Stream production database updates to another database in near-real time. |
| swat/swat-staging (blocked) | Run Rails console scripts on GitLab.com without directly logging in | - |
| otp (currently blocked) | - | - |
| ceph (currently blocked) | - | - |
| Any future functionality | We need a way to create flexible functionality on top of a platform, and be able to deploy it immediately. It should be de-coupled from monthly releases. | A platform solution |
Other requirements
| Requirement | Cog-based design | Potential alternative |
|---|---|---|
| Fine-grained roles and permissions management allows certain users to do certain production tasks. | Fine-grained permissions system in Cog | Integrate with GitLab using not-yet-implemented custom roles. |
| ChatOps when GitLab.com is down | Cog bundles | Separate GitLab instance (not GitLab.com) or Runners that interacts with GitLab.com |
| Audit log of commands to investigate and retro on incidents | Stored in Cog bundles | Expanding the audit log view in GitLab to support ChatOps |
Piping multiple commands together (typically implemented with vertical bar character so that you can easily create scripts |
Cog supports piping | Depends on solution |
Current proposed design / implementation plan
- Create a ChatOps platform solution that we can ship with GitLab, probably inside Omnibus.
- The platform solution should allow GitLab "production support" users to do ChatOps without relying on other tools. These are users who deploy GitLab at the infrastructure level. (Note this applies to external customers and our own GitLab production team.)
- The platform solution should integrate with Slack as a high priority. Potentially other chat clients in the future.
- Create a migration strategy to move GitLab production team needs and GitLab release manager needs from the existing Cog-based solution to the new integrated-in-Omnibus solution.
- To speed up migration and minimize re-work, the platform solution should be developed such that the existing custom-built Cog bundles can be easily converted to the new GitLab-Omnibus-based "bundles". Using JSON has been proposed to aid in this effort.