-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[chore] Update vertex_ai to vertex.ai #1684
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Guangya Liu <gyliu@ibm.com>
@lmolkova Done! But seems the CI is reporting an compatibility issue:
|
@@ -13,9 +13,9 @@ groups: | |||
stability: experimental | |||
value: "openai" | |||
brief: 'OpenAI' | |||
- id: vertex_ai |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lmolkova do you know if we can also need to mark vertex_ai
as deprecated? if so, how to make it? This is a value and not an attribute, did not find any example for this, thanks!
I will update https://github.com/open-telemetry/semantic-conventions/blob/main/schema-next.yaml after #1683 got merged. |
stability: experimental | ||
value: "vertex_ai" | ||
value: "vertex.ai" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find any evidence of just "Vertex" without "AI" in GCP's docs, so vertex_ai
actually seems appropriate to me. I can't imagine any other vertex.*
values.
If that reasoning holds water to keep it as vertex_ai
, I can verify with the team.
stability: experimental | ||
value: "vertex_ai" | ||
value: "vertex.ai" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we're here, should we prefix with gcp.
like we have for some other vendors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, we can name it as gcp.vertex.ai
or google.vertex.ai
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're really inconsistent in semconv on prefixing things with cloud name (not intentionally). General issue - #608
E.g. we have spanner
and it's ok since there is just one spanner DB.
We have gcp_pubsub
for messaging because pubsub
is too generic. We also have some gcp.*
attributes and resources.
Both vertex.ai
or vertext_ai
are unique enough - they don't have to have a prefix similarly to spanner
. If we add prefix, it should be gcp
.
So what should we do:
spanner
,vertex_ai
,gcp_pubsub
spanner
,vertex_ai
,gcp.pubsub
gcp.spanner
,gcp.vertex_ai
,gcp.pubsub
gcp_spanner
,gcp_vertex_ai
,gcp_pubsub
- ...
?
Speaking from Azure side, we're likely to stay where we are: cosmosdb
, eventhubs
, az.ai.inference
(use product name when it's unique enough, use az.
namespace when it's not). Reasons: it's nice to be consistent, but some of these things are de-facto stable and are used wide enough to make breaking really problematic.
cc @jsuereth if he has any thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also the cloud.platform
values which look like azure_functions
, gcp_cloud_functions
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm like 80% confident we can rename azure_functions
to az.functions
. Let me try
Fixes #
This is a follow up for #1574 (comment)
/cc @lmolkova
Changes
Please provide a brief description of the changes here.
Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.
Merge requirement checklist
[chore]