[openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

Anna Taraday akamyshnikova at mirantis.com
Mon Oct 17 14:27:27 UTC 2016


Ihar, we all adults here, but this does not save us from making silly
mistakes sometimes :(
I think that if we can protect from possible mistakes - lets do this, as
messing up with size of fields is a common issue.

On Mon, Oct 17, 2016 at 2:16 PM Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Henry Gessau <HenryG at gessau.net> wrote:
>
> > Anna Taraday <akamyshnikova at mirantis.com> wrote:
> >> Henry, thanks for taking care of this!
> >>
> >> In my opinion, it is just safe to use raw values in migration, because
> >> migration is a strict point in time.
> >>
> >> I remember how many patches I send in havana in Neutron for fixing
> >> synchronization issues. Usage constants everywhere can be good in this
> >> case,
> >> but ModelMigrationSyc did such check of this for us already.
> >>
> >> If we want to have constants everywhere, we should guarantee that they
> are
> >> unchanged - have test in neutron-lib which verifies their values.
> >
> > Yes, we could have some tests, although a patch changing a constant would
> > probably also have a change to the test. :) We might need to also have a
> > prominent "Warning! Do not change this test!" comment for each test.
>
> I actually think (or hope) everyone is adult here, and will be able to
> block a patch changing a constant, even if there is no unit test written,
> especially if we put such a warning in a comment above the constants we
> know are especially unsafe to touch.
>
> But if we are still think that it’s better safe than sorry, we could have
> some tests to make that even more explicit. It just seems like a waste of
> cpu cycles when any careful reviewer can spot such an issue.
>
> Anyhow, whatever works for the goal, that I think is: making constants safe
> to use in all relevant contexts, including alembic.
>
> Ihar
>
> __________________________________________________________________________
> 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
>
-- 
Regards,
Ann Taraday
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161017/4ce8d48c/attachment.html>


More information about the OpenStack-dev mailing list