A better way to define Service ports

[concaf]

The way Kubernetes' ServiceSpec allows describing Ports is something like this -

services:
- name: wordpress
  type: LoadBalancer
  ports:
  - port: 8080
    targetPort: 80
    protocol: UDP

We can also provide an alternative shortcut way to do this by using a syntax like -

services:
- name: wordpress
  type: LoadBalancer
  ports:
  - 8080:80/udp

[pradeepto]

Will this not make tooling difficult and perhaps induce string magic?

[kadel]

You are overwriting already existing 'ports'.
Shortcuts can't do that. We have to keep the original way of defining things untouched.

We can use a shortcut like this, but it has to be named differently. Something that is not already in ServiceSpec

[concaf]

@pradeepto -

Will this not make tooling difficult and perhaps induce string magic?

Yes, the tooling will be difficult but that is an implementation detail that we can take care of.
Yes, this introduces string magic, but how else do we want to implement more intuitive shortcuts?

@kadel -

We can use a shortcut like this, but it has to be named differently. Something that is not already in ServiceSpec

Agree, we can have a different field name for this, we can carry the ...Ref convention here

services:
- name: wordpress
  type: LoadBalancer
  portsRef:
  - 8080:80/udp
  ports:
  - port: 8080
    targetPort: 80
    protocol: UDP

[pradeepto]

Yes, the tooling will be difficult but that is an implementation detail that we can take care of.
Yes, this introduces string magic, but how else do we want to implement more intuitive shortcuts?

That is definitely not what we discussed in the meeting. To quote from the meeting logs that you yourself noted:

"We should make something that is easier to tool the entire thing"

Strong -1 to this idea.

[kadel]

ref should be used as a shortcut for Reference. In this case, we are not referencing anything, or am I missing something?

[kadel]

"We should make something that is easier to tool the entire thing"

Just be aware that it is quite common that "easy to tool" and "easy for humans" are opposite.

[concaf]

@kadel -

ref should be used as a shortcut for Reference. In this case, we are not referencing anything, or am I missing something?

Yep, in OpenCompose we decided to use ref as something that will refer to the root level shared concepts, but here we can use it to refer to a concept.
I am fine with any other convention if ref does not look right, but I'd love to have a convention to define the shortcuts.

[concaf]

@pradeepto - everything in #2 required string magic. Doing string magic is going to let us create shortcuts to add better UX to the spec. It's not about string magic, it's about better UX for the spec, which is the prime goal right now.

I'm fine with not doing string magic if there is a better way of implementing this, any suggestions?

[pradeepto]

@containscafeine @kadel Whatever you guys decide, keep integrations (LSP bits etc) in the mind. If we can integrate with existing tooling (vscode, che) with less or no effort that is a HUGE win. Saves time and wins hearts. That is all I am saying.

[concaf]

I don't think we need this for now, let's reconsider if and when a need arises