Open Stack

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.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/0cad6f60/attachment.html>