Open Stack

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.

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?

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.

On Fri, Jun 9, 2017 at 6:03 AM, Paul Belanger <pabelanger at redhat.com> wrote:

> On Fri, Jun 09, 2017 at 05:20:03AM -0700, Kevin Benton wrote:
> > This was an intentional decision. One of the goals of OpenStack is to
> > provide consistency across different clouds and configurable defaults for
> > new tenants default rules hurts consistency.
> >
> > If I write a script to boot up a workload on one OpenStack cloud that
> > allows everything by default and it doesn't work on another cloud that
> > doesn't allow everything by default, that leads to a pretty bad user
> > experience. I would now need logic to scan all of the existing security
> > group rules and do a diff between what I want and what is there and have
> > logic to resolve the difference.
> >
> FWIW: While that argument is valid, the reality is every cloud provider
> runs a
> different version of operating system you boot up your workload on, so it
> is
> pretty much assume that every cloud is different out of box.
>
> What we do now in openstack-infra, is place expected cloud
> configuration[2] in
> ansible-role-cloud-launcher[1], and run ansible against the cloud. This
> has been
> one of the ways we ensure consistency between clouds. Bonus point, we
> build and
> upload images daily to ensure our workloads are also the same.
>
> [1] http://git.openstack.org/cgit/openstack/ansible-role-cloud-launcher
> [2] http://git.openstack.org/cgit/openstack-infra/system-config/
> tree/playbooks/clouds_layouts.yml
>
> > It's a backwards-incompatible change so we'll probably be stuck with the
> > current behavior.
> >
> >
> > On Fri, Jun 9, 2017 at 2:27 AM, Ahmed Mostafa <ahmedmostafadev at gmail.com
> >
> > wrote:
> >
> > > I believe that there are no features impelemented in neutron that
> allows
> > > changing the rules for the default security group.
> > >
> > > I am also interested in seeing such a feature implemented.
> > >
> > > I see only this blueprint :
> > >
> > > https://blueprints.launchpad.net/neutron/+spec/default-
> > > rules-for-default-security-group
> > >
> > > But no work has been done on it so far.
> > >
> > >
> > >
> > > On Fri, Jun 9, 2017 at 9:16 AM, Paul Schlacter <wlfightup at gmail.com>
> > > wrote:
> > >
> > >>     I see the neutron code, which added the default rules to write
> very
> > >> rigid, only for ipv4 ipv6 plus two rules. What if I want to customize
> the
> > >> default rules?
> > >>
> > >> ____________________________________________________________
> > >> ______________
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscrib
> > >> e
> > >> 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
> > >
> > >
>
> > ____________________________________________________________
> ______________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170609/15859e6e/attachment.html>