Comment 1 for bug 1440228

This is a really interesting question. I really didn't like the idea but had a hard time at first figuring out why. I mean, apis are versioned for a reason. It allows us to change things as required without breaking clients. Having a non-versioned url to the api just means it'll go boom without any sort of warning.

So then it hit me, comparing this to charms or even things like github. What happens is that you have a tool that is given an ID and that ID is resolved.

So in the case of charms, you have a constant charmstore url that the client uses the api it's build for (right now the non-versioned legacy api and soon the versioned v4 api) to figure out how to turn landscape-dense-maas into an ID for the API.

So the client is insulating you from the api changes that might take place.

The same is true of a github repository. You git a git url, and that url is mapped to the GH api to get data and the git client and the code is runs is what's insulating you from api changes.

So coming back to the idea of a bundle $id that is consistant, we have that and juju-quickstart as a client supports it. I can do juju-quickstart mongodb-cluster and it figures out the right api call for it. When we rev to v5 of the api, we'll update the client (juju-quickstart) to work with it and to the user, the bundle is still 'mongodb-cluster'.

Matching this up a bit farther, if you wanted to do this with a charm, there's a plugin that we'll be moving into the upcoming 'juju store' subcommand that will do a 'juju charm get' which fetches the content of the charm to your system. It resolves the charmstore ID (which doesn't change regardless of the api version of the charmstore) to where the content is (which might change as the api evolves).

What we're missing is the equivelent for bundles. So my proposal is a couple-fold.

1) The shortest answer if that a juju bundle get or even just updating 'juju charm get' with bundle support would be a good start and at least bring things up to par.

2) The juju-core team and our team are starting work and preparing specs for bundle support in juju core over this next year. We'll see bundles turning into supported entities in juju and it would allow us to provide a real juju client for your needs that would provide a wrapper around the API so that it can evolve which keeping a consistent UX to the user. That work will take time and is a bit out though. This issue though demonstrates that while it's great to have the API, the client and its consistency is very important and something we need to keep in mind.

Does that make sense and if so/not so please let me know what you think. I know this is a long winded way of saying 'no' to this bug report, but I think the real answer is 'yes, what you're asking for makes sense, but in a more official and blessed way'.