Allow processes with same name but in different namespace

[f1bonacc1]

Allow processes with same name but in different namespace

[F1bonacc1]

Hi @shivaraj-bh,

That's a proposal that makes a lot of sense.
The downside is that it will break backward compatibility. As you know the namespace key is part of the process:

processes:
  p1:
    command: c1
    namespace: n1
  p2:
    command: c2
    namespace: n2

Changing p2 to p1 will fail parsing on the yaml level.
The YAML spec does not allow for duplicate keys in a mapping node.

There are a few bad options that I see:

Option 1:

processes:
  n1:
    p1:
      command: c1
  n2:
    p1:
      command: c2

Which breaks backward compatibility.

Option2:
Add NS prefix with a delimiter.

processes:
  n1::p1:
    command: c1
    namespace: n1
  n2::p1:
    command: c2
    namespace: ABCD # kept for BW compatibility, but will be replaced with `n2` in code.

Feels not intuitive and hacky.

Option3:
Convert processes to a list.

processes:
  - p1:
    command: c1
    namespace: n1
  - p1:
    command: c2
    namespace: n2

Also breaks backward compatibility and for long enough compose.yaml files there will be more than 1 default.p1 processes.

Do you see any other options that I am missing?

[adrian-gierakowski]

IMHO this feels like feature creep.

Apart from requiring breaking changes to configuration format, it will also force the user provide the namespace when calling command which take process name as args (process start|stop|logs …)

Maybe namespace should have been called group to not give people ideas, lol 😂

Anyway, if this was to go ahead, I’d suggest to add a new namespaces prop which could house the namespaced processes. Top level processes could be placed in default namespace which would also be the default when addressing processes without providing namespace explicitly on command line

[shivaraj-bh]

@F1bonacc1 I had Option 3 in mind as well, but that again introduces its own set of problems. I posted this thinking -- maybe we can find an easy way out -- but seems like it will only introduce breaking changes for no real functionality benefits.

[shivaraj-bh]

I am guessing we agree on the fact that this might not be feasible, closing this as not planned.