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 <[email protected]> > To: Akihiro Motoki <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Openstack] [openstack-dev] About fix of validate name > string length at API level > Message-ID: > <[email protected]. > 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 <[email protected]> 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 <[email protected]>: > > > 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:[email protected]] > > >> 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" <[email protected] > > >> <mailto:[email protected]> > 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: > > >> [email protected]?subject:unsubscribe > > >> > <http://[email protected]?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 : [email protected] > > > Unsubscribe : > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > -- > > Akihiro Motoki <[email protected]> > > > > _______________________________________________ > > Mailing list: > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : [email protected] > > Unsubscribe : > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > -- > Kevin Benton _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
