Open Stack

On 03/02/2016 01:53 PM, Andrew Laski wrote:
> On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote:
>> Clearly, some operators and users disagree with the opinion that 'by
>> default security groups should closed off' given that we have several
>> large public providers who have changed these defaults (despite there
>> being no documented way to do so), and we have users in this thread
>> expressing that opinion. Given that, I am not sure there is any value
>> behind us expressing we have different opinions on what defaults
>> should be (let alone enforcing them by not allowing them to be
>> configured) unless there are some technical reasons beyond 'this is
>> not what my policy is, what my customers wants', etc. I also
>> understand the goal of trying to make clouds more similar for better
>> interoperability (and I think that is extremely important), but the
>> reality is we have created a situation where clouds are already not
>> identical here in an even worse, undocumented way because we are
>> enforcing a certain set of opinions here.
>>
>> To me this is an extremely clear indication that at a minimum the
>> defaults should be configurable since discussion around them seems to
>> devolve into different opinions on security policies, and there is no
>> way we should be in the business of dictating that.
>>
> +1. While I happen to agree with closed by default there are many others
> who feel differently, and there are cloud deployment scenarios where it
> may not be the reasonable default.
> It seems to me that visibility should be the primary focus. Make it easy
> for users to know what they're getting, and make it clear that it's
> something they should check rather than assume it's set a certain way.

++ And make it easy for them to choose the other thing.

(try writing an idempotent ansible playbook that tries to make your 
security group look exactly like you want it not knowing in advance what 
security group rules this provider happens to want to give you that you 
didn't think to explicitly look for.)

>> Cheers,
>> Greg
>> ____________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>