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 <sniki...@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 <ghanshyamm...@gmail.com>: > >> On Tue, Jan 17, 2017 at 2:37 PM, Alex Xu <sou...@gmail.com> wrote: >> >>> >>> >>> 2017-01-17 10:26 GMT+08:00 Matt Riedemann <mrie...@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-requ...@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-requ...@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-requ...@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-requ...@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-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