Service Connect Upstream stanza doesn't match service definition in consul

[Ilhicas]

Nomad version

Nomad v1.0.3 (08741d9)

Consul Agent Version

consul.version | 1.9.3
consul.revision | f55da9306

Operating system and Environment details

Amazon EC2 Linux

Issue

Declaring a service stanza in nomad with consul service struct attribute for local_bind_address results in declaring an unknown attribute.

Reproduction steps

Set consul service definition as

This is a consul definition, not to be confused by Service Stanza in Nomad

services {
  name = "client"
  port = 8080

  connect {
    sidecar_service {
      proxy {
        upstreams {
          destination_name   = "echo"
          local_bind_address = "127.0.0.2"
          local_bind_port    = 9191
        }
      }
    }
  }
}

services {
  name = "echo"
  port = 9090

  connect {
    sidecar_service {}
  }
}

All is correctly configured in consul side

Job file (if appropriate)

Set the following in nomad service stanza and will result in attribute not found

...
service {
  name = "client"
  port = 8080

  connect {
    sidecar_service {
      proxy {
        upstreams {
          destination_name   = "echo"
          local_bind_address = "127.0.0.2"
          local_bind_port    = 9191
        }
      }
    }
  }
}
... omitted for brevity

Nomad Client logs (if appropriate)

Unsupported argument; An argument named "local_bind_address" is not expected here.

[tgross]

Hi @Ilhicas! If I look at the upstreams documentation, I don't see local_bind_address in the listed configuration options. So that validation is working as expected.

Also, it's not super clear to me what the difference you're intending to show between those two jobspecs... but the first one has services rather than the valid service, so I'd expect the first one to fail validation as well.

[Ilhicas]

Hi @Ilhicas! If I look at the upstreams documentation, I don't see local_bind_address in the listed configuration options. So that validation is working as expected.

Also, it's not super clear to me what the difference you're intending to show between those two jobspecs... but the first one has services rather than the valid service, so I'd expect the first one to fail validation as well.

Hello @tgross , what I'm saying is that consul services declaration is not matched by the one in Nomad service stanza.

From consul docs: https://www.consul.io/api-docs/agent/service

Proxy.Upstreams.LocalBindAddress

[tgross]

Yup, it's not yet supported. See #6248. Going to close this issue as a dupe, but if you give a 👍 reaction on that issue it'll help surface it for roadmapping.

[Ilhicas]

Yup I've seen that issue before 👍
Assumed it was stale

@tgross do you know if there are any plans to support it?
I can try to make a pull request for it as I'm currently in need of that feature, and would probably help other people in the way.

Do you see any reason for it not being supported as of yet? Something I might be missing and why it wasn't implemented yet.

I'm assuming that pr would be a lot similar to this:
#9472

[tgross]

Do you see any reason for it not being supported as of yet? Something I might be missing and why it wasn't implemented yet.

Just time and resources for the team. I'd be happy to review your PR if you're interested!

[paladin-devops]

I'm experiencing a similar issue and would really love this feature.

connect { sidecar_service { proxy { upstreams { destination_name = "prometheus-${job_env}" local_bind_port = 9090 local_bind_address = "prometheus-${job_env}.service.consul" } } } }

Deployment output:

» Deploying...
! Unexpected response code: 400 (input.hcl:68,15-33: Unsupported argument; An
argument named "local_bind_address" is not expected here.)

[Ilhicas]

Hi @paladin-devops this feature was added to 1.1.0 check the related issue that was merged.

[paladin-devops]

Thanks @Ilhicas , I looked at your PR and then only after the fact saw that it was already included in the 1.1.0 release (and then, moments later, 1.1.1 dropped earlier today :) ). Appreciate the contribution!

[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.