Open Stack

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>