Open Stack

I don't see too much benefit in turning on FWaaS in Havana, but we would
definitely want this to be considered for the master/Icehouse branch. The
FWaaS support leverages the Neutron L3 agent footprint, and my
understanding is that there were efforts underway to stabilize this L3
agent code. If required, we can wait until this stabilization effort around
the L3 agent is finished before we turn q-fwaas so as to avoid having an
additional variable to track at the gate. If this is not a concern, we can
turn on q-fwaas right away.

Thanks,
~Sumit.


On Mon, Dec 30, 2013 at 9:49 AM, Clark Boylan <clark.boylan at gmail.com>wrote:

> On Mon, Dec 30, 2013 at 12:17 AM, Sumit Naiksatam
> <sumitnaiksatam at gmail.com> wrote:
> > Yair, The FWaaS tempest tests were not planned for H release. They are
> > planned for the current release (hence the blueprint) and some of us were
> > working towards them. This is also a standing discuss item this during
> the
> > the FWaaS sub team meetings.
> >
> > Thanks,
> > ~Sumit.
> >
> >
> > On Sun, Dec 29, 2013 at 2:41 PM, Salvatore Orlando <sorlando at nicira.com>
> > wrote:
> >>
> >> I reckon the decision of keeping neutron's firewall API out of gate
> tests
> >> was reasonable for the Havana release.
> >> I might be argued the other 'experimental' service, VPN, is already
> >> enabled on the gate, but that did not happen before proving the feature
> was
> >> reliable enough to not cause gate breakage.
> >>
> >> If we can confidently say the same for the firewall extension now, I
> would
> >> agree on enabling it on gate tests as well.
> >>
> >> Salvatore
> >>
> >>
> >> On 29 December 2013 22:22, Yair Fried <yfried at redhat.com> wrote:
> >>>
> >>> Hi,
> >>> I'm trying to push a firewall api test [1] and I see it cannot run on
> the
> >>> current gate.
> >>> I was FWaaS is disabled since it broke the gate.
> >>> Does anyone knows if this is still an issue?
> >>> If so - how do we overcome this?
> >>> I would like to do some work on this service (scenarios) and don't want
> >>> to waste time if this is something that cannot be done right now
> >>>
> >>> Thank you
> >>> Yair
> >>>
> >>> [1] https://review.openstack.org/64362
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-Infra mailing list
> > OpenStack-Infra at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >
>
> There was a change [0] proposed to enable q-fwaas in devstack-gate,
> but it also enabled the service on the Havana branch which is
> problematic because as I understand it adding extra neutron services
> to the Havana gate broke things [1] and fwaas isn't ready in Havana.
> If we want to enable this service we should only do so on the master
> branch (feel free to update that change I can restore it), or if I am
> mistaken about the state of things in the Havana gate let me know and
> we can restore that change as is.
>
> [0] https://review.openstack.org/#/c/60149/
> [1] https://review.openstack.org/#/c/48793/
>
> Clark
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131230/ae3ad70c/attachment.html>