Open Stack

Does this fix your issue? https://review.openstack.org/#/c/475445/

On Mon, Jun 19, 2017 at 12:21 AM, Gary Kotton <gkotton at vmware.com> wrote:

> Sorry for being vague – have been debugging.
>
> We overwrite the base method:
>
>
>
>             with db_api.context_manager.writer.using(context):
>
>                     secgroup_db = (
>
>                         super(NsxV3Plugin, self).create_security_group(
>
>                             context, security_group, default_sg))
>
>                     nsx_db.save_sg_mappings(context,
>
>                                             secgroup_db['id'],
>
>                                             ns_group['id'],
>
>                                             firewall_section['id'])
>
>                     self._process_security_group_
> properties_create(context,
>
>
> secgroup_db,
>
>
> secgroup,
>
>
> default_sg)
>
>
>
> The secgroup_db that returns always has empty rules. If I remove the
> transaction then it works.
>
> Still trying to figure out why when we call:
>
>             with db_api.context_manager.writer.using(context):
>
>                     secgroup_db = (
>
>                         super(NsxV3Plugin, self).create_security_group(…
>
>
>
> The rules are not populated. The db_api.context_manager.writer.using is
> what is causing the problem.
>
>
>
> As a work around we reread the object when we need to process the rules.
> Not sure if anyone else has hit this
>
> Thanks
>
> Gary
>
>
>
> *From: *Kevin Benton <kevin at benton.pub>
> *Reply-To: *OpenStack List <openstack-dev at lists.openstack.org>
> *Date: *Monday, June 19, 2017 at 10:01 AM
> *To: *OpenStack List <openstack-dev at lists.openstack.org>
> *Cc: *"isaku.yamahata at gmail.com" <isaku.yamahata at gmail.com>
> *Subject: *Re: [openstack-dev] [neutron] security group OVO change
>
>
>
> Do you mean the callback event for AFTER_CREATE is missing the rules when
> it's for default security groups?
>
>
>
> On Sun, Jun 18, 2017 at 4:44 AM, Gary Kotton <gkotton at vmware.com> wrote:
>
> Hi,
> That patch looks good. We still have an issue in that the create security
> groups does not return the list of the default rules.
> Thanks
> Gary
>
>
> On 6/17/17, 2:33 AM, "Isaku Yamahata" <isaku.yamahata at gmail.com> wrote:
>
>     It also broke networking-odl.
>     The patch[1] is needed to unbreak.
>     [1] https://review.openstack.org/#/c/448420/
>
>     necessary db info is taken from context.session.new.
>     But with OVO, those expunge themselves with create method.
>     Those info needs to be passed as callback argument.
>
>     Thanks,
>
>     On Fri, Jun 16, 2017 at 01:25:28PM -0700,
>     Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>
>     > To close the loop here,
>     >
>     > - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
>     > - we polished https://review.openstack.org/474575 to fix both
>     > vmware-nsx and heat issues
>     > - I also posted a patch for oslo.serialization for the bug that
>     > triggered MemoryError in heat gate:
>     > https://review.openstack.org/475052
>     > - the vmware-nsx adoption patch is at:
>     > https://review.openstack.org/#/c/474608/ and @boden is working on
> it,
>     > should be ready to go in due course.
>     >
>     > Thanks and sorry for inconveniences,
>     > Ihar
>     >
>     > On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton <gkotton at vmware.com>
> wrote:
>     > > Hi,
>     > >
>     > > The commit https://review.openstack.org/284738 has broken
> decomposed plugins
>     > > (those that extend security groups and rules). The reason for this
> is that
>     > > there is a extend callback that we use which expects to get a
> database
>     > > object and the aforementioned patch passes a new neutron object.
>     > >
>     > > I have posted [i] to temporarily address the issue. An alternative
> is to
>     > > revert the patch until the decomposed plugins can figure out how to
>     > > correctly address this.
>     > >
>     > > Thanks
>     > >
>     > > Gary
>     > >
>     > > [i] https://review.openstack.org/474575
>     > >
>     > >
>     > > ____________________________________________________________
> ______________
>     > > 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
>
>     --
>     Isaku Yamahata <isaku.yamahata at gmail.com>
>
>     ____________________________________________________________
> ______________
>     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/20170620/237dd2da/attachment.html>