Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Chris Johnson
    @chrisjohnson
    Why does the config entry specify a Port here? That port seems to be ignored
    The command to run the ingress proxy specifies its own port
    Port = 8080
    The command later is $ consul connect envoy -gateway=ingress -register -service ingress-service -address '{{ GetInterfaceIP "eth0" }}:8888'
    We tried to specify the port and omit -address and it seems to pick its own port instead of pulling from the config entry
    Blake Covarrubias
    @blake
    The port defined in -address is primarily used for Consul to health check the ingress gateway. The Port defined in the configuration entry is where Envoy will listen to accept connections from external clients.
    Chris Johnson
    @chrisjohnson
    It doesn't actually seem to behave that way in practice. I'll double check but we were seeing that the envoy proxy was listening on 443 (consul 1.8.3 -- prior to the change to 8443 by default) rather than the port defined in the ingress-gateway config entry
    And then when adding -address including port, the envoy proxy seemed to be listening on that port that was specified
    Blake Covarrubias
    @blake
    Is the port 8888 accepting web traffic? Does Envoy ever listen on port 8080?
    Chris Johnson
    @chrisjohnson
    I'll set up for a closer experiment and take closer notes
    Chris Johnson
    @chrisjohnson
    Ok here's what we are seeing, if we omit -address, envoy tries to listen on port 443 (from what I've read, in consul 1.9.x the new default is 8443)
    Regardless of what's in the config entry
    We can specify -address with the same port as what's in the config entry, and then it only listens on that port
    Or if we specify -address with a different port, it listens on both
    It's not clear why it's trying to listen on both
    If this is getting into github issue territory let me know. I'm just wondering if there's something obvious we are misunderstanding
    Blake Covarrubias
    @blake
    -address should only be used by Consul to health check the Envoy instance. AFAIK, that port is not supposed to be used for external traffic. You should define listerners in the config entry which handle traffic from external sources.
    I think this is a documentation issue. We need to have a bit more info explaining how -address works with ingress gateway, and how you are supposed to define upstream listeners.
    Chris Johnson
    @chrisjohnson
    I guess my confusion is, I would expect if the ingress gateway's config entry specifies port 8888, and I omit -address, that it only tries to listen on 8888
    I would rather not specify the port on the command at all if I can
    Blake Covarrubias
    @blake
    The internal port for the sidears and mesh gateways is automatically allocated. I’ll need to see why the same is not done for the ingress.
    Tomer Salakoff
    @tomerMP
    Hey guys... just a short Q:
    Any reason I should be concerned about this line constantly appearing in my Consul logs?
    agent.server.router.manager: Rebalanced servers, new active server: number_of_servers=3 active_server="HOSTNAME.dc1 (Addr: tcp/172.10.100.11:8300) (DC: dc1)"
    A cause for alarm or just plain old heartbeat health check?
    Sidy LOM
    @slom_gitlab

    Hello all. I have an issue with Consul 1.9.3 and Micronaut 2.3.2.
    I have this error at the application startup
    io.micronaut.http.client.exceptions.HttpClientResponseException: Request decode failed: json: cannot unmarshal object into Go struct field .Address of type string
    In application.yml I have this

    consul:
  client:
    registration:
      enabled: true
    defaultZone: "${CONSUL_HOST:localhost}:${CONSUL_PORT:8500}"

    Can someone help?

    Daniel Kimsey
    @dekimsey
    @tomerMP There's a mention of this behavior on the Telemetry docs. Leadership flapping is a problem and you'll want to look into what's causing it.
    Daniel Kimsey
    @dekimsey
    I'm unable to delete an intention after recently upgrading my Consul servers to 1.9.3 (agents are still on 1.8.5). The DELETE /v1/connect/intentions/exact endpoint returns a 500, Sources[0].LegacyMeta must be omitted. But this registration has no metadata associated with it as far as I can tell. How do I delete something that won't delete?
    Blake Covarrubias
    @blake
    Hey @dekimsey, I just saw the issue you filed for this hashicorp/consul#9818. What version of the Consul CLI are you using?
    Daniel Kimsey
    @dekimsey
    1.9.3
    I was running the commands on the server, so I didn't attach client info settings. Sorry about that!
    Blake Covarrubias
    @blake
    No worries. I think what you’re seeing is expected behavior. According to our docs, the old APIs can be used as long as you’re only editing an intention. https://www.consul.io/docs/upgrading/upgrade-specific#deprecated-fields The metadata would need to be migrated to the config entry’s Meta field.
    How many intentions do you have with metadata? Is it a large number, or a only a few?
    Daniel Kimsey
    @dekimsey
    @blake Most of them (now) strangely enough this is the only one that behaved in this manner. Our automation tooling adds a "managed" flag so that it won't stomp on manual changes.

    This one was added by hand by an operator and when our automation when to create the intention it aborted due to the duplicate entry, when I went to manually drop it and let automation do it's thing, I got that error.

    I'm going to check the deprecated fields against what we are writing.

    I think I understand, looks like our automation is still using the ID based API to write to, and successfully did so. But the client it was talking to was 1.8.5. That's probably how this got into a weird state. I'm going to look at updating this and re-generating the intentions against the config API.
    Roi Ezra
    @ezraroi
    Hi all, we see very strange behaviour in consul agent. We are starting an agent we a conflict name of another node in the cluster. The agent is reporting that it is shutting down the serf and indeed the surf port is closed but the agent is not stopping and thinks that it is part of the cluster
    Shantanu Gadgil
    @shantanugadgil
    @ezraroi something like that happens when/if someone clones an already cloned VM. Got into such a soup once. I would check up both the nodes (if they are clones), wipe our their data dir and restart ....
    that should hopefully take care of things.
    Roi Ezra
    @ezraroi
    @shantanugadgil Thanks, what worries me is that the consul agent is not stopping and you can't know that the agent is in that state from outside. The agents keeps receiving service registration, thinks it is part f the cluster while he is not.
    I would expect the agent to shutdown and leave as it is doing when joining the cluster is failing
    Chris Johnson
    @chrisjohnson
    Is there a reason that default tokens don't get applied when issuing commands via cli?
    I've got a token stored in acl.tokens.default but I still have to pass it via CONSUL_HTTP_TOKEN when issuing consul ... cli commands
    Is there any way to get it to consume the default token there without explicitly passing it? I'm having to come up with ugly workarounds in .bash_profile to make it easy for the operator to inspect and manage consul without discovering that host's token by hand
    Chris Johnson
    @chrisjohnson
    The docs say
         ACL token to use in the request. This can also be specified via the
     CONSUL_HTTP_TOKEN environment variable. If unspecified, the query
     will default to the token of the Consul agent at the HTTP address.
    But it doesn't seem to behave like this
    Nevermind rubber duck, I was mixing up agent and default tokens
    Yoan Blanc
    @greut
    Does anyone know if HashiCorp has some plans to add arm64 to their APT/RPM hosted repositories?
    Michael Aldridge
    @the-maldridge
    I'd be somewhat surprised, the apt/rpm repos aren't managed in a way that makes them easy to use for production environments
    fortunately, its very easy for you to build your own packages for apt at least. RPM is a strange land
    Yoan Blanc
    @greut
    do you mean arm64 isn't suited for prod environments?
    Michael Aldridge
    @the-maldridge
    No, I mean that Hashicorp's repo specifically does not suit production use by not following the same conventions of the debian/rpm repos already in use on those systems
    Yoan Blanc
    @greut
    Okay; we'll stick to the curl / extract then. Thanks
    HelloWood
    @helloworlde
    Does anyone known how to call consul interface by gRPC? I found proto defination in https://github.com/hashicorp/consul/tree/master/proto, but I didn't found service in this files; And consul provide gRPC port in 8502, how could I use it? Thanks.