Open Stack

Hello, Kevin Benton, Akihiro Motoki
Cc: Maru Newby, Mark McClain
Cc: Assaf Muller, Armando Migliaccio, Oleg Bondarev, Toshiaki Higuchi
Cc: Carl Baldwin, Aaron Rosen, Paul Michali, Rossella Sblendido

Thank you for your advices and comments.

Regarded to the comment of Maru Newby in Patch set 6 of this fix [1].
What is everyone's idea about it, please?
1) Is the hard resetting like patch set 6 ok?
2) Or create a helper like "def reset_global_maximum_string_field_length(self, do_reset=False)" and recall from non-DB plugin better?
3) Or any other way like suggested in Akihiro Motoki's mail before?

[1] https://review.openstack.org/#/c/145660/

Also, I have another question.
About the understanding of non-db backend plugin.
I have looked through all plugins and found that the following plugins have no db module.
If any of the plugins is not a non-db backend plugin, please correct me.
- embrane
- ibm
- midonet
- mlnx
- ofagent
- opencontrail
- plumgrid
- sriovnicagent

Best regards,
Watanabe.isao


> ------------------------------
> 
> Message: 27
> Date: Fri, 6 Feb 2015 00:45:09 -0800
> From: Kevin Benton <blak111 at gmail.com>
> To: Akihiro Motoki <amotoki at gmail.com>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [Openstack] [openstack-dev] About fix of validate name
> 	string length at API level
> Message-ID:
> 	<CAO_F6JOgUCVoXfu6nxgCeKhsPqTXGwUb5njv7-7=yh=GusDZhw at mail.gmail.
> com>
> Content-Type: text/plain; charset="utf-8"
> 
> I think as we start moving these validations to the API, we should probably
> just enforce them across all plugins. Having conditionals in the API to
> check if the DB is there to change validation logic doesn't sound like much
> fun to maintain.
> 
> On Thu, Feb 5, 2015 at 1:22 AM, Akihiro Motoki <amotoki at gmail.com> wrote:
> 
> > It is a good idea to enforce some validations for string fields.
> > As Kevin said, Contrail plugin does not use db-backend but the API
> > layer is still used,
> > so attrbiutes.py works in the API layer, so we need to coordinate the
> > effort.
> >
> > In addition, Neutron API v2.0 is an already shipped version. so we
> > have several choice:
> > - Keep the behavior unchanged
> > - Always enforce string validation (it affects non-db backend plugins)
> > - Enforce string validation conditionally
> >   There are several possible options to control the condition:
> >   - new configuration option which controls string field validation is
> > enforced
> >   - query corresponding plugins (core, l3, service plugins) if it
> > requires string validation
> >   - some other dynamic detection?
> >
> > In the next version of Neutron (v2.1 or v3), we should have more
> > consistent validations
> > on string fields too.
> >
> > > If there is a DB that can be detected (something like sql.true()), we
> > set 255 to name validate, otherwise we leave it as None.
> > > How do you like this idea?
> >
> > Regarding your idea, I haven't understood how your idea works.
> > sqlalchemy is always installed on neutron-server and sql.true() just
> > returns a constant.
> > In addition, it depends on db backend but if [database] connection is
> > set when non-db
> > backend it does not work. Previously [database] connection config
> > pramater is just ignored
> > so it can still change the behavior.
> >
> > Akihiro
> >
> > 2015-01-30 10:33 GMT+09:00 Zou, Yun <zou.yun at jp.fujitsu.com>:
> > > To: Kevin Benton
> > > To: Mark McClain,
> > > Cc: Akihiro Motoki
> > >
> > > Hello, Kevin Benton. Thank you for the reply.
> > > I have an idea.
> > > If there is a DB that can be detected (something like sql.true()), we
> > set 255 to name validate, otherwise we leave it as None.
> > > How do you like this idea?
> > >
> > > Best regards,
> > > watanabe.isao
> > >
> > >> -----Original Message-----
> > >> From: Kevin Benton [mailto:blak111 at gmail.com]
> > >> Sent: Monday, January 26, 2015 1:56 PM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] About fix of validate name string length
> > at API
> > >> level
> > >>
> > >> Devstack may not install neutron without a database backend, but that's
> > just
> > >> a side effect of devstack. If I recall correctly, the contrail plugin
> > does
> > >> not use the DB at all to service the API calls, so that would be an
> > example
> > >> of a non-db plugin that you would have to consider.
> > >>
> > >> So the concern here would be that putting this new constraint at the
> > API layer
> > >> would break long names on something like the contrail plugin when they
> > could
> > >> have been working before.
> > >>
> > >> IMO, putting some restrictions on what can go into an arbitrary Neutron
> > >> installation for fields like this is a better experience for
> > users/deployers.
> > >> However, we should probably do it in a coordinated effort (i.e.
> > restrict them
> > >> all simultaneously) rather than slowly trickling in restrictions across
> > >> several releases.
> > >>
> > >> On Jan 25, 2015 8:40 PM, "Zou, Yun" <zou.yun at jp.fujitsu.com
> > >> <mailto:zou.yun at jp.fujitsu.com> > wrote:
> > >>
> > >>
> > >>       To: Mark McClain
> > >>       Cc: Akihiro Motoki
> > >>       Cc: Assaf Muller, Armando Migliaccio, Oleg Bondarev, Toshiaki
> > >> Higuchi
> > >>       Cc: Carl Baldwin, Aaron Rosen, Paul Michali, Rossella Sblendido
> > >>
> > >>       Hello, Mark McClain. I'm working on a bug fix [1] of validate name
> > >> string length at API level.
> > >>       This fix let neutron return 400 BadRequest Error instead of
> > internal
> > >> 500 DB Error in an user operation.
> > >>       Then, Akihiro Motoki kindly told me that he worked on a similar
> > issue
> > >> [2], and you have reminded him about non-db backend plugin.
> > >>       I would like to take a consensus about this non-db backend plugin
> > >> issue, before I move on my work.
> > >>       I have looked at the code of devstack [3], and it shows that
> > neutron
> > >> API server will not be installed if there is not any $DATABASE_BACKENDS
> > been
> > >> enabled.
> > >>       So I don't know what should we really take care about in this fix.
> > >>       Could you tell me your original concern or the picture you are
> > imaging,
> > >> please?
> > >>
> > >>       [1] https://review.openstack.org/#/c/145660/
> > >>       [2] https://review.openstack.org/#/c/84708/
> > >>       [3] http://docs.openstack.org/developer/devstack/stack.sh.html
> > >>
> > >>       Best regards,
> > >>       watanabe.isao
> > >>
> > >>
> > >>
> ________________________________________________________________
> > >> __________
> > >>       OpenStack Development Mailing List (not for usage questions)
> > >>       Unsubscribe:
> > >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >>
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de
> > >> v
> > >>
> > >
> > > _______________________________________________
> > > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > > Post to     : openstack at lists.openstack.org
> > > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
> >
> > --
> > Akihiro Motoki <amotoki at gmail.com>
> >
> > _______________________________________________
> > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to     : openstack at lists.openstack.org
> > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> 
> 
> 
> --
> Kevin Benton