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

Cannot set Docker labels for sidecar tasks #7991

Closed
akhayyat opened this issue May 17, 2020 · 4 comments
Closed

Cannot set Docker labels for sidecar tasks #7991

akhayyat opened this issue May 17, 2020 · 4 comments
Assignees
Milestone

Comments

@akhayyat
Copy link

Nomad version

Nomad v0.11.1 (b434570)

Operating system and Environment details

Debian 10.3

Issue

Setting Docker labels for sidecar_task has no effect. The envoy sidecar containers do not have the configured labels. Docker labels work fine on normal tasks.

Reproduction steps

Run a Docker job with some Docker labels defined under service.connect.sidecar_task.config.labels. See below for an example.

Job file (if appropriate)

job "echo" {
  datacenters = ["test"]
  group "echo" {
    network {
      mode = "bridge"
      port "http" {
        static = 8080
        to = 8080
      }
    }
    service {
      name = "echo"
      port = 8080
      connect {
        sidecar_service {}
        sidecar_task {
          config {
            labels {
              nomad_job = "${NOMAD_JOB_NAME}"
              nomad_group = "${NOMAD_GROUP_NAME}"
            }
          }
        }
      }
    }
    task "echo" {
      user = 65534
      driver = "docker"
      config {
        image = "hashicorp/http-echo"
        args = [
          "-listen",
          ":8080",
          "-text",
          "hello world"
        ]
      }
      resources {
        memory = 10
      }
    }
  }
}

Nomad Client logs (if appropriate)

Nothing special.

@akhayyat
Copy link
Author

So, after a while (hours), labels started to show up in the output of docker inspect!

Now, when I changed the labels, stopped the job, then ran it again, I still kept seeing the old labels.

Are the sidecar task custom labels cached, perhaps?

@shoenig
Copy link
Member

shoenig commented May 18, 2020

Thanks for reporting @akhayyat ! At first guess, I suspect we're not properly identifying when the opaque sidecar_task.config block is being modified, which should trigger a destructive update for the allocation.

@shoenig shoenig self-assigned this Oct 5, 2020
shoenig added a commit that referenced this issue Oct 5, 2020
This PR fixes a long standing bug where submitting jobs with changes
to connect services would not trigger updates as expected. Previously,
service blocks were not considered as sources of destructive updates
since they could be synced with consul non-destructively. With Connect,
task group services that have changes to their connect block or to
the service port should be destructive, since the network plumbing of
the alloc is going to need updating.

Fixes #8596 #7991

Non-destructive half in #7192
shoenig added a commit that referenced this issue Oct 5, 2020
This PR fixes a long standing bug where submitting jobs with changes
to connect services would not trigger updates as expected. Previously,
service blocks were not considered as sources of destructive updates
since they could be synced with consul non-destructively. With Connect,
task group services that have changes to their connect block or to
the service port should be destructive, since the network plumbing of
the alloc is going to need updating.

Fixes #8596 #7991

Non-destructive half in #7192
shoenig added a commit that referenced this issue Oct 5, 2020
This PR fixes a long standing bug where submitting jobs with changes
to connect services would not trigger updates as expected. Previously,
service blocks were not considered as sources of destructive updates
since they could be synced with consul non-destructively. With Connect,
task group services that have changes to their connect block or to
the service port should be destructive, since the network plumbing of
the alloc is going to need updating.

Fixes #8596 #7991

Non-destructive half in #7192
fredrikhgrelland pushed a commit to fredrikhgrelland/nomad that referenced this issue Oct 22, 2020
This PR fixes a long standing bug where submitting jobs with changes
to connect services would not trigger updates as expected. Previously,
service blocks were not considered as sources of destructive updates
since they could be synced with consul non-destructively. With Connect,
task group services that have changes to their connect block or to
the service port should be destructive, since the network plumbing of
the alloc is going to need updating.

Fixes hashicorp#8596 hashicorp#7991

Non-destructive half in hashicorp#7192
@tgross
Copy link
Member

tgross commented Dec 16, 2020

Closed by #9029 and shipped in 1.0.0

@tgross tgross closed this as completed Dec 16, 2020
Nomad - Community Issues Triage automation moved this from Needs Triage to Done Dec 16, 2020
@tgross tgross added this to the 1.0 milestone Dec 16, 2020
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants