Add EnvironCapability to state.Policy

Add EnvironCapability to state.Policy

environs.EnvironCapability is moved to the
state package, extended with the
SupportsUnitPlacement method, and added to
the state.Policy interface.

Methods for creating machines and assigning
units to them are now modified to use the
SupportsUnitPlacement method to enable
policy implementations to block adding of
empty machines (juju add-machine) and to
block unit placement (deploy/add-unit --to).

Also, a new EnvironBase type is added to
provider/common, which implements some
default behaviour common to all providers
such as the new SupportsUnitPlacement
method.

A followup will override the default
behaviour of SupportsUnitPlacement in the
Azure provider, blocking placement if in
availability-sets-enabled mode.

https://code.launchpad.net/~axwalk/juju-core/state-environcapability/+merge/211749

(do not edit description out of merge proposal)

[axw, 2014-03-19 14:52:09]

Please take a look.

[fwereade, 2014-03-19 15:15:17]

LGTM. Don't quite love the "Base" name but I guess its semantic payload is close
enough to reality that I'm not going to fight it. If you can think of something
better, though...

[hduran, 2014-03-19 18:37:43]

On 2014/03/19 15:15:17, fwereade wrote:
> LGTM. Don't quite love the "Base" name but I guess its semantic payload is
close
> enough to reality that I'm not going to fight it. If you can think of
something
> better, though...

You could user Common instead of Base altough I am not sure if it represents
correctly reality

[axw, 2014-03-20 03:32:47]

On 2014/03/19 18:37:43, hduran wrote:
> On 2014/03/19 15:15:17, fwereade wrote:
> > LGTM. Don't quite love the "Base" name but I guess its semantic payload is
> close
> > enough to reality that I'm not going to fight it. If you can think of
> something
> > better, though...
> 
> You could user Common instead of Base altough I am not sure if it represents
> correctly reality

Kind of, but not really. Some providers may override the behaviour.

After discussing with rogpeppe on IRC, I decided to replace EnvironBase
with two types: NopPrechecker and DoesSupportUnitPlacement. They're
more specific, and have non-generic names to imply non-changing behaviour.
If we just use "DefaultPrechecker" then someone may change the default
behaviour without considering how it affects one of the providers.

[axw, 2014-03-20 03:36:02]

Please take a look.

[fwereade, 2014-03-24 09:45:56]

LGTM modulo further naming quibbles which I will leave to your judgment.

https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go
File provider/azure/environ.go (right):

https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go#...
provider/azure/environ.go:55: common.DoesSupportUnitPlacement
Not honestly loving these names either (although they're certainly better).
Would you be OK tacking "Policy" onto those names to make their intent a little
clearer to the reader? Alternatively, tell me that's a stupid idea, and go ahead
with what you have.

[axw, 2014-03-24 14:46:38]

Please take a look.

https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go
File provider/azure/environ.go (right):

https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go#...
provider/azure/environ.go:55: common.DoesSupportUnitPlacement
On 2014/03/24 09:45:57, fwereade wrote:
> Not honestly loving these names either (although they're certainly better).
> Would you be OK tacking "Policy" onto those names to make their intent a
little
> clearer to the reader? Alternatively, tell me that's a stupid idea, and go
ahead
> with what you have.

Renamed NopPrechecker to NopPrecheckerPolicy, DoesSupportUnitPlacement to
SupportsUnitPlacementPolicy.

[fwereade, 2014-03-27 12:29:50]

On 2014/03/24 14:46:38, axw wrote:
> Please take a look.
> 
> https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go
> File provider/azure/environ.go (right):
> 
>
https://codereview.appspot.com/77820044/diff/20001/provider/azure/environ.go#...
> provider/azure/environ.go:55: common.DoesSupportUnitPlacement
> On 2014/03/24 09:45:57, fwereade wrote:
> > Not honestly loving these names either (although they're certainly better).
> > Would you be OK tacking "Policy" onto those names to make their intent a
> little
> > clearer to the reader? Alternatively, tell me that's a stupid idea, and go
> ahead
> > with what you have.
> 
> Renamed NopPrechecker to NopPrecheckerPolicy, DoesSupportUnitPlacement to
> SupportsUnitPlacementPolicy.

If that's all you did this still LGTM

[axw, 2014-04-03 03:42:37]

Please take a look.