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

Updates of workloads due to ConfigMap changes #97

Closed
viglesiasce opened this issue Feb 22, 2018 · 9 comments
Closed

Updates of workloads due to ConfigMap changes #97

viglesiasce opened this issue Feb 22, 2018 · 9 comments
Labels
area/deploy kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@viglesiasce
Copy link
Contributor

When a ConfigMap manifest is updated, users may want that to automatically update the workload that it references. Unfortunately the deployment will only update if the configmap name or any other field changes in the spec.

@r2d4
Copy link
Contributor

r2d4 commented Feb 23, 2018

ref #98

@dlorenc
Copy link
Contributor

dlorenc commented Jul 2, 2018

When updating config maps, we would have to track all entities that reference the config map and trigger a restart of all of those.

@balopat balopat added the priority/p3 agreed that this would be good to have, but no one is available at the moment. label Aug 21, 2018
@lucperkins
Copy link

lucperkins commented Aug 31, 2018

Having changes to a config file trigger changes to the appropriate ConfigMap, Deployment, etc. would be fantastic, but probably difficult to implement and more suited for a release further down the line. In the short term, however, I think it would be extremely helpful to be able to define configs even without auto-updating. Something like this:

apiVersion: skaffold/v1alpha2
kind: Config
build:
  tagPolicy:
    sha256: {}
  local: {}
  artifacts:
  - imageName: my-app
    bazel:
      target: //:my-app.tar
  configs:
  - configMapName: prometheus-config
    file: config/prometheus.yml
  - configMapName: nginx-config
    file: config/nginx.conf
  - configMapName: my-arbitrary-config
    args:
      foo: bar
      baq: baz

Even if this only created the ConfigMaps at the beginning and didn't watch them for changes, it would be a big win for a lot of use cases. As it stands, the config file thing is pretty much the only thing that keeps Skaffold from being a "one-command" solution to a thorny problem.

@demisx
Copy link
Contributor

demisx commented May 24, 2019

Currently, if I change a value in a config map, skaffold (v0.30) does neither rebuild/apply the updated value. I have to restart it manually for new values to take effect. Is this related to this issue (or kubernetes/kubernetes#22368) or is there something wrong with my skaffold configuration? I've confirmed that I am not manually syncing my k8s/ folder.

@lucperkins
Copy link

lucperkins commented May 24, 2019

@demisx The issue is still open. Skaffold does not yet support this desired behavior. As far as I know Skaffold doesn’t handle ConfigMaps at all.

@demisx
Copy link
Contributor

demisx commented May 24, 2019

@lucperkins Got it. Sorry, I wasn't sure if this was the issue I was experiencing or not. I'll be watching!

@vaidik
Copy link

vaidik commented Jun 25, 2019

Configmaps get updated but not the deployments referencing them.

@tstromberg
Copy link
Contributor

I'm closing this issue as it hasn't seen activity in awhile, and if it does still exist, it doesn't seem to be getting any traction at the moment. If this issue appears in the most recent release of Skaffold, please feel free to add a follow-up comment and we will see about getting it prioritized appropriately.

If someone sees a similar issue to this one, please create a new issue, but do include a link to this issue if possible.

Thank you for sharing this issue with us!

@JasonMan34
Copy link

This is quite a hassle when working with many services locally
I'm working on a repo with 55 deployments, having to re-launch all of them because I changed the configmap of one is.. less than optimal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/deploy kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
Development

No branches or pull requests

9 participants