New group-level network stanza ports not detected by the service stanza

[jsardev]

Nomad version

Nomad v0.12.3

Operating system and Environment details

Mac OSX Catalina

Issue

I tried to use the new group-level network stanza for allocating ports (instead of task -> resources -> network level), but unfortunately those ports can't be used in the task-level service stanza.

Also, shouldn't the docker-attached port being forwarded to the container's EXPOSE port? Because when I remove the port { to } directive, then nomad will forward the host port to the same port on the container (even if it EXPOSES the 80 port).

Reproduction steps

Run the below job file - it will fail with an error:

Error submitting job: Unexpected response code: 500 (1 error occurred:
	* Task group app1 validation failed: 1 error occurred:
	* Task app1 validation failed: 1 error occurred:
	* 1 error occurred:
	* port label "http" referenced by services app1-app1-app1 does not exist
)

Job file (if appropriate)

job "app1" {
  datacenters = ["dc1"]

  group "app1" {
    network {
      port "http" {
        to = 80
      }
    }

    task "app1" {
      driver = "docker"

      config {
        image = "nginx"
        ports = ["http"]
      }

      service {
        check {
          type     = "tcp"
          port     = "http"
          interval = "10s"
          timeout  = "2s"
        }
      }

    }
  }
}

[nickethier]

Hey @sarneeh I've got a fix pending for this in #8743

For now the workaround is to use the deprecated syntax. Sorry for the inconvenience, we'll get this merged soon.

Thanks.

[jsardev]

@nickethier Thank you! 🙇

[Legogris]

@sarneeh If you don't mind, what's your reason for wanting to keep the service under task and not move that to group as well? Just thinking why that wouldn't be a preferred workaround over using deprecated syntax.

[jsardev]

@Legogris Honestly? I just followed examples from the docs 😄 But I guess the rule of thumb is that if a job consists of just 1 group with 1 task, I'd rather put the service stanza in the task.

[dominhhai]

Any progress here?

[dnrce]

Current support aside, is putting service in the group recommended over putting it in the task? The docs don't make the choice clear.

[gmichalec-pandora]

Just to be clear, is the plan to allow a service defined in a task to be able to access port labels defined at the group level? Or is the recommendation to move service definitions that require port labels to the group level? If the former, would that be just a temporary fix until the old syntax is fully deprecated, or will that supported moving forward. I'm just trying to determine how best to advise our users to update their specs - rearranging all the service definitions in 1000s of hcls will be a bit of an undertaking :)

[kaspergrubbe]

@gmichalec-pandora 1000s jobs? I feel your pain! I've asked about the docs and deprecation to be improved here: #9292 so I guess it's related to this issue as well.

[nickethier]

Hey folks, sorry this issue has waned I plan to pick it up this week.

I would recommend using group service blocks where you can (which should be in most cases). Most new service features (connect) only work with group service blocks.

[shantanugadgil]

As a general help, would it be possible to mention (in docs) which specific features/syntax need connect enabled?

i.e. will the new group level syntax work without the Connect enabled?

[nickethier]

Connect is an entirely separate feature that is enabled by 1) group bridge network mode and 2) group service block with a sidecar_service inner block. So a group service works independently from and is what enables connect, not the other way around.

I'll try to find a good place to call it out.

[m1keil]

@Legogris Honestly? I just followed examples from the docs 😄 But I guess the rule of thumb is that if a job consists of just 1 group with 1 task, I'd rather put the service stanza in the task.

Exactly my situation as well. I was just testing the latest nomad versions and copying examples from docs.

[gmichalec-pandora]

It might be clearer if service definitions were only valid at the group level, but allowing them at either seems confusing. I can certainly understand the arguments for putting service definitions at the allocation (group) level, but, given the choice, it does make more sense to me to associate a service with a task - it's not the group that is listening on those ports, but the application running in the task.

[github-actions]

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.