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....@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  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 , > 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 , 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? > >  https://review.openstack.org/#/c/145660/ >  https://review.openstack.org/#/c/84708/ >  http://docs.openstack.org/developer/devstack/stack.sh.html > > Best regards, > watanabe.isao > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev