Request: stable bundle retrieval mechanism

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'.

Just to provide a little context here, the client in my case is 'openstack-install' which pulls down the latest landscape-dense-maas bundle from the charmstore. Currently the versioned api url is hardcoded in the client and just like juju quickstart we'd have to update the client if/when the versioned url changed.

I do like the idea of having a `juju bundle get` or `juju charm get` in the interim while Juju gets a more official support for bundles. This keeps me from having to update the installer everytime a new Landscape is released or if the versioned api url changes.

Like David said this isn't high priority but would like to keep this on the radar moving forward.

Thanks!

Moved to quickstart, just as a better holding ground after talking with Rick. There could be a better spot for it, charm-tools or juju-core, not sure.

With flat namespaces now, juju charm get (and juju bundle get since charm-tools also squats on that namespace) could do this when it switches to new v4 api

I thought about adding a --download-yaml option to quickstart but it really feels like it's cross a functional line there. Since Marci has expressed interest in the charmtools approach I'm going to remove quickstart and then make sure it ends up in the core work going on.