... > > And now I think of it, can I stream resources? I don't want to > provision a machine with 8TB of storage just so I can restore a 4TB > dump. Maybe this is just a terrible example, since I probably couldn't > be bothered uploading the 4TB dump in the first place, and would > instead setup tunnels and pipes to stream it into a 'juju run' > command. An abuse of Juju resources better suited to Juju blob > storage? > > We've talked about streaming resources, but decided to omit it for version 1.
1. Resources are cached in the server anyway, so a 4TB resources isn't a great fit there. We want to be caching it both for efficiency (5 units consuming 100MB resource only needs to be copied to the cloud one time), and for repeatability (adding another unit can be sure to get the same content of the resource even if the charm store, etc has been upgraded.) 2. Resources *are* loaded only on demand. So until the charm does "resource-get", we don't copy the data from the API server to the unit. 3. I believe we left it implementation defined if we load resources from the charm store opportunistically, but I think because of (1) we probably will. 4. We can certainly add a new hook tool that would stream the content from the API server (eg resource-stream). However, 1&2 mean it didn't seem super useful vs added complexity and more time to implement. John =:->
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
