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.

Sign up for GitHub

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

Jump to bottom

RFC: Inert deployments #14516

Closed
ironcladlou opened this issue Sep 24, 2015 · 9 comments
Closed

RFC: Inert deployments #14516

ironcladlou opened this issue Sep 24, 2015 · 9 comments
Labels
area/app-lifecycle priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone
v1.2

Comments

@ironcladlou
Copy link
Contributor

The deployment design (#1743) implicitly supports a deployment triggering use case known as "config change triggering" in OpenShift: when a new deployment state is observed, the cluster works to realize the new state as soon as possible. There is one functional gap in this design: users sometimes need to temporarily disable a deployment. This could be accomplished by allowing deployments to be "inert". Some uses for inert deployments:

  • Provides a way for the deployment to exist in the system awaiting external human processes/validations
  • Provides a safe way to prepare a deployment resource without iterative changes being rolled out
  • A safety switch to prevent a deployment which you don't want to happen

Technically these use cases are satisfied by simply deleting the deployment resource and recreating it when ready, but that places a burden on the user to preserve the old state until it's ready to be recreated.
@ironcladlou
Copy link
Contributor Author

cc @smarterclayton @nikhiljindal @ghodss @bgrant0607

@smarterclayton
Copy link
Contributor

If a deployment is inert, it would be desirable to do exactly one rev of the controller loop for that deployment - i.e. "PUT /deployments/foo/instantiate". That covers the use case of "I don't want automatic deployments, I want them automatic when I trigger"

@ironcladlou ironcladlou mentioned this issue Sep 24, 2015
Closed
@bgrant0607 bgrant0607 added priority/backlog Higher priority than priority/awaiting-more-evidence. area/app-lifecycle team/ux labels Sep 24, 2015
@pmorie
Copy link
Member

pmorie commented Sep 25, 2015

It's not obvious to me what this has to do specifically with config change triggering.

@ironcladlou
Copy link
Contributor Author

It's not obvious to me what this has to do specifically with config change triggering.

Inert deployments combined with the inherent design of the deployment controller seem to provide config change trigger functionality without needing to introduce the concept of a "config change trigger" as defined in OpenShift.

@bgrant0607 bgrant0607 added this to the v1.2-candidate milestone Nov 12, 2015
@bgrant0607 bgrant0607 modified the milestones: v1.2-candidate, v1.2 Nov 19, 2015
@0xmichalis
Copy link
Contributor

Related: #7242

@bgrant0607 bgrant0607 added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed priority/backlog Higher priority than priority/awaiting-more-evidence. labels Dec 1, 2015
@0xmichalis
Copy link
Contributor

A couple of questions:

  • Is this work for a separate controller or do we think the main one is enough? If the former, then it's as simple as a condition in the spec (and a 2nd controller:) ). If the latter and we do a reconcilation per "PUT /deployments/foo/instantiate", how should the controller recognize that the deployment it is processing is actually inert and that it shouldn't try to reconcile it again without re-triggering? I am envisioning still a condition - a bool pointer (any proposed names? - nil would mean always reconcile, true: ignore, false: reconcile once). The controller would have to invalidate (set to true) non-nil conditions in the end of the reconcilation process. I think I prefer the latter.
  • Where should we have "PUT /deployments/foo/instantiate" under? kubectl rollout?

@0xmichalis
Copy link
Contributor

Should "PUT /deployments/foo/instantiate" work only on inert or in every deployment? I would guess the latter.

@smarterclayton
Copy link
Contributor

I believe every is correct - It would simply be a no-op if the deployment
was not inert (or if the deployment already fired)

On Fri, Dec 18, 2015 at 11:42 AM, Michail Kargakis <notifications@github.com

wrote:

Should "PUT /deployments/foo/instantiate" work only on inert or in every
deployment? I would guess the latter.

—
Reply to this email directly or view it on GitHub
#14516 (comment)
.

@0xmichalis 0xmichalis mentioned this issue Dec 18, 2015
Merged
@pmorie
Copy link
Member

pmorie commented Dec 18, 2015

@ironcladlou

It's not obvious to me what this has to do specifically with config change triggering.

Now it's obvious. lol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/app-lifecycle priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Milestone
v1.2
Development

No branches or pull requests
5 participants
@ironcladlou @pmorie @smarterclayton @0xmichalis @bgrant0607