Migrate the modules to use vanity url go.opentelemetry.io/collector-contrib

[dmitryax]

Similar to how it's done in the core repo, we should use vanity URLs for contrib modules:

github.com/open-telemetry/opentelemetry-collector-contrib -> go.opentelemetry.io/collector-contrib

Brought by @Aneurysm9 in #21272 (comment):

Regarding the go.opentelemetry.io metadata proxy, it takes data from here and adding an entry for collector-contrib should be easy. I believe there are issues with hosting and management that are being worked through ATM, but I would expect the more significant impediment to its use by collector contrib to simply be the accumulated mass of code already built working with modules at the existing import paths that would need to change.

[Aneurysm9]

@damemi had mentioned that the existing vanity URL redirect implementation is hosted by Google and needs to be transferred to OTel GC/TC or CNCF operation. I do not know the status or timelines of that effort.

Beyond that, what would be the impact to users of these modules if we change the import path? What would the migration path look like?

[damemi]

@damemi had mentioned that the existing vanity URL redirect implementation is hosted by Google and needs to be transferred to OTel GC/TC or CNCS operation. I do not know the status or timelines of that effort.

Yeah, I wrote up some details about how @MrAlias hit this in open-telemetry/opentelemetry-go-vanityurls#17, and the steps we took to finally publish it in this doc proposal.

Now that the service account in the project has been given the necessary IAM roles, you should be able to deploy a new URL without needing a Googler to manually do anything with the project.

But thinking longer term, it shouldn't be just Googlers with access to that project. I think @mtwo was planning to bring this up at the GC meeting.

[mx-psi]

Beyond that, what would be the impact to users of these modules if we change the import path? What would the migration path look like?

An important question to me here is if this would mean a change for all ocb manifests (I expect the answer to be "yes")

[codeboten]

@mx-psi this sounds like something we could make the builder capable of managing for users to help alleviate the pain of the transition period.

[mx-psi]

this sounds like something we could make the builder capable of managing for users to help alleviate the pain of the transition period.

Fair enough, we can probably make the change transparent to users then, provided they are using a recent enough builder version. If we can, we potentially want to land the builder change before we do the migration itself, to minimize the number of "I am using an old builder" type of issues. I am okay with the migration if we do this 👍

[dmitryax]

Beyond that, what would be the impact to users of these modules if we change the import path? What would the migration path look like?

@Aneurysm9 I believe it's only a one-time problem for the users that want to update the otel collector contrib dependencies in their repos. All the dependencies on the existing versions will continue working.

We can mitigate the migration in the builder by renaming the modules under the hood, as @codeboten mentioned in #21382 (comment). For users that don't use the builder, maybe we can provide a shell command to replace import paths in their repos.

Please let us know what other complications you can think of.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.