Allow syncing to be disabled

[danielhelfand]

Describe the problem/challenge you have

I would like to be able to disable syncing entirely for an App and only have that App updated by explicit request from a client.

Describe the solution you'd like

On the App spec, there should be some way to disable syncing for an App and then reconciliation only happens via a client request to kapp-controller.

apiVersion: kappctrl.k14s.io/v1alpha1
kind: App
metadata:
  name: simple-app
  namespace: default
spec:
  disableSyncPeriod: true
  serviceAccountName: default-ns-sa
  fetch:
  - git:
      url: https://github.com/k14s/k8s-simple-app-example
      ref: origin/develop
      subPath: config-step-2-template
  template:
  - ytt:
      inline:
        pathsFrom:
        - secretRef:
            name: simple-app-values
  deploy:
  - kapp: {}

[ewrenn8]

What is the use case for this? There is already a paused key in the app spec which will pause all future reconciliations.

reconciliation only happens via a client request to kapp-controller.

I'm not sure I understand this part fully. Do you mean there is some API exposed that a client can hit and trigger reconciliation? If so, I don't think we would want to do that as it would require both exposing kapp-controller to clients and would move away from declarative APIs.

[danielhelfand]

What is the use case for this? There is already a paused key in the app spec which will pause all future reconciliations.

The use case would be to have more control over when changes are deployed to the cluster (e.g. only during a CI/CD run). While pausing would allow for this to a certain extent, what would the workflow look like to do this?

I think it might be more intuitive to allow for users to turn off syncing such that the App is only updated in the event someone or automation through CI/CD runs kubectl apply or kapp deploy.

I'm not sure I understand this part fully. Do you mean there is some API exposed that a client can hit and trigger reconciliation? If so, I don't think we would want to do that as it would require both exposing kapp-controller to clients and would move away from declarative APIs.

By client I am just referring to kubectl, kapp, or other Kubernetes deployment tools.

[github-actions]

This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.

[praveenrewar]

Slack thread where this came up again.

[jorgemoralespou]

Making comments (from above thread) here as it's easier to read:

We have hundreds of Applications that we use for convenience to deploy things onto our Kubernetes clusters but that don't need further reconciliation as usage of the resources might be short in time, although the App and generated resources might live in the cluster for long (until a pruning process happens). Our biggest concern is that setting a high syncPeriod would still effectively put pressure on kapp-controller reconciliation check loop, and also that, in case of kapp-controller restart, apps would reconcile, and while there might be still hundreds of Apps living in the cluster, it might choke kapp-controller and prevent it from serving any new App deployed, as these Apps can be deployed at any given time into the cluster.

We would want a way to do the initial, one time only reconciliation and then don't try again, but not even be try-able by kapp-controller in any circumstance.

[praveenrewar]

@jorgemoralespou In another conversation, @100mik mentioned that @ThomasVitale uses kctrl dev when he doesn't want Apps to reconcile again. Would that be something that would be useful in your case?

[100mik]

Not sure what we are talking about here, but I am not sure if this was a production use case. Maybe I am misremembering.

That said, if we are talking about App resources here, I do not see any reason to not take that path if it fits.

[jorgemoralespou]

It does not, since this is declarative application of App resources, and not imperative via a CLI. What does kctrl dev do under the hood?

[praveenrewar]

It does not, since this is declarative application of App resources, and not imperative via a CLI.

Yeah, that's what I had thought as well. It won't be much helpful in that case.

What does kctrl dev do under the hood?

It does the same thing that kapp-controller does, but in memory, so it doesn't even require kapp-controller to be installed.