Add string manipulation functions to domain template about serving HOT 14 OPEN

I'll re-open the issue and see if there's more input from the other maintainers

I'm leaning towards your idea of adding the funcs

cc @ReToCode @skonto

from serving.

It seems like you want a different template per namespace.

Maybe extending the config to support that then trying to do this with templates would the easier approach. This would mirror already what we're doing with domain name selection.

from serving.

@dprotaso that would work too.

Not sure what you mean about the domain name selection though, as far as I know that only selects on labels not based on the namespace.

from serving.

This would mirror already what we're doing with domain name selection.

You're right we do domain selection based on labels from the knative service resource. But now with the new config it's easy enough to extend it to have something like a namespaceSelector

from serving.

Up to you. I think adding namespace selectors to the domain template and domains configuration is a more elegant solution. Even more so if the configurations were consistent formats where you could match labels or namespaces. It would be more user friendly.

But string manipulation would certainly be easier to implement.

from serving.

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

from serving.

/remove-lifecycle stale

from serving.

I'm going to close this out but feel free to create a new feature request for namespaceSelector in the domain selection

from serving.

I'm looking more at the label selectors in the domain configmap and I'm not sure it would be a good solution after all for the example I gave. The configuration would still have to be pretty huge and repetitive.

{{.Name}}-project1.dev.example.com: |
  namespaceSelector:
    name: project1-dev
{{.Name}}-project1.test.example.com: |
  namespaceSelector:
    name: project1-test
{{.Name}}-project2.dev.example.com: |
  namespaceSelector:
    name: project2-dev

Whereas some string manipulation functions would reduce this kind of repetitive configuration considerably. Is there a reason you don't think that is a good idea? @dprotaso or do you have a better suggestion on a way forward?

from serving.

what's {{.Name}} in that example?

The config-domain is just the base domain selection.

project1.dev.example.com: |
  namespaceSelector:
    name: project1-dev
project1.test.example.com: |
  namespaceSelector:
    name: project1-test
project2.dev.example.com: |
  namespaceSelector:
    name: project2-dev

And then pair it with the domain template - https://github.com/knative/networking/blob/41aa2087242da0af0b1fee6721882fc0aed1b87e/config/config-network.yaml#L109

You could then make your domain template the following

"{{.Name}}-{{.Domain}}"

This would give you isolation since you've codified the namespace into the base domain

from serving.

@dprotaso yea that would work but would be even more verbose than the current solution. So I don't see it as a real improvement.

Edit: It's also more difficult to handle the else case that I listed above unless you built a very long if statement with all the namespaces names in it to decide if the pattern should be {{.Name}}-{{.Domain}} or {{.Name}}.{{.Domain}}

from serving.

difficult to handle the else case that I listed above

I believe the way it works is we always pick the longest selector - so you could add an empty selector and it would be your fallback which would act like your else

from serving.

The else would need to be in the domain template not the domain configmap (note that dot instead of a dash). So I'm not sure if that would work.

So where are we at with this issue? Is this not going to be accepted to Knative? If so I don't think I intend on making a new feature request with your suggestion as I mentioned it is actually more verbose than the current workaround.

from serving.

Hm I'm a bit hesitent about adding more dynamics in general. This increases the (already quite high) complexity in various places while the value added is limited (in my personal opinion).
For example the domain pattern in #14903 (comment) also ends up adding new challenges to create certificates. There were good reasons for ingress solutions (OpenShift for example) to rely on default domains with just one subdomain (like *.apps.mycluster.com) with the ability to overwrite this for specific services.

from serving.