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

Skaffold remoteManifests doesn't work as documented #2160

Closed
gbird3 opened this issue May 21, 2019 · 3 comments
Closed

Skaffold remoteManifests doesn't work as documented #2160

gbird3 opened this issue May 21, 2019 · 3 comments
Labels
area/deploy deploy/kubectl help wanted We would love to have this done, but don't have the bandwidth, need help from contributors kind/bug Something isn't working priority/p1 High impact feature/bug.

Comments

@gbird3
Copy link

gbird3 commented May 21, 2019

Expected behavior

Adding remoteManifests to the skaffold.yaml should allow you to replace an already deployed k8s resource with the locally built version.

Actual behavior

Skaffold doesn't use the remoteManifests section in the yaml and instead just looks for the manifests in the default k8s/*.yaml location.

Information

This feature would be critical for us to start using skaffold. We currently keep all of our kubernetes manifests in a central repo with custom code to help deploy to our different environements. As such, for development, our developers already have the resources deployed in the cluster and we just want to update that.

On slack it was pointed out that this code was removed in this PR: #1451

  • Skaffold version: v0.29.0
  • Operating system: MacOS
  • Contents of skaffold.yaml:
apiVersion: skaffold/v1beta11
kind: Config
build:
  artifacts:
  - image: docker.joltup.com/jolt/api
    docker:
      dockerfile: Dockerfile-local
    sync:
      manual:
        - src: 'src/**/*.js'
          dest: .
deploy:
  kubectl:
    remoteManifests:
    - default:deployment/api-server

Steps to reproduce the behavior

  1. Deploy your application to a Kubernetes cluster
  2. Use a skaffold yaml similar to above that uses remoteManifests instead of manifests
  3. Skaffold won't be able to use the pre-existing deployment
@dgageot dgageot added deploy/kubectl kind/bug Something isn't working labels May 27, 2019
@balopat
Copy link
Contributor

balopat commented Jun 5, 2019

Hi, thank you for opening this, this does look like a bug.

@balopat balopat added help wanted We would love to have this done, but don't have the bandwidth, need help from contributors priority/p1 High impact feature/bug. labels Jun 5, 2019
@tanner-bruce
Copy link
Contributor

We fixed this up and also updated the semantics of how the Delete function works on RemoteManifests to ensure it works correctly. Previously, after cancelling skaffold dev the image of the deployment would be left with the latest deployed tag, which then caused the next run of skaffold dev to no longer match that image, since the tags were off.

We made the initial run of KubeDeploy.Apply save the existing images with their tags, and then the Cleanup method references those images and reverts the deployments.

I'll clean up the code a bit and submit a PR.

tanner-bruce pushed a commit to tanner-bruce/skaffold that referenced this issue Jun 12, 2019
Fix remoteManifests
cdfd10a 
This commit address issue GoogleContainerTools#2160. Remote manifests in the config are
properly pulled again.

This also addresses another unmentioned issue: when using a remote
manifest with `skaffold dev`, the remote manifest will have its image
updated to include the new tag. When shutting down, the remote manifest
will be left the same, including the updated tag. This causes further
runs of `skaffold dev` to no longer match the image, and not update it
properly.

This is addressed by saving all of the images in the manifests found the
first time apply is ran, and then on cleanup replacing the images with
those initially found.
@tanner-bruce tanner-bruce mentioned this issue Jun 12, 2019
Merged
tanner-bruce pushed a commit to tanner-bruce/skaffold that referenced this issue Jun 12, 2019
Fix remoteManifests
6f3d880 
This commit address issue GoogleContainerTools#2160. Remote manifests in the config are
properly pulled again.

This also addresses another unmentioned issue: when using a remote
manifest with `skaffold dev`, the remote manifest will have its image
updated to include the new tag. When shutting down, the remote manifest
will be left the same, including the updated tag. This causes further
runs of `skaffold dev` to no longer match the image, and not update it
properly.

This is addressed by saving all of the images in the manifests found the
first time apply is ran, and then on cleanup replacing the images with
those initially found.
@balopat balopat added help wanted We would love to have this done, but don't have the bandwidth, need help from contributors and removed help wanted We would love to have this done, but don't have the bandwidth, need help from contributors labels Jul 2, 2019
tanner-bruce pushed a commit to tanner-bruce/skaffold that referenced this issue Jul 24, 2019
@tanner-bruce
Fix remoteManifests
fa210e9 
This commit address issue GoogleContainerTools#2160. Remote manifests in the config are
properly pulled again.

This also addresses another unmentioned issue: when using a remote
manifest with `skaffold dev`, the remote manifest will have its image
updated to include the new tag. When shutting down, the remote manifest
will be left the same, including the updated tag. This causes further
runs of `skaffold dev` to no longer match the image, and not update it
properly.

This is addressed by saving all of the images in the manifests found the
first time apply is ran, and then on cleanup replacing the images with
those initially found.
tanner-bruce added a commit to tanner-bruce/skaffold that referenced this issue Jul 24, 2019
@tanner-bruce
Fix remoteManifests
0f4959c 
This commit address issue GoogleContainerTools#2160. Remote manifests in the config are
properly pulled again.

This also addresses another unmentioned issue: when using a remote
manifest with `skaffold dev`, the remote manifest will have its image
updated to include the new tag. When shutting down, the remote manifest
will be left the same, including the updated tag. This causes further
runs of `skaffold dev` to no longer match the image, and not update it
properly.

This is addressed by saving all of the images in the manifests found the
first time apply is ran, and then on cleanup replacing the images with
those initially found.
@corneliusweig corneliusweig mentioned this issue Aug 1, 2019
Closed
tejal29 pushed a commit to tanner-bruce/skaffold that referenced this issue Aug 9, 2019
@tanner-bruce @tejal29
Fix remoteManifests
467c496 
This commit address issue GoogleContainerTools#2160. Remote manifests in the config are
properly pulled again.

This also addresses another unmentioned issue: when using a remote
manifest with `skaffold dev`, the remote manifest will have its image
updated to include the new tag. When shutting down, the remote manifest
will be left the same, including the updated tag. This causes further
runs of `skaffold dev` to no longer match the image, and not update it
properly.

This is addressed by saving all of the images in the manifests found the
first time apply is ran, and then on cleanup replacing the images with
those initially found.
@nkubala
Copy link
Contributor

nkubala commented Aug 13, 2019

I'm going to close this since I believe it was fixed through tanner-bruce@467c496. if anyone is still seeing this issue please feel free to reopen!

@nkubala nkubala closed this as completed Aug 13, 2019
@LeoDupont LeoDupont mentioned this issue Feb 28, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/deploy deploy/kubectl help wanted We would love to have this done, but don't have the bandwidth, need help from contributors kind/bug Something isn't working priority/p1 High impact feature/bug.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dgageot @balopat @nkubala @gbird3 @tanner-bruce