Discuss changing naming conventions for faas metrics

[skonto]

What are you trying to achieve?

I am defining the metrics specs for Openshift Serverless and I am looking to use a standard approach.
The Opentelemetry spec currently covers only the case of a FaaS using faas as the prefix for the corresponding naming conventions for resources, traces, metrics etc.
I see a better fit to change this to something more generic like func instead. There are cases where function frameworks
run on premise that are not covered by the current spec.

What did you expect to see?
A more generic definition for function metrics.

Additional context.
Previously discussed here.

[Oberon00]

This proposal was already brought up (with a different motivation): #1480

I think my arguments against the change still stand (copied from the mentioned PR):

1. Renaming a whole semantic convention group is a large breaking change. Breaking changes are generally OK, since these conventions are still "experimental", but I think the name "faas" is not bad enough to justify this. If we are worried about discoverability, I'm sure we can add a prominent link e.g. in a Lambda section of the upcoming AWS semantic conventions.
2. I think when most users read "faas" they will not know what it is. But when they read "function" they think they know what it is, but it will be wrong. Thus, I think the name "function" is worse. @anuraaga already brought up the confusion with code.function that can arise for example. I think "serverless", "serverless_function", "faas_instance", "cloud_function" might be better names, but I am not convinced renaming is worth it.

[Oberon00]

There are cases where function frameworks run on premise that are not covered by the current spec.

The name "faas" may not be a perfect fit, but I think they are still covered.
Also, while from the company perspective, the function framework may not be provided "as a service" when running on premise, from a developers perspective, it is a service they can use 😃

[Oberon00]

What might be helpful: adding a value to cloud.provider and faas.invoked_provider to signify on-premise.

[skonto]

@Oberon00

This proposal was already brought up (with a different motivation): #1480

Good to know I missed that. Thanks

Also, while from the company perspective, the function framework may not be provided "as a service" when running on premise, from a developers perspective, it is a service they can use
I think "serverless", "serverless_function", "faas_instance", "cloud_function" might be better names, but I am not convinced renaming is worth it.

For the operator though who runs stuff on-premise the term faas is a bit unrelated (typically it is about cloud managed services with a specific cost model etc) but it could be ok if we expand the definition or at least make it clear somehow. Btw people could run services both on-premise and on the cloud and we might want to make a distinction and this is where the proposal above
defining the provider might be useful.

Regarding the confusion for code function it was solved easily. I dont see a real issue if a domain prefix is used like serverless the same way code was used. I think this would be much better than relying on:

I think when most users read "faas" they will not know what it is.

and then let them find out what that is. Reason is there are users out there who are aware of cloud computing and they will identify faas quickly.

[yurishkuro]

I think the term faas applies equally to cloud and on prem. When on prem, there is still a "service" provided to other applications that manages their serverless functions.

[kenfinnigan]

Should an industry term such as "faas" be used in the semantic conventions? We don't use "IaaS" or "PaaS", as far as I can see, to refer to anything matching those terms. What happens when "faas", as an industry term, falls out of favor and is replaced with another?

I'd be interested to have your thoughts on this @rakyll.

I agree it makes sense for "on-premise" to be an option for a provider. Should a separate issue be opened for this?

[ocelotl]

I asked Claude to review this issue and Claude suggests it be closed with this explanation:

Purely a semantic-conventions naming discussion (renaming the faas prefix), a domain that has since migrated to open-telemetry/semantic-conventions and is no longer tracked in the spec repo. The discussion also fizzled in June 2021 with maintainers (Oberon00, yurishkuro) largely opposed to the rename and no consensus; it revisits prior non-merged PRs #1480/#1736.

To guard against a mistaken suggestion, Claude then independently re-verified this conclusion:

Confirmed: a stale (June 2021) faas-prefix rename discussion, no consensus with maintainers Oberon00/yurishkuro opposed; the faas semantic conventions now live in open-telemetry/semantic-conventions and are no longer tracked in the spec repo, so moved-repo close is correct.

Claude evaluated this issue with medium confidence that it can be closed.

Claude has classified this issue as belonging in another repository.

The intention of this comment is to make it easier for a human being to review this issue before making a decision.

[svrnm]

Closing this, as this is now a semantic conventions issue, if this is incorrect, please open a new issue on the semantic conventions repository.