Azure provider: return a signed URL

Azure provider: return a signed URL

This branch changes the implementation of the URL() method in storage.go so that it returns a "signed" URL that can be anonymously accessed.  This allows uploading the tools to a private container while still allowing the machines to fetch the tools anonymously.

Drive-by fix 1: improve the prefix used to name machines for better readability.

Drive-by fix 2: return error instead of nil when the error is != nil in {delete/create}VirtualNetwork and {delete/create}AffinityGroup.

https://code.launchpad.net/~rvb/juju-core/use-signed-url/+merge/177126

(do not edit description out of merge proposal)

[rvb, 2013-07-26 10:26:18]

Please take a look.

[jtv.canonical, 2013-07-26 10:49:38]

LGTM as it's definitely an improvement.  Silly mistake to make, but it's the
sort of thing that happens when the language forces so much mindless repetition
on you.  It happened in a lot of places, but that's a more likely outcome of the
repetitive error-passing chore than "automatically having to think about it" is.

Julian tends to test all such error paths when he works on gwacl, and that would
have caught these mistakes, but frankly it's just not feasible to keep that
practice up in an application of this size and complexity.  Much like assembly
languages or (in this day and age) C, I wouldn't recommend writing an entire
application in a labour-intensive systems language like this — only bits and
pieces that really benefit from it.

The lifetime of 10 years for public URLs seems generous: IIRC we only support
LTS Server for 7 years.

I do have one note on something that I think could be improved.  Don't forget
idempotency for deletion operations!  If you're deleting something that isn't
there, that's success, not failure.

[rvb, 2013-07-26 10:54:19]

On 2013/07/26 10:49:38, jtv.canonical wrote:
> LGTM as it's definitely an improvement.  Silly mistake to make, but it's the
> sort of thing that happens when the language forces so much mindless
repetition
> on you.  It happened in a lot of places, but that's a more likely outcome of
the
> repetitive error-passing chore than "automatically having to think about it"
is.
> 
> Julian tends to test all such error paths when he works on gwacl, and that
would
> have caught these mistakes, but frankly it's just not feasible to keep that
> practice up in an application of this size and complexity.  Much like assembly
> languages or (in this day and age) C, I wouldn't recommend writing an entire
> application in a labour-intensive systems language like this — only bits and
> pieces that really benefit from it.

My thoughts, exactly.

> The lifetime of 10 years for public URLs seems generous: IIRC we only support
> LTS Server for 7 years.

I like to be generous :)

> I do have one note on something that I think could be improved.  Don't forget
> idempotency for deletion operations!  If you're deleting something that isn't
> there, that's success, not failure.

That's handled on the gwacl side: deleting a Virtual Network or an Affinity
Group which does not exist is not an error.

[rog, 2013-07-29 08:00:41]

LGTM