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

Prepare OnCall for Unified Slack App #4232

Open
wants to merge 61 commits into
base: dev
Choose a base branch
from

Conversation

Konstantinov-Innokentii
Copy link
Member

@Konstantinov-Innokentii Konstantinov-Innokentii commented Apr 16, 2024

This PR does a bunch of changes to prepare OnCall for Unified Slack App:

  1. Install Slack via Chatops-Proxy. This change contains two parts: getting a Slack install link from chatops-proxy (code) and receiving a "slack installed" event from chatops-proxy (code). Also it means that OnCall doesn't need to register slack_links anymore when slack is connected/disconnected. These changes are behind UNIFIED_SLACK_APP_ENABLED flag and should be no-op if flag is not enabled.
  2. Get rid of Multiregionatily restrictions - instrument all slack interactions with a ProxyMeta - json data telling chatops-proxy where to route the interaction. Note, that it doesn't apply for "Add to resolution notes" message action - it will be handled differently in following PR.
  3. Move all chatops-proxy related stuff from common/oncall-gateway to apps/chatops-proxy

Minor changes:

  1. Remove usage of CHATOPS_V3 flag. Chatops v3 is already released (It's a refactoring from previous quarter)

engine/apps/slack/oauth.py Fixed Show fixed Hide fixed
Move slack installation & uninstallation code to separate functions to reuse betwen social-auth and chatops-proxy
…-install-multiple-responses' into handle_chatops_proxy_broadcast
Copy link
Collaborator

@matiasb matiasb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users will need to disconnect/reconnect Slack to switch to the unified app? Or is there any migration/transition plan?
There are a few data representation changes in the slack scenarios (e.g. schedules), could that break interaction with previously posted messages?
Also, it would be nice to add some tests for the chatops_proxy additions? (auth, handlers)

@@ -436,9 +437,9 @@ def _alert_group_action_value(self, **kwargs):

data = {
"organization_id": self.alert_group.channel.organization_id,
"alert_group_pk": self.alert_group.pk,
# eventually replace using alert_group_pk with alert_group_public_pk in slack payload
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this comment can be removed now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, guess so

@@ -32,6 +33,15 @@ class Tenant:
msteams_links: List[MSTeamsLink] = field(default_factory=list)


@dataclass
class OauthInstallation:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but maybe this should be OAuthInstallation? (OAuth is shoft for "Open Authorization")

) -> tuple[Tenant, requests.models.Response]:
url = f"{self.api_base_url}/tenants/register"
d = {
"tenant": {
"service_tenant_id": service_tenant_id,
"cluster_slug": cluster_slug,
"service_type": service_type,
"stack_id": stack_id,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this value backfilled/updated somehow for already registered tenants?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be. Probably I'll add a new endpoint on ChatopsProxy, allowing to PUT tenants and set their stack ids.
Currently it will be just ignored by ChatopsProxy, since new API is not released yet.

f"msg=\"ChatopsEventsHandler: Found matching handler {h.__name__}\" event_type={event_data.get('event_type')}"
)
h.handle(event_data.get("data", {}))
break
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could log if we got an event but there is no match?

@shared_dedicated_queue_retry_task(
autoretry_for=(Exception,),
retry_backoff=True,
max_retries=100,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to have 100 retries, or 10 should be the same for this purpose?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea behind 100 retries is to make sure we didn't miss any OnCall org creation. Initially it was endless, but me and @vadimkerr decided to make it some finite number.

@Konstantinov-Innokentii
Copy link
Member Author

Konstantinov-Innokentii commented May 23, 2024

Users will need to disconnect/reconnect Slack to switch to the unified app? Or is there any migration/transition plan? There are a few data representation changes in the Slack scenarios (e.g., schedules); could that break interaction with previously posted messages? Also, it would be nice to add some tests for the chatops_proxy additions. (auth, handlers)

  1. To fully switch to unified app users must reconnect the app to submit new permissions. It will be same app, under different name and I'm planning to introduce "soft-reinstall" to not to disconnect anything. Readon behind that is that Incident has some permissions we don't. However, OnCall parts should still work. There is no migration plan yet, I'll start to work on that once work on Unified App itself will be done.
  2. Data representation changes should be fully compatible with old messages. @vadimkerr just pinging to confirm that.
  3. I'll add some tests. Didn't got the point about auth tests? What auth are u referring to?

Copy link
Collaborator

@matiasb matiasb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates! 👍
LGTM

"payload": {
# It's not actual payload we are getting from slack, just a placeholder
"slack_id"
"some_slack_id"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this sample data ok ^?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noticing. missed a coma. Anyway, I went ahead and used a more accurate payload example from slack docs instead of placeholder

@Konstantinov-Innokentii
Copy link
Member Author

Thanks for the updates! 👍 LGTM

Thanks! Added more tests covering our slack installation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:no public docs Added to a PR that does not require public documentation updates release:ignore PR will not be added to release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants