Gary Kotton <gkot...@vmware.com> wrote: > Would it be worth considering have the three patches: > https://review.openstack.org/399891, https://review.openstack.org/398113 > and https://review.openstack.org/398489 based one on top of the other. > Then all sub projects could take the top of the commit and base on top of > that. That may make the process a little more efficient.
The problem is that the ExtensionDescriptor change has its own specific order in which the patches must be done, as explained in http://lists.openstack.org/pipermail/openstack-dev/2016-November/108005.html My recommendation is that ExtensionDescriptor be done first. Then we could stage the PLURALS and _FIELD_SIZES as you suggest, but the PLURALS change is quite independent, so it could be done in parallel with ExtensionDescriptor. Once ExtensionDescriptor, PLURALS and _FIELD_SIZES are done, then we will be in a position to remove attributes.py from core neutron. That is the aim of this little dance. > Thanks > Gary > > > > > On 11/26/16, 9:03 AM, "Henry Gessau" <hen...@gessau.net> wrote: > > The following _MAX_LEN constants are being removed from > neutron/api/v2/attributes.py in [1]. The corresponding DB field size > constants from neutron_lib.db.constants should be used instead. > > All subproject maintainers should update their code to use the > the db *_FIELD_SIZE constants from neutron-lib. > > I have submitted patches [2] for most subprojects. > > NAME_MAX_LEN --> NAME_FIELD_SIZE > TENANT_ID_MAX_LEN --> PROJECT_ID_FIELD_SIZE > DESCRIPTION_MAX_LEN --> DESCRIPTION_FIELD_SIZE > LONG_DESCRIPTION_MAX_LEN --> LONG_DESCRIPTION_FIELD_SIZE > DEVICE_ID_MAX_LEN --> DEVICE_ID_FIELD_SIZE > DEVICE_OWNER_MAX_LEN --> DEVICE_NAME_FIELD_SIZE > > In alembic migration scripts, the raw numerical value shall be used. > > For more information, see [3]. > > [1] https://review.openstack.org/399891 > [2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes > [3] > http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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