Request: change ownership of the Ubuntu Advantage charm

charmhub requests
1

Hello,

Please change the ownership of the Ubuntu Advantage charm to the “Ubuntu Advantage Charmers” team.

Thanks!

2

This is referrring to Charmhub | Deploy Ubuntu Advantage using Charmhub - The Open Operator Collection and Ubuntu Advantage Charmers in Launchpad just to be clear. Thanks.

3

This is done :slight_smile:

1 Like
4

@roadmr related to this, would it be possible to delete the not-fully-setup ubuntu pro charm? Just to confirm before you do though, that wouldn’t prevent someone from renaming ubuntu-advantage to ubuntu-pro at some point in the future, would it?

5

Ick, I really prefer not to delete charms.

If the end goal is to deprecate ubuntu-advantage in favor of ubuntu-pro, maybe you could start publishing charm builds under ubuntu-pro even if it’s the same charm, and eventually make ubuntu-advantage uninstallable and unlisted? So the question becomes how to migrate people currently on ubuntu-advantage to ubuntu-pro.

  • Daniel
6

@roadmr in that case can you simply transfer ubuntu-pro to be owned by “Ubuntu Advantage Charmers” as well?

7

Sure, it is done.

  • Daniel
1 Like
8

@cmisare explained to me that at some point, we were told to stop publishing the ubuntu-pro charm until proper support for charm renames was added.

Since then, we’ve had people contacting us not knowing which charm should be used (ubuntu-advantage vs. ubuntu-pro).

I added a note explaining the situation in the README of the repo, but that’s not very visible to end users.

I was planning on doing the following:

  1. Resuming the publishing of ubuntu-advantage as both ubuntu-pro and ubuntu-advantage by reactivating the other Launchpad recipe.
  2. Documenting the situation in both the README and as CharmHub documentation, explaining that either charm name can be used and that the latest revisions of both will always be the same, but that the name shown in juju status will be ubuntu-advantage regardless of the charm name used to install it.

What do you think @mthaddon @cmisare @ijansky?

9

I’m not really sure of the reasoning behind stopping publishing to ubuntu-pro, what do you mean by “until proper support for charm renames was added”? Is there a particular bug around that that you’re tracking? As far as I know if you rename a charm currently charm (i.e. explicitly request it to be renamed by the charmhub team) upgrades will continue to work but new deploys will require using the new name, which I think is what would be wanted?

10

@mthaddon I was trying to understand the reason why we don’t have a recipe for releasing the ubuntu-pro charm in this repo, and when discussing this with @cmisare, he mentioned:

[…] but at some point we were asked to remove the recipe as the juju team was said to be deciding on how charm renames/upgrades would work and happen in the future

So I thought that by resuming the publishing of ubuntu-pro with a recipe, we could be going against some strict recommendation. @cmisare and I couldn’t find any references to back that idea, but I decided to check in this thread anyway.

Anyway, after discussing this further within CS team, the idea is basically to follow @roadmr’s suggestion:

  1. Fork ubuntu-advantage with a real rename in the charm manifest (ubuntu-pro), in a separate LP repo (charm-ubuntu-pro) with a recipe publishing to the ubuntu-pro charm. We’d make that the supported charm going forward.

  2. Deprecate ubuntu-advantage: it would still be available and have a recipe for releasing, but it’d only receive bugfixes when absolutely needed.

  3. Update documentation on both charms to explain the situation.

I think that kind of fixes the problem in a less confusing manner to users, even though it costs a bit more of maintenance effort in the short term. If anyone has other ideas, we are open to suggestions.

11

So there are 3 relevant names (and one private identifier) that I think are relevant.

  1. A charm’s name as present in Charmhub
  2. A charm’s metadata.yaml name field
  3. The running application name
  4. The charm UUID as given by Charmhub

The issue is that Juju uses the metdata.yaml’s name (2) to create a default for the application name (3), but the thing that the user types is actually (1).

If you juju deploy ./my-customized-mysql.charm that likely would create an application named mysql in your model, though you could override that with juju deploy ./my-customized-mysql.charm better-name.

This is also true of charms that we find on charmhub, (eg, if I have a charmhub charm listed as jameinel-ubuntu, I can have it deploy applications named just ‘ubuntu’).

It is generally not great form for the user string to not match the metadata name, but AFAIK this isn’t enforced by anyone. (And enforcing it gets tricky with juju download foo creating foo_r21.charm, etc, so the names don’t usually match exactly.)

The other trick with (4) is that when Juju asks Charmhub what mysql means, it returns a charm, a revision, and a UUID that is Charmhub’s tracking identifier. So that if you in the future change Charmhub’s registry so that foo is now called bar and something new is called foo, then users that do juju refresh my-foo-app will get the updated revisions of bar (but they should be able to juju refresh --switch foo my-foo-app.

In the case of Ubuntu Advantage and Ubuntu Pro, I would start by clearly defining what you consider the ideal case would be, and then we can try to work backward to what you consider a reasonable compatibility path to get there. IMO, because ubuntu-advantage is a deprecated name, what you want is to end up with a charm at Charmhub | Deploy Ubuntu Pro using Charmhub - The Open Operator Collection that calls itself ubuntu-pro internally, that juju deploys as ubuntu-pro.

I think that makes it fairly obvious what you want to publish at that name.

Now the question is how do you get there from here, and what do you do with the old ubuntu-advantage charm and structure.

I think you could

  1. Deprecate the old name entirely, leave the charm calling itself ubuntu-advantage but have the charm itself give a message saying self.status = Active('this charm is deprecated, please --switch to ubuntu-pro') This means people could juju refresh ubuntu-advantage --switch ubuntu-pro and change the charm that they are running, even without changing the application name, or they could remove and redeploy the charm (depending on whether the two are actually compatible in the sense of what relations are present, etc.)

  2. Publish the ubuntu-pro charm at ubuntu-advantage, so people just doing juju refresh ubuntu-advantage get the new version of the charm, but also people doing juju deploy ubuntu-advantage would actually end up with an application named ubuntu-pro which may cause some confusion.

Note that juju itself doesn’t support changing the name of a running application. Partly because of the implications of all the places where that name is referenced (the unit agents, the config files, the charms and relations all include the application names).