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

Manual Gating #163

Closed
aackerman opened this issue May 2, 2019 · 7 comments · Fixed by #251
Closed

Manual Gating #163

aackerman opened this issue May 2, 2019 · 7 comments · Fixed by #251
Labels
kind/feature Feature request

Comments

@aackerman
Copy link
Contributor

I discussed on slack with @stefanprodan the possibility of manual gating.

He mentioned that the feature could be created with new webhooks, flagger could send out a webhook call for external step approval, pre/during/post, and if the webhook returns a 200, then the step would be approved to move forward otherwise the the canary would be halted

@mumoshu
Copy link
Contributor

mumoshu commented Jul 11, 2019

I was thinking about this as well.

What seems complicated when implemented with a webhook server, is that you'll likely need a unique webhook endpoint per deployment.

Perhaps we could create a generic webhook server that serves:

  1. POST /gates/${gate_id}/ to be used as a unique webook endopint per canary deployment
  2. POST /gates to create a new gate. This endpoint would be called from within your CI/CD pipeline or your GitHub/Slack webhook server to trigger manual approvals.

A unique webhook endpoint could be used from Flagger's pre-rollout webhook to postpone/start canary rollout with manual gating, for example.

He mentioned that the feature could be created with new webhooks

Does this mean new webhook types other than listed in https://docs.flagger.app/how-it-works#webhooks need to be added to flagger?

@stefanprodan
Copy link
Member

stefanprodan commented Jul 11, 2019

I think we could have dedicated webhook types for manual gating. I see two possible types: confirm-rollout (delay analysis until POST /gates/start/{canary.namespace} returns 200) and confirm-promotion (delay promotion until POST /gates/promote/{canary.namespace} returns 200)

PS. I’m on vacation till 22 July

@stefanprodan stefanprodan added the kind/feature Feature request label Jul 12, 2019
@mumoshu
Copy link
Contributor

mumoshu commented Jul 24, 2019

@stefanprodan Thanks for the response!

From Flagger's perspective, you'll be able to use whatever path to send webhooks to(i.e. /gates/start/{canary.namespace} is just an example and not hard-coded), right?

I'd like Flagger to work like that so that we can generate whatever URLs with Helm and integrate it with any http server.

FWIW, I'll be using paths like /gates/start/pr/<PR NUMBER> which starts returning 200 once I comment on the PR with /start, and set the PR number to be included in the webhook url via a helm chart value.

@stefanprodan
Copy link
Member

stefanprodan commented Jul 24, 2019

@mumoshu with #251 you can set whatever URL you want for the confirm-rollout webhook. Flagger will do a HTTP POST and if the call returns HTTP 200, will proceed with the analysis.

The HTTP POST body is the same as with every hook:

{
    "name": "podinfo",
    "namespace": "test",
    "phase": "Progressing"
}

@mumoshu
Copy link
Contributor

mumoshu commented Jul 24, 2019

@stefanprodan Just reviewed #251 - looks AWESOME. That's exactly what I wanted. Thanks a lot for your effort!

@stefanprodan
Copy link
Member

@mumoshu if the PR looks ok can you please approve it in the GitHub UI? Thanks

@mumoshu
Copy link
Contributor

mumoshu commented Jul 24, 2019

@stefanprodan Approved 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants