When I chatted about this, it is because the immediate point where the
code wants to read the index files doesn't have the credentials to read
the private bucket.
However, when we discussed it, anything that wanted to start an actual
instance needs to have the credentials for the provisioner (compute) so
you would expect that it would have access to the data store (swift/s3).
So it seems like we *should* be able to use the private bucket, I'm not
sure how well that is exposed.
Certainly at this level, you just have a bunch of URLs, and you can't
just read from a private URL (you have to go through the provider which
has the auth credentials).
So maybe just for simple unification (each place you probe is just a
URL)?
https:/ /codereview. appspot. com/9128047/ diff/7001/ environs/ ec2/ec2. go
File environs/ec2/ec2.go (right):
https:/ /codereview. appspot. com/9128047/ diff/7001/ environs/ ec2/ec2. go#newcode361 ec2/ec2. go:361: // Add the simplestreams base URL off the
environs/
public bucket.
On 2013/05/16 08:59:11, fwereade wrote:
> Why not the private bucket?
When I chatted about this, it is because the immediate point where the
code wants to read the index files doesn't have the credentials to read
the private bucket.
However, when we discussed it, anything that wanted to start an actual
instance needs to have the credentials for the provisioner (compute) so
you would expect that it would have access to the data store (swift/s3).
So it seems like we *should* be able to use the private bucket, I'm not
sure how well that is exposed.
Certainly at this level, you just have a bunch of URLs, and you can't
just read from a private URL (you have to go through the provider which
has the auth credentials).
So maybe just for simple unification (each place you probe is just a
URL)?
https:/ /codereview. appspot. com/9128047/