<div dir="ltr">This isn't about the operating system of the instance or even the host. It's the behavior of the Neutron API WRT what traffic will be filtered by the default security group.<div><div><br></div><div>If we go down this route, users will have to expect effectively random sets of security group rules from cloud to cloud and manually inspect each one. If those are the semantics we want to provide, why have a default security group at all?</div></div><div><br></div><div>Is your suggestion that since clouds are already inconsistent, we should make it easier for operators to make it worse? It sounds silly, but the main supporting argument for this seems to be that operators are already breaking consistency using other scripts, etc so we shouldn't care.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 6:03 AM, Paul Belanger <span dir="ltr"><<a href="mailto:pabelanger@redhat.com" target="_blank">pabelanger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jun 09, 2017 at 05:20:03AM -0700, Kevin Benton wrote:<br>
> This was an intentional decision. One of the goals of OpenStack is to<br>
> provide consistency across different clouds and configurable defaults for<br>
> new tenants default rules hurts consistency.<br>
><br>
> If I write a script to boot up a workload on one OpenStack cloud that<br>
> allows everything by default and it doesn't work on another cloud that<br>
> doesn't allow everything by default, that leads to a pretty bad user<br>
> experience. I would now need logic to scan all of the existing security<br>
> group rules and do a diff between what I want and what is there and have<br>
> logic to resolve the difference.<br>
><br>
</span>FWIW: While that argument is valid, the reality is every cloud provider runs a<br>
different version of operating system you boot up your workload on, so it is<br>
pretty much assume that every cloud is different out of box.<br>
<br>
What we do now in openstack-infra, is place expected cloud configuration[2] in<br>
ansible-role-cloud-launcher[1]<wbr>, and run ansible against the cloud. This has been<br>
one of the ways we ensure consistency between clouds. Bonus point, we build and<br>
upload images daily to ensure our workloads are also the same.<br>
<br>
[1] <a href="http://git.openstack.org/cgit/openstack/ansible-role-cloud-launcher" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/ansible-role-cloud-<wbr>launcher</a><br>
[2] <a href="http://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/clouds_layouts.yml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/system-config/<wbr>tree/playbooks/clouds_layouts.<wbr>yml</a><br>
<div class="HOEnZb"><div class="h5"><br>
> It's a backwards-incompatible change so we'll probably be stuck with the<br>
> current behavior.<br>
><br>
><br>
> On Fri, Jun 9, 2017 at 2:27 AM, Ahmed Mostafa <<a href="mailto:ahmedmostafadev@gmail.com">ahmedmostafadev@gmail.com</a>><br>
> wrote:<br>
><br>
> > I believe that there are no features impelemented in neutron that allows<br>
> > changing the rules for the default security group.<br>
> ><br>
> > I am also interested in seeing such a feature implemented.<br>
> ><br>
> > I see only this blueprint :<br>
> ><br>
> > <a href="https://blueprints.launchpad.net/neutron/+spec/default-" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/neutron/+spec/default-</a><br>
> > rules-for-default-security-<wbr>group<br>
> ><br>
> > But no work has been done on it so far.<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Jun 9, 2017 at 9:16 AM, Paul Schlacter <<a href="mailto:wlfightup@gmail.com">wlfightup@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> >>     I see the neutron code, which added the default rules to write very<br>
> >> rigid, only for ipv4 ipv6 plus two rules. What if I want to customize the<br>
> >> default rules?<br>
> >><br>
> >> ______________________________<wbr>______________________________<br>
> >> ______________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscrib" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscrib</a><br>
> >> e<br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> >><br>
> >><br>
> ><br>
> > ______________________________<wbr>______________________________<wbr>______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> ><br>
> ><br>
<br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>