konveyor/operator

Further name changes of 'Tackle' to 'Konveyor'

Opened this issue · 7 comments

jwmatthews commented

Continuing with the work to change from 'Tackle' to 'Konveyor'.
Let's make the below changes so we capture the higher level of what is deployed is Konveyor for consistency:

  • Update this repository from 'tackle2-operator' to 'konveyor-operator'
  • Update the 'CR' from 'Tackle' to 'Konveyor'
  • Update the role from 'tackle' to 'konveyor'
  • Update the namespace to be 'konveyor' from 'konveyor-tackle'
  • Update the deployment 'tackle-operator' to 'konveyor-operator'

After this, I am unsure how far to go. Let's at least consider and think through the below.

Questions:

  • Do we want to go deeper with name changes and update the other components?
    • konveyor-ui from tackle-ui, konveyor-hub from tackle-hub, etc
    • ingress of 'tackle' or 'konveyor', etc
  • How far do we take this?
    • What about the API group 'tackle.konveyor.io'
aufi commented

Do we want to go deeper with name changes and update the other components?

  • konveyor-ui from tackle-ui, konveyor-hub from tackle-hub, etc

If we'd change component names, it might make sense don't use prefixed names, so the names change could be:
tackle2-ui -> ui (repo github.com/konveyor/ui)
tackle2-hub -> hub (repo github.com/konveyor/hub)
...

  • 👍2
jmontleon commented

Changing the CR is going to be the most disruptive of the above. If we want to change API Group I vote we do it at the same time otherwise we're going to hit this twice. And we should probably do it sooner and just get it over with so we can stabilize on the new ones.

I'm not sure if the namespace change will inflict any pain other than we'll probably have to make sure it works in both (and upgrades in both, I'm not sure if we change the namespace and then have OwnNamespace as the only option if we cause pain for existing installs https://github.com/konveyor/tackle2-operator/blob/main/bundle/manifests/konveyor-operator.clusterserviceversion.yaml#L339-L342, we might need to add SingleNamespace).

The repo name change probably isn't too painful.

I think the deployment name change and role name change should be painless.

jwmatthews commented

I could see the API Group is excessive and not needed, worth talking out and seeing what folks think though.

djzager commented

/triage accepted
/priority important-longterm
/kind documentation
/kind feature

jortel commented

I'm still opposed to this.
There are 80 repositories in konveyor and tackle2- prefix is the only way to easily identify what constitutes the tackle application.

djzager commented

I was of the understanding that it was still an open question if we go around dropping the tackle(2)- prefix. That what could be done and warrants prioritization is:

  • Update the 'CR' from 'Tackle' to 'Konveyor' ... this has api compatibility concerns
  • Update the role from 'tackle' to 'konveyor' ... this would likely be transparent to any user
  • Update the namespace to be 'konveyor' from 'konveyor-tackle' ... would need to make sure that this doesn't break existing installs, and isn't this partly a documentation issue where we tell users to install our operator?
  • Update the deployment 'tackle-operator' to 'konveyor-operator' ... already done
  • 👍1
dymurray commented

+1, ignoring the repo prefix (though I would want to consider removing tackle2 as much as possible and that probably includes cleaning up our organization so it's not confusing which repo is which to Jeff's point), the CR and operator/CSV changes should be prioritized.