Function name should match service name

[lance]

At the moment, the function name almost always matches the service name. However, if the function name has a dash in it, the service name gets a double dash. E.g. a function named game-score becomes a service named game--score, which is not ideal.

[rhuss]

I remember a long discussion with @lkingland about what is more important: The external URL or that the KService and the Function share the same identity (aka name). (unfortunately, I lost the link to this discussion along with the reasoning that it contained)

My POV is still that you can't treat the KService as an implementation detail that is completely hidden by the user if we are leveraging func as a plugin of kn which is for Knative and from which commands are shared to e.g. examine KService created for functions. I have strong feelings here ;-)

But it's not only me since I heard quite some feedback from people who were equally surprised about this kind of name encoding and that you can't map a function name 1:1 to a Knative service name.

[lkingland]

I also think that, as a kn plugin, it should be consistent with how kn works, in particular not escaping in Lance's example above.

Herein lies the rub, for context: As a developer, I would like to "create www.example.org" and "create www.example.com" using Functions, and serve them both from the same cluster. They should also be SSL secured and exposed via the configured cluster issuer without any hassle. Here is a demo of this workflow working (no vaporware): https://lukekingland.com/vid/standard-handler.mp4
We have backed off this workflow a bit since then, in particular the path-derived naming. But please note how it flows from "create" through to "curl", "list" and finally "delete" while being consistent at this level of abstraction.

I do not like that this necessitates that the underlying Knative service have the Function name's dots escaped. It has code smell. I am interested to know if there is a technical solution we can offer that both provides the above level of abstraction and functionality, while still maintaining a 1:1 relationship between the Function names and their underlying Knative service name. It is my understanding the limitation by Kubernetes itself on service names, not Knative. Perhaps the recent work done to enable Service domain names would help here (which was not used for the demo video above).

I do have a proposal that would perhaps satisfy both perspectives, but only if we can first agree that these are both valid use cases, from different perspectives, and are mutually irreconcilable using some technical solution I am unaware of.

[zroubalik]

I have been thinking about this and there are imho these options (or maybe other and would love to hear them):

1. Allow users to create functions with an arbitrary name, so it could contain characters such as ,,_ and when doing the deployment and creating the actual KService, convert the name to the allowed form [1] , ie. replace all the not allowed characters to -. But don't do the duplication of - character, as it is done currently. So this is basically a small correction of the current behavior.
2. Validate the function name during the actual creation of the function (when running kn func create) and fail in case of a unallowed character in the function name. So allow only functions that have name as specified in [1].

[1] https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

I prefer solution 2. as it is more straightforward and doesn't do any unexpected conversion, it is more opinionated (wrt function naming) though.

[rhuss]

+1 for option 2, I think it's fair to apply this restriction on naming which still allows enough choice for the naming.

[lance]

I prefer solution 2. as it is more straightforward and doesn't do any unexpected conversion, it is more opinionated (wrt function naming) though

I think opinionated is often the right approach. I'm +1 for #2.

[lkingland]

I am a fan of opinionated code and fail-fast as well. If we make this change, we will just be unable to:
kn func create myapp.boson-project.org
kn func create myapp.boson-project.com
And auto-create the associated routes; A use-case I sure like; see the demo above). But if we are going to go ahead and agree that it is not worth the trade-off of having to generate a compatible underlying service name, that's fine, but how will we do this now? Perhaps:
kn func create myapp-org --route myapp.boson-project.org
kn func create myapp-com --route myapp.boson-project.com
Perhaps there is a better way?

[rhuss]

Wouldn't it be good enough to create an opinionated URL and show that at the end, but allow the user to overwrite the URL if needed ? So I don't think that the second suggestion with the --route option is bad at all (and gives the user 2 degrees of freedom (service name not coupled to final URL, but having good default).

The difference is that the route URL will be auto-generated by default instead of the service name (that is needed to identify the function in other management calls with kn), but you still have the freedom to chose both independently. To iterate on my main argument to use the service name as an identifier and being identical to the function name is, that many other commands of kn use the service name (not the function name) as the identifier (like listing services, deleting services, connecting services to the event infrastructure, ....). If the service and function name differs and is not considered to be equivalent, then this is totally confusing to the user.

The alternative to the invariant service name == function name would be to decouple func from kn and offer all the service and eventing commands also on func, including the translation from func name to service name. But I don't think this is a good and feasible solution.

[zroubalik]

Agree with Roland on this.

And I as well think, that an option like --route is a great one. As an extra it gives user ability to update the route without changing the function name (as it would have to happen if we go with the function name == route).