Loki SSD fails if interface is not eth0 or en0

[darrikmazey]

Describe the bug
A minimal config for SSD fails if the network interface is not either eth0 or en0, causing services to bind to lo instead.

To Reproduce
Steps to reproduce the behavior:

1. Started Loki (v2.4.1) on an AWS EC2 instance with default interface ens5

Expected behavior
Expected services to bind to private IP address.

Environment:

• Infrastructure: AWS EC2
• Deployment tool: manual configuration

Screenshots, Promtail config, or terminal output
On startup logs showed:

Dec 15 14:44:13 i-0c07138529555a68b loki[5836]: level=warn ts=2021-12-15T14:44:13.193460761Z caller=util.go:168 msg="error getting interface" inf=eth0 err="route ip+net: no such network interface"
Dec 15 14:44:13 i-0c07138529555a68b loki[5836]: level=warn ts=2021-12-15T14:44:13.194079795Z caller=util.go:168 msg="error getting interface" inf=en0 err="route ip+net: no such network interface"

/config showed:

  instance_interface_names:
  - eth0
  - en0
  - lo
  address: ""
  port: 0

This was rectified by adding the following to configs:

common:
  ring:
    interface_names:
      - ens5

[dginhoux]

Hi,

In container, it's not possible du get the device name for specifying it in cfg file... is it possible to use a wildcard or use all availables interfaces ?

[DylanGuedes]

That's a very complicated problem because based on some internal discussion that we had, there are scenarios where users might be badly affected by using an unwanted interface and scenarios where users are badly affected by not using a wanted interface, so picking a default that works for everyone is not an easy task.

That said, we are focusing instead on improving the configuration experience. For that, we are adding a way to configure the net interface to be used by Loki in a single place, inside the common configuration section.

For context, the main problem with the current scenario is that when you configure common: ring: interface_names, you might fall into the trap of thinking Loki will use the defined interface_names everywhere. But it will actually only use it for ring communication, not for other components (ex: the frontend, which isn't a ring). With this new configuration, this is solved, as what is defined there will be used by all Loki components.

[stale]

Hi! This issue has been automatically marked as stale because it has not had any
activity in the past 30 days.

We use a stalebot among other tools to help manage the state of issues in this project.
A stalebot can be very useful in closing issues in a number of cases; the most common
is closing issues or PRs where the original reporter has not responded.

Stalebots are also emotionless and cruel and can close issues which are still very relevant.

If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.

We regularly sort for closed issues which have a stale label sorted by thumbs up.

We may also:

• Mark issues as revivable if we think it's a valid issue but isn't something we are likely
  to prioritize in the future (the issue will still remain closed).
• Add a keepalive label to silence the stalebot if the issue is very common/popular/important.

We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task,
our sincere apologies if you find yourself at the mercy of the stalebot.

[dginhoux]

still present and still searching for a workaround in full containerized deployements

[DylanGuedes]

I believe it is solved; you only have to use the common section directly instead of common/ring section:

common:
-  ring:
-    interface_names:
-      - ens5
+ interface_names:
+ - ens5

[dginhoux]

Yes, this work in a bare metal setup where it's easy to get the net devname.
But in fully containerized like kub or swarm env, with multiple networks.... ? howto ?

[stale]

Hi! This issue has been automatically marked as stale because it has not had any
activity in the past 30 days.

We use a stalebot among other tools to help manage the state of issues in this project.
A stalebot can be very useful in closing issues in a number of cases; the most common
is closing issues or PRs where the original reporter has not responded.

Stalebots are also emotionless and cruel and can close issues which are still very relevant.

If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.

We regularly sort for closed issues which have a stale label sorted by thumbs up.

We may also:

• Mark issues as revivable if we think it's a valid issue but isn't something we are likely
  to prioritize in the future (the issue will still remain closed).
• Add a keepalive label to silence the stalebot if the issue is very common/popular/important.

We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task,
our sincere apologies if you find yourself at the mercy of the stalebot.

[dginhoux]

I'll try in fews days if 2.5 release help when deploying in containers swarm and kube.