Skip to content
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

Import model name collision #1433

Open
kian99 opened this issue Nov 13, 2024 · 4 comments
Open

Import model name collision #1433

kian99 opened this issue Nov 13, 2024 · 4 comments

Comments

@kian99
Copy link
Contributor

kian99 commented Nov 13, 2024

When working on #1432 to import offers into JIMM, I didn't address the scenario where is collision with an existing offer URL.

For context, an offer URL takes the form:

  • [offer-owner]/[model-name].[app-name/alias]
  • E.g. admin/foo.postgresql

At first glance it struck me that we can't have a collision when importing offers into JIMM because the Juju controller enforces this URL must be unique. This was until I realised JIMM could import models with the same name from multiple controllers.

Consider Controller A with model foo and Controller B with model foo, both created by an admin user. When importing these models into JIMM, you would import these to a new owner say "[email protected]" the second model import will fail because [email protected]/foo already exists.

Overall, the case where offer URLs collide seems to be a subset of the problem where model names collide.

In #1272 I changed the way model uniqueness was enforced in JIMM. Previously a model was unique according to a combination of (controller, name, owner). Now it is unique according to (name, owner), meaning that we more closely match Juju's behaviour that a user cannot have two models with the same name (previously we had conflicts in the Juju CLI if you had access to two models with the same owner and same model name).

How can we address the situation where you want to import a model where the name is already used because of another controller?
Some ideas:

  • Allow the model name to be changed.
  • Tell the user to add the model to a different owner.
@ale8k
Copy link
Contributor

ale8k commented Nov 13, 2024

What happens if I create:

  • Controller A
  • Controller B

And on both controllers, create:

  • my-model (On A)
  • my-model (On B)

And finally, I run:

  • juju switch controller-a:my-model
  • juju migrate my-model controller-b

I imagine the result of this is the behaviour we want here.

@ale8k
Copy link
Contributor

ale8k commented Nov 13, 2024

Tested this, same issue in Juju:

❯ jj migrate my-model controller-b
ERROR target prechecks failed: migration target prechecks failed: model named "my-model" already exists

Closing issue.

@ale8k ale8k closed this as completed Nov 13, 2024
@alesstimec
Copy link
Collaborator

I think this is still a valid issue: we need to discuss it as a team.

@alesstimec alesstimec reopened this Nov 13, 2024
@kian99
Copy link
Contributor Author

kian99 commented Nov 14, 2024

After some more thought on this yesterday, the issue with model names colliding is potentially simply solved by using a different owner (as mentioned above). But application offer URLs can still collide with no way for resolution. I'll change the name of the issue to better reflect this new issue.

Consider:

  • Controller A with model foo and Controller B with model foo, both created by an admin user.
  • Both models have an application called postgresql.
  • When attempting to import these models into JIMM (even using different owners), both will have the same offer URL of admin/foo.postgresql.

Some ideas on solving this:

  • Alias the application offer in JIMM, i.e. if an offer URL already exists during import then save the URL with a number attached like admin/foo.postgresql-1.
  • Allow the user to provide a "suffix" so they can make their model's offer URLs more unique. I.e. --offer-alias=my-team aliasing the offer to admin/foo.postgresql-my-team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants