Mismatch between module name and repository URL

[mkalcok]

Since the repository was moved from ovn-org, the name of the module in go.mod does not match the repository URL. This causes go tooling to complain

> go get github.com/ovn-kubernetes/libovsdb
go: github.com/ovn-kubernetes/libovsdb@upgrade (v0.7.0) requires github.com/ovn-kubernetes/[email protected]: parsing go.mod:
        module declares its path as: github.com/ovn-org/libovsdb
                but was required as: github.com/ovn-kubernetes/libovsdb

Renaming the module in go.mod is probably not the way to go, since that would break any existing projects that still use github.com/ovn-org/libovsdb URL. But perhaps a section on top of README file could mention how to add this module as a dependency?

[dave-tucker]

Ugh yeah this is annoying. I think the plan should be:

1. Create a fork of this repo back at github.com/ovn-org/libovsdb
2. Add a deprecation notice to the module there using: https://go.dev/ref/mod#go-mod-file-module
3. Archive the repo (so no future updates)
4. Rename the module in the go.mod here

This may break the github redirects, but I think that's preferable to having go import issues.

[dave-tucker]

@tssurya @jcaamano is ☝ something you can help with?

[jcaamano]

Question:

> go get github.com/ovn-org/libovsdb

would still work right?

Not disagreeing with @dave-tucker suggestion, just want to know where we sit today.

[mkalcok]

Question:

> go get github.com/ovn-org/libovsdb

would still work right?

Not disagreeing with @dave-tucker suggestion, just want to know where we sit today.

Yes, that format still works today because github redirects old URLs when a project is moved to new account/org.

[dave-tucker]

Figured I'd at least explain my reasoning for proposing #394 (comment)

For the old URL github redirect will work indefinitely unless another ovn-org/libovsdb repo happens gets created, at which point all bets are off (could no longer be Go code). While this is improbable, it's not impossible. I guess you could consider this a route for a potential supply chain attack - except of course that ovn-org would need to be compromised for this to happen.

Having go get github.com/ovn-kubernetes/libovsdb broken is not ideal either especially as that's what will show up when you search for libovsdb today... and we can't change the module name without breaking existing users 😭

So while it's a bit of extra work, I think the plan I've proposed is the "cleanest" way we can rename the module AND keep things working for the old URLs.