New openstack use-default-secgroup option

New openstack use-default-secgroup option

Bug #1129720

Openstack environments can be configured to start
instances with the "default" security group assigned.
The new use-default-secgroup config option (default false)
is used to enable this behaviour.

https://code.launchpad.net/~wallyworld/juju-core/instance-default-secgroup/+merge/199929

(do not edit description out of merge proposal)

[wallyworld, 2013-12-23 00:51:04]

Please take a look.

[fwereade, 2014-01-02 09:41:46]

I'm just ignorant, I'm sure, but I don't see what we gain by making this
configurable. What do we lose by just *always* adding the default security
group?

https://codereview.appspot.com/44770044/diff/1/cmd/juju/help_topics.go
File cmd/juju/help_topics.go (right):

https://codereview.appspot.com/44770044/diff/1/cmd/juju/help_topics.go#newcode99
cmd/juju/help_topics.go:99: # use-default-secgroup: false
Thanks for documenting this, but I feel little the wiser.

[gz, 2014-01-09 12:56:35]

I added a comment to bug 1129720 about the general approach.

I agree with William that adding more config here isn't really desirable, but
just putting the default group on all machines juju creates is a step back in
our general isolation level. The per-environment security group is a much
cleaner place to add custom rules, even if we don't supply a juju command for
doing that (though we could).

Code itself looks fine.

[fwereade, 2014-01-09 19:48:46]

On 2014/01/09 12:56:35, gz wrote:
> I added a comment to bug 1129720 about the general approach.
> 
> I agree with William that adding more config here isn't really desirable, but
> just putting the default group on all machines juju creates is a step back in
> our general isolation level. The per-environment security group is a much
> cleaner place to add custom rules, even if we don't supply a juju command for
> doing that (though we could).
> 
> Code itself looks fine.

I dunno, I think there's quite a neat separation between the default security
group -- with whatever cloud-specific rules, considered appropriate by the
administrator, that are kinda outside our purview -- and our own config. What's
the use case for *not* including the default security group? Nobody's needed it
before, sure; but the default behaviour doesn't look harmful, and if that's been
changed it seems reasonable to assume it's been done for a reason. Right?

Sorry for the delay, Ian, I had an all-day power cut -- can we chat about this
tomorrow morning? I'm fine with the code, indeed, but I feel like including that
security group is the correct default, and I'd be happiest of all if we just
skipped the config, but I'll accept pretty much any plausible use case that
requires its falsity as justification for including the setting.

[fwereade, 2014-01-10 08:28:07]

On 2014/01/09 19:48:46, fwereade wrote:
> On 2014/01/09 12:56:35, gz wrote:
> > I added a comment to bug 1129720 about the general approach.
> > 
> > I agree with William that adding more config here isn't really desirable,
but
> > just putting the default group on all machines juju creates is a step back
in
> > our general isolation level. The per-environment security group is a much
> > cleaner place to add custom rules, even if we don't supply a juju command
for
> > doing that (though we could).
> > 
> > Code itself looks fine.
> 
> I dunno, I think there's quite a neat separation between the default security
> group -- with whatever cloud-specific rules, considered appropriate by the
> administrator, that are kinda outside our purview -- and our own config.
What's
> the use case for *not* including the default security group? Nobody's needed
it
> before, sure; but the default behaviour doesn't look harmful, and if that's
been
> changed it seems reasonable to assume it's been done for a reason. Right?
> 
> Sorry for the delay, Ian, I had an all-day power cut -- can we chat about this
> tomorrow morning? I'm fine with the code, indeed, but I feel like including
that
> security group is the correct default, and I'd be happiest of all if we just
> skipped the config, but I'll accept pretty much any plausible use case that
> requires its falsity as justification for including the setting.

LGTM after discussion -- we've been fine without it so far, so let's stick with
the existing default. Thanks for bearing with me.