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

Nomad plan confused by multiple services with the same name. #10964

Closed
apollo13 opened this issue Jul 29, 2021 · 3 comments · Fixed by #10965
Closed

Nomad plan confused by multiple services with the same name. #10964

apollo13 opened this issue Jul 29, 2021 · 3 comments · Fixed by #10965
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. theme/consul theme/plan type/bug
Milestone

Comments

@apollo13
Copy link
Contributor

Nomad version

Nomad v1.1.2 (60638a0)

Operating system and Environment details

Not relevant

Issue

The output from plan is simply wrong, it conflates multiple services with the same name (please note that this is fine from a consul perspective and nomad itself does the "same" when registering multiple ports to the "nomad" service).

Reproduction steps

Deploy:

job "whoami-test" {
  datacenters = ["dc1"]

  group "whoami" {
    network {
      mode = "bridge"
      port "expose" {}
    }

    service {
      name = "whoami"
      port = 80
      tags = [
        "traefik.enable=true",
        "traefik.consulcatalog.connect=true",
        "traefik.http.routers.whoami.rule=Host(`whoami.example.com`)"
      ]

      connect {
        sidecar_service {}
      }
    }

    #service {
    #  name = "whoami"
    #  port = "expose"
    #  tags = ["test"]
    #}

    task "whoami" {
      driver = "docker"
      config {
        image = "containous/whoami"
      }
    }
  }
}

Uncommented the commented service and plan:

+/- Job: "whoami-test"
+/- Task Group: "whoami" (1 in-place update)
  +/- Service {
        AddressMode:       "auto"
        EnableTagOverride: "false"
        Name:              "whoami"
        Namespace:         "default"
        OnUpdate:          "require_healthy"
    +/- PortLabel:         "80" => "expose"
        TaskName:          ""
    +/- Tags {
      + Tags: "test"
      - Tags: "traefik.consulcatalog.connect=true"
      - Tags: "traefik.enable=true"
      - Tags: "traefik.http.routers.whoami.rule=Host(`whoami.example.com`)"
        }
    -   ConsulConnect {
        - Native: "false"
        - SidecarService {
          - DisableDefaultTCPCheck: "false"
            Port:                   ""
          }
        }
      }
      Task: "connect-proxy-whoami"
      Task: "whoami"

Scheduler dry-run:
- All tasks successfully allocated.

Job Modify Index: 919746
To submit the job with version verification run:

Actually deploy the planned version and observe the result:

curl https://consul.infra.bap.co.at/v1/catalog/service/whoami | jq

(or via the webui) You will see that nomad/consul properly created two instances for the service:
image

Expected Result

Nomad plan should properly differentiate between services with the same name

Actual Result

The last service in the nomad file seems to "win"

@apollo13
Copy link
Contributor Author

I have started working on a draft PR, not really sure what the best way to separate the services would be -- ideas welcome (currently I do name+portlabel)

@apollo13
Copy link
Contributor Author

I guess the main question about my PR is whether we can accept that a change in port label means "deletion & creation" of the service as opposed to a "change".

@shoenig shoenig added stage/accepted Confirmed, and intend to work on. No timeline committment though. theme/consul labels Jul 30, 2021
@shoenig shoenig added this to the 1.1.4 milestone Jul 30, 2021
@jrasell jrasell modified the milestones: 1.1.4, 1.2.0 Sep 2, 2021
@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 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
stage/accepted Confirmed, and intend to work on. No timeline committment though. theme/consul theme/plan type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants