[Openstack] [openstack-dev] About fix of validate name string length at API level

Kevin Benton blak111 at gmail.com
Fri Feb 6 08:45:09 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150206/ea3ad933/attachment.html>


More information about the Openstack mailing list