Open Stack

Hi, Sergey!

Thanks for the info, but we are now to the point that should it be a
microversion bump or not. The users would love to have longer tags of
cause. But it seems too late to have a microversion for this cycle.
But will the DB migration be a problem? From 80 to 60?


On Tue, Jan 17, 2017 at 3:16 PM, Sergey Nikitin <snikitin at mirantis.com>
wrote:

> Hi, folks!
>
> I guess I found the reason of the problem. The first spec was created by
> Jay. At that moment I was just an implementer. In this spec we have a
> contradiction between lines #74 and #99.
> https://review.openstack.org/#/c/91444/16/specs/juno/tag-instances.rst
>
> Line 74 says "A tag shall be defined as a Unicode bytestring no longer
> than 60 bytes in length."
>
> Line 99 contains SQL instruction for migration "tag VARCHAR(80) NOT NULL
> CHARACTER SET utf8"
>
> It seems to me that everybody missed this contradiction and I just copy
> the whole migration script with length 80.
>
> So it's just an old mistake and I think we can change length of tag from
> 60 to 80.
>
> 2017-01-17 10:04 GMT+04:00 GHANSHYAM MANN <ghanshyammann at gmail.com>:
>
>> On Tue, Jan 17, 2017 at 2:37 PM, Alex Xu <soulxu at gmail.com> wrote:
>>
>>>
>>>
>>> 2017-01-17 10:26 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:
>>>
>>>> On 1/16/2017 7:12 PM, Zhenyu Zheng wrote:
>>>>
>>>>> Hi Nova,
>>>>>
>>>>> I just discovered something interesting, the tag has a limited length,
>>>>> and in the current implementation, it is 60 in the tag object
>>>>> definition:
>>>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/objec
>>>>> ts/tag.py#n18
>>>>>
>>>>> but 80 in the db model:
>>>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sq
>>>>> lalchemy/models.py#n1464
>>>>>
>>>>> As asked in the IRC and some of the cores responded(thanks to Matt and
>>>>> Jay), it seems to be an
>>>>> oversight and has no particular reason to do it this way.
>>>>>
>>>>> Since we have already created a 80 long space in DB and the current
>>>>> implementation might be confusing,  maybe we should expand the
>>>>> limitation in tag object definition to 80. Besides, users can enjoy
>>>>> longer tags.
>>>>>
>>>>> And the question could be, does anyone know why it is 60 in object but
>>>>> 80 in DB model? is it an oversight or we have some particular reason?
>>>>>
>>>>> If we could expand it to be the same as DB model (80 for both), it is
>>>>> ok
>>>>> to do this tiny change without microversion?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kevin Zheng
>>>>>
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>> As I said in IRC, the tags feature took a long time to land (several
>>>> releases) so between the time that the spec was written and then the data
>>>> model patch and finally the REST API change, we might have just totally
>>>> missed that the length of the column in the DB was different than what was
>>>> allowed in the REST API.
>>>>
>>>> I'm not aware of any technical reason why they are different. I'm
>>>> hoping that Sergey Nikitin might remember something about this. But even
>>>> looking at the spec:
>>>>
>>>> https://specs.openstack.org/openstack/nova-specs/specs/liber
>>>> ty/approved/tag-instances.html
>>>>
>>>> The column was meant to be 60 so my guess is someone noticed that in
>>>> the REST API review but missed it in the data model review.
>>>>
>>>
>>> I can't remember the detail also. Hoping Sergey can remember something
>>> also.
>>>
>>>
>>>>
>>>> As for needing a microversion of changing this, I tend to think we
>>>> don't need a microversion because we're not restricting the schema in the
>>>> REST API, we're just increasing it to match the length in the data model.
>>>> But I'd like opinions from the API subteam about that.
>>>>
>>>>
>>> We still need microversion for the user to discover the max length
>>> between different cloud deployments.
>>>
>>
>> ​I agree that we still need microversion for this. As Alex mentioned,
>> otherwise it will be issue on interoperability.
>>
>> Can we just keep it 60 and change DB to match the same?
>>
>> -gmann
>>
>>>
>>>
>>>> --
>>>>
>>>> Thanks,
>>>>
>>>> Matt Riedemann
>>>>
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170117/e6feda5c/attachment.html>