[openstack-dev] [neutron] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

Gary Kotton gkotton at vmware.com
Mon Nov 28 08:30:24 UTC 2016


Ok, makes sense. Lets continue as you proposed.

On 11/27/16, 10:44 PM, "Henry Gessau" <HenryG at gessau.net> wrote:

    Gary Kotton <gkotton at 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" <HenryG at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    



More information about the OpenStack-dev mailing list