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

portMappings.hostPort does not reset on multiple machine specs #108

Open
danielskowronski opened this issue Jun 3, 2024 · 1 comment
Open

Comments

@danielskowronski
Copy link

According to specification and common sense, when bootloose.yaml defines several machine sets (e.g. workers and controllers), you'd expect portMappings.hostPort to be the base for port numbers only in a given machine set, not globally. However, the counter continues through all machine replicas in all specifications that include hostPort - contrary to name field, which expands %d as replica counter in given set.

Bootloose version: v0.8.0


Example bootloose.yaml:

cluster:
  name: foo
  privateKey: cluster-key
machines:
  - count: 3
    spec:
      image: quay.io/k0sproject/bootloose-ubuntu22.04
      name: a%d
      portMappings:
        - containerPort: 22
          hostPort: 13000
  - count: 3
    spec:
      image: quay.io/k0sproject/bootloose-ubuntu22.04
      name: b%d
      portMappings:
        - containerPort: 22
          hostPort: 14000
  - count: 3
    spec:
      image: quay.io/k0sproject/bootloose-ubuntu22.04
      name: c%d
      portMappings:
        - containerPort: 22
          hostPort: 15000

Expected mapping for port 22 in each container created:

  • a0 - 13000, a1 - 13001, a2 - 13002
  • b0 - 14000, b1 - 14001, b2 - 14002
  • c0 - 15000, c1 - 15001, c2 - 15002

Actual behaviour - bootloose show:

NAME     HOSTNAME   PORTS           IP            IMAGE                                      CMD          STATE
foo-a0   a0         0->{22 13000}   172.17.0.2    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-a1   a1         0->{22 13001}   172.17.0.3    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-a2   a2         0->{22 13002}   172.17.0.4    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-b0   b0         0->{22 14003}   172.17.0.5    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-b1   b1         0->{22 14004}   172.17.0.6    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-b2   b2         0->{22 14005}   172.17.0.7    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-c0   c0         0->{22 15006}   172.17.0.8    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-c1   c1         0->{22 15007}   172.17.0.9    quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
foo-c2   c2         0->{22 15008}   172.17.0.10   quay.io/k0sproject/bootloose-ubuntu22.04   /sbin/init   Running
@danielskowronski
Copy link
Author

danielskowronski commented Jun 3, 2024

https://github.com/k0sproject/bootloose/blob/main/pkg/cluster/cluster.go#L128 is the root cause - I think user should be in more control and have proper responsibility for input file specification. If user is the only party responsible for not having name collision, then we should just allow Docker to fail when attempting to assign a port that already exists.

Current behaviour lets user control ID of machine in replica set, while internally bootloose uses absolute IDs. If in the above example, you remove hostPort from a%d spec, then b0 will still get 14003 :/

danielskowronski added a commit to danielskowronski/bootloose that referenced this issue Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant