Re: [openstack-dev] [neutron][db] online schema upgrades
my initial proposal for scripted expand/contract migrations is up:
https://review.openstack.org/#/c/192937/
On 6/18/15 5:54 AM, Anna Kamyshnikova wrote:
On Wed, Jun 17, 2015 at 8:23 PM, Mike Bayer mba...@redhat.com
mailto:mba...@redhat.com wrote:
On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:
Ihar, thanks for bringing this up!
This is very interesting and I think it worth trying. I'm +1 on
that and want to participate in this work.
Awesome.
In fact a lot *not strict* migrations are removed with
juno_initial, so I hope it won't be so hard for now to apply
stricter rules for migration. But what is the plan for those
migrations that are *not strict* now?
Still, we have several live data migrations from Juno to Kilo:
- - 14be42f3d0a5_default_sec_group_table.py: populates db with default
security groups;
- - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
extraqdhcpopts with default ip_version = 4;
- - 2d2a8a565438_hierarchical_binding.py: populates db with
port_binding_levels objects, then drops old tables;
- - 35a0f3365720_add_port_security_in_ml2.py: port security field is
populated with True for ports and networks;
- - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
column from subnetpools: probably unused so we can be ok with it?..
In any case, the plan for existing migration rules is: don't touch
them. Their presence in N release just indicates that we cannot get
online db migration in N+1. That's why we should adopt strict rules
the earlier the better, so that opportunity does not slip to N+X where
X is too far.
The patches currently in review that look suspicious in this regard are:
- - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
into another;
- - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
default server values (why is it even needed?..);
- - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
we are ok with it;
- - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
though since it touches existing live data impact rule?
I made a list of migrations from juno- kilo that are non
expansive or do data migrations:
*these contain drop column:*
034883111f_remove_subnetpool_allow_overlap.py
2d2a8a565438_hierarchical_binding.py
*these contain drop table:*
28c0ffb8ebbd_remove_mlnx_plugin.py
2b801560a332_remove_hypervneutronplugin_tables.py
408cfbf6923c_remove_ryu_plugin.py
57086602ca0a_scrap_nsx_adv_svcs_models.py
*these contain data migrations:*
14be42f3d0a5_default_sec_group_table.py
16cdf118d31d_extra_dhcp_options_ipv6_support.py
2b801560a332_remove_hypervneutronplugin_tables.py
2d2a8a565438_hierarchical_binding.py
35a0f3365720_add_port_security_in_ml2.py
*Example of failure:*
neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
- drops the following columns:
op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings',
'foreignkey')
op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
op.drop_column('ml2_dvr_port_bindings', 'segment')
op.drop_column('ml2_dvr_port_bindings', 'driver')
op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
op.drop_column('ml2_port_bindings', 'driver')
op.drop_column('ml2_port_bindings', 'segment')
which then causes a failure in Juno:
OperationalError: (OperationalError) (1054, Unknown column
'ml2_port_bindings_1.driver' in 'field list')
In M release we will be able to create kilo_initial migration that
will hide all these migrations(juno - kilo), so I as there is nothing
we can do we won't touch them as Ihar said. The problem about
migrations that are on review is more serious, as we should adopt
strict rules as early as possible and all core reviewer should be
aware about that.
To Ihar's list of migrations on review I can add :
I3426b13eede8bfa29729cf3efea3419fb91175c4 - insert some data,
I9cf36e1fd3a009c175e0d475af407a30f4e5c408 (almost ready to be merged!)
- drop tables.
And there are a lot changes with altering columns. One is merged in
neutron-vpnaas.
So we should decide these things quickly.
(the list can be incomplete)
I think that we should try to use Alembic as much we could as
Mike is going to support us in that and we have time to make
some change in Alembic directly.
Yes, sure, I'm looking forward to see Mike's proposal in public.
We should undoubtedly plan this work for M release because there
will be some issues that will appear in the process.
Sure. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2
Re: [openstack-dev] [neutron][db] online schema upgrades
On Wed, Jun 17, 2015 at 8:23 PM, Mike Bayer mba...@redhat.com wrote:
On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:
Ihar, thanks for bringing this up!
This is very interesting and I think it worth trying. I'm +1 on
that and want to participate in this work.
Awesome.
In fact a lot *not strict* migrations are removed with
juno_initial, so I hope it won't be so hard for now to apply
stricter rules for migration. But what is the plan for those
migrations that are *not strict* now?
Still, we have several live data migrations from Juno to Kilo:
- - 14be42f3d0a5_default_sec_group_table.py: populates db with default
security groups;
- - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
extraqdhcpopts with default ip_version = 4;
- - 2d2a8a565438_hierarchical_binding.py: populates db with
port_binding_levels objects, then drops old tables;
- - 35a0f3365720_add_port_security_in_ml2.py: port security field is
populated with True for ports and networks;
- - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
column from subnetpools: probably unused so we can be ok with it?..
In any case, the plan for existing migration rules is: don't touch
them. Their presence in N release just indicates that we cannot get
online db migration in N+1. That's why we should adopt strict rules
the earlier the better, so that opportunity does not slip to N+X where
X is too far.
The patches currently in review that look suspicious in this regard are:
- - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
into another;
- - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
default server values (why is it even needed?..);
- - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
we are ok with it;
- - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
though since it touches existing live data impact rule?
I made a list of migrations from juno- kilo that are non expansive or do
data migrations:
*these contain drop column:*
034883111f_remove_subnetpool_allow_overlap.py
2d2a8a565438_hierarchical_binding.py
*these contain drop table:*
28c0ffb8ebbd_remove_mlnx_plugin.py
2b801560a332_remove_hypervneutronplugin_tables.py
408cfbf6923c_remove_ryu_plugin.py
57086602ca0a_scrap_nsx_adv_svcs_models.py
*these contain data migrations:*
14be42f3d0a5_default_sec_group_table.py
16cdf118d31d_extra_dhcp_options_ipv6_support.py
2b801560a332_remove_hypervneutronplugin_tables.py
2d2a8a565438_hierarchical_binding.py
35a0f3365720_add_port_security_in_ml2.py
*Example of failure:*
neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
- drops the following columns:
op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings',
'foreignkey')
op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
op.drop_column('ml2_dvr_port_bindings', 'segment')
op.drop_column('ml2_dvr_port_bindings', 'driver')
op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
op.drop_column('ml2_port_bindings', 'driver')
op.drop_column('ml2_port_bindings', 'segment')
which then causes a failure in Juno:
OperationalError: (OperationalError) (1054, Unknown column
'ml2_port_bindings_1.driver' in 'field list')
In M release we will be able to create kilo_initial migration that will
hide all these migrations(juno - kilo), so I as there is nothing we can do
we won't touch them as Ihar said. The problem about migrations that are on
review is more serious, as we should adopt strict rules as early as
possible and all core reviewer should be aware about that.
To Ihar's list of migrations on review I can add :
I3426b13eede8bfa29729cf3efea3419fb91175c4 - insert some data,
I9cf36e1fd3a009c175e0d475af407a30f4e5c408 (almost ready to be merged!) -
drop tables.
And there are a lot changes with altering columns. One is merged in
neutron-vpnaas.
So we should decide these things quickly.
(the list can be incomplete)
I think that we should try to use Alembic as much we could as Mike
is going to support us in that and we have time to make some change
in Alembic directly.
Yes, sure, I'm looking forward to see Mike's proposal in public.
We should undoubtedly plan this work for M release because there
will be some issues that will appear in the process.
Sure.
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVgaL4AAoJEC5aWaUY1u57oZgH/34pgV7AqOiq4XnWOOmQ9HA9
jL+8E9jv8pUSW3X4v0Rm5mDuWJyWscrgy61Om+sWsmqBFAmm/gmLWm+NNADbYM5e
6hsoaO5WmuvRc03MwIwsa0NEgfPc8EhT5JiZmYRjOBc85ZCs6+UOKUHBAI2EVTg8
t8YKdTdzxlrZQEOng1lbsUQYkHnNUZTbsREnpangfaHXBk3xmilH/ebGsz3CRUCe
OBrpp6q8N7mgZgK/UQKb04eS5bCna7eVmv6q7PvIO0SlYhhDbrL3+dv/SZpqQWZ/
Hek2Oig0IYyPygVrGc4BpT9MIaKisGoxXMn1rRB2g8us8jM58VyzqgXwEH2H4Aw=
=TqHb
-END
Re: [openstack-dev] [neutron][db] online schema upgrades
On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:
Ihar, thanks for bringing this up!
This is very interesting and I think it worth trying. I'm +1 on
that and want to participate in this work.
Awesome.
In fact a lot *not strict* migrations are removed with
juno_initial, so I hope it won't be so hard for now to apply
stricter rules for migration. But what is the plan for those
migrations that are *not strict* now?
Still, we have several live data migrations from Juno to Kilo:
- - 14be42f3d0a5_default_sec_group_table.py: populates db with default
security groups;
- - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
extraqdhcpopts with default ip_version = 4;
- - 2d2a8a565438_hierarchical_binding.py: populates db with
port_binding_levels objects, then drops old tables;
- - 35a0f3365720_add_port_security_in_ml2.py: port security field is
populated with True for ports and networks;
- - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
column from subnetpools: probably unused so we can be ok with it?..
In any case, the plan for existing migration rules is: don't touch
them. Their presence in N release just indicates that we cannot get
online db migration in N+1. That's why we should adopt strict rules
the earlier the better, so that opportunity does not slip to N+X where
X is too far.
The patches currently in review that look suspicious in this regard are:
- - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
into another;
- - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
default server values (why is it even needed?..);
- - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
we are ok with it;
- - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
though since it touches existing live data impact rule?
I made a list of migrations from juno- kilo that are non expansive or
do data migrations:
*these contain drop column:*
034883111f_remove_subnetpool_allow_overlap.py
2d2a8a565438_hierarchical_binding.py
*these contain drop table:*
28c0ffb8ebbd_remove_mlnx_plugin.py
2b801560a332_remove_hypervneutronplugin_tables.py
408cfbf6923c_remove_ryu_plugin.py
57086602ca0a_scrap_nsx_adv_svcs_models.py
*these contain data migrations:*
14be42f3d0a5_default_sec_group_table.py
16cdf118d31d_extra_dhcp_options_ipv6_support.py
2b801560a332_remove_hypervneutronplugin_tables.py
2d2a8a565438_hierarchical_binding.py
35a0f3365720_add_port_security_in_ml2.py
*Example of failure:*
neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
- drops the following columns:
op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings', 'foreignkey')
op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
op.drop_column('ml2_dvr_port_bindings', 'segment')
op.drop_column('ml2_dvr_port_bindings', 'driver')
op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
op.drop_column('ml2_port_bindings', 'driver')
op.drop_column('ml2_port_bindings', 'segment')
which then causes a failure in Juno:
OperationalError: (OperationalError) (1054, Unknown column
'ml2_port_bindings_1.driver' in 'field list')
(the list can be incomplete)
I think that we should try to use Alembic as much we could as Mike
is going to support us in that and we have time to make some change
in Alembic directly.
Yes, sure, I'm looking forward to see Mike's proposal in public.
We should undoubtedly plan this work for M release because there
will be some issues that will appear in the process.
Sure.
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVgaL4AAoJEC5aWaUY1u57oZgH/34pgV7AqOiq4XnWOOmQ9HA9
jL+8E9jv8pUSW3X4v0Rm5mDuWJyWscrgy61Om+sWsmqBFAmm/gmLWm+NNADbYM5e
6hsoaO5WmuvRc03MwIwsa0NEgfPc8EhT5JiZmYRjOBc85ZCs6+UOKUHBAI2EVTg8
t8YKdTdzxlrZQEOng1lbsUQYkHnNUZTbsREnpangfaHXBk3xmilH/ebGsz3CRUCe
OBrpp6q8N7mgZgK/UQKb04eS5bCna7eVmv6q7PvIO0SlYhhDbrL3+dv/SZpqQWZ/
Hek2Oig0IYyPygVrGc4BpT9MIaKisGoxXMn1rRB2g8us8jM58VyzqgXwEH2H4Aw=
=TqHb
-END PGP SIGNATURE-
__
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
Re: [openstack-dev] [neutron][db] online schema upgrades
Ihar, thanks for bringing this up! This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work. In fact a lot *not strict* migrations are removed with juno_initial, so I hope it won't be so hard for now to apply stricter rules for migration. But what is the plan for those migrations that are *not strict* now? I think that we should try to use Alembic as much we could as Mike is going to support us in that and we have time to make some change in Alembic directly. We should undoubtedly plan this work for M release because there will be some issues that will appear in the process. On Tue, Jun 16, 2015 at 6:58 PM, Mike Bayer mba...@redhat.com wrote: On 6/16/15 11:41 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - instead of migrating data with alembic rules, migrate it in runtime. There should be a abstraction layer that will make sure that data is migrated into new schema fields and objects, while preserving data originally stored in 'old' schema elements. That would allow old neutron-server code to run against new schema (it will just ignore new additions); and new neutron-server code to gradually migrate data into new columns/fields/tables while serving user s. Hi Ihar - I was in the middle of writing a spec for neutron online schema migrations, which maintains expand / contract workflow but also maintains Alembic migration scripts. As I've stated many times in the past, there is no reason to abandon migration scripts, while there are many issues related to abandoning the notion of the database in a specific versioned state as well as the ability to script any migrations whatsoever. The spec amends Nova's approach and includes upstream changes to Alembic such that both approaches can be supported using the same codebase. - mike __ 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 -- Regards, Ann Kamyshnikova Mirantis, Inc __ 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
Re: [openstack-dev] [neutron][db] online schema upgrades
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/16/2015 05:58 PM, Mike Bayer wrote: On 6/16/15 11:41 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - instead of migrating data with alembic rules, migrate it in runtime. There should be a abstraction layer that will make sure that data is migrated into new schema fields and objects, while preserving data originally stored in 'old' schema elements. That would allow old neutron-server code to run against new schema (it will just ignore new additions); and new neutron-server code to gradually migrate data into new columns/fields/tables while serving user s. Hi Ihar - I was in the middle of writing a spec for neutron online schema migrations, which maintains expand / contract workflow but also maintains Alembic migration scripts. As I've stated many times in the past, there is no reason to abandon migration scripts, while there are many issues related to abandoning the notion of the database in a specific versioned state as well as the ability to script any migrations whatsoever. The spec amends Nova's approach and includes upstream changes to Alembic such that both approaches can be supported using the same codebase. I probably don't follow completely. It was not my intent to propose complete abandonment of migration scripts. In any case, eagerly waiting for your proposal in gerrit. :) Note that now that neutron process leans more to RFEs in Launchpad, it may be the case that a better place for the description of your proposal is in neutron's devref. Anyway, we'll see. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVgaKrAAoJEC5aWaUY1u574o0H/0C84GFx16w62k59UZEtLv/J jwf4dxxQi0tEx1+cGpmYje4Yn56KqMYPhuZ/woFmAJ4o2WWO+qLD9Mi4Mmc91MiD xY4oLbHriNmMoDpgzLoib17aOIbFSMuwi5fyBJUP8Hu2/3in1N5c0iuHIXnLV/i+ szB8LdJTd1FBIfbcQMPll1IZNCo0D4V+HGoFFtFQOcls9L4TAsEs8AkMR54zZXio MGhTGj+9VhxJlpL7k6zeCukVtdgFiqWzbWXUh+/fZuInhVnsWGMAxnr3cFEaTKmT 0Ju5Hf/9np4nmlKFpY7L5hxnGXyQjSlgRmuAAr/BlP5fvhuZrUxGRVp2ZoXoRXo= =QW/o -END PGP SIGNATURE- __ 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
Re: [openstack-dev] [neutron][db] online schema upgrades
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote: Ihar, thanks for bringing this up! This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work. Awesome. In fact a lot *not strict* migrations are removed with juno_initial, so I hope it won't be so hard for now to apply stricter rules for migration. But what is the plan for those migrations that are *not strict* now? Still, we have several live data migrations from Juno to Kilo: - - 14be42f3d0a5_default_sec_group_table.py: populates db with default security groups; - - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates extraqdhcpopts with default ip_version = 4; - - 2d2a8a565438_hierarchical_binding.py: populates db with port_binding_levels objects, then drops old tables; - - 35a0f3365720_add_port_security_in_ml2.py: port security field is populated with True for ports and networks; - - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap column from subnetpools: probably unused so we can be ok with it?.. In any case, the plan for existing migration rules is: don't touch them. Their presence in N release just indicates that we cannot get online db migration in N+1. That's why we should adopt strict rules the earlier the better, so that opportunity does not slip to N+X where X is too far. The patches currently in review that look suspicious in this regard are: - - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table into another; - - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with default server values (why is it even needed?..); - - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure we are ok with it; - - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue though since it touches existing live data impact rule? (the list can be incomplete) I think that we should try to use Alembic as much we could as Mike is going to support us in that and we have time to make some change in Alembic directly. Yes, sure, I'm looking forward to see Mike's proposal in public. We should undoubtedly plan this work for M release because there will be some issues that will appear in the process. Sure. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVgaL4AAoJEC5aWaUY1u57oZgH/34pgV7AqOiq4XnWOOmQ9HA9 jL+8E9jv8pUSW3X4v0Rm5mDuWJyWscrgy61Om+sWsmqBFAmm/gmLWm+NNADbYM5e 6hsoaO5WmuvRc03MwIwsa0NEgfPc8EhT5JiZmYRjOBc85ZCs6+UOKUHBAI2EVTg8 t8YKdTdzxlrZQEOng1lbsUQYkHnNUZTbsREnpangfaHXBk3xmilH/ebGsz3CRUCe OBrpp6q8N7mgZgK/UQKb04eS5bCna7eVmv6q7PvIO0SlYhhDbrL3+dv/SZpqQWZ/ Hek2Oig0IYyPygVrGc4BpT9MIaKisGoxXMn1rRB2g8us8jM58VyzqgXwEH2H4Aw= =TqHb -END PGP SIGNATURE- __ 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-dev] [neutron][db] online schema upgrades
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi neutron folks, I'd like to discuss a plan on getting support for online db schema upgrades in neutron. *What is it even about?* Currently, any major version upgrade, or master-to-master upgrade, requires neutron-server shutdown. After shutdown, operators apply db migration rules to their database (if any), and when it's complete, are able to start their neutron-server service(s). It has several drawbacks: - - while db is upgraded, API endpoints are not available (user visible out-of-service period); - - db upgrade may take a significant time, and the out-of-service period can become quite long. For rolling master-based environments, it's especially painful, since you get the scheduled offline time more often than once per 6 months. (Though even once per 6 months is not ideal.) *Proposal* Make neutron-server resilient to under-the-hood db schema changes. How can we achieve this? There are multiple things to touch both code- and culture-wise: - - if we want old neutron-server to continue working with db that is potentially upgraded to a newer schema, it means that we should stop applying non-additive changes to schema in migration rules. (Note that we still have a way to collect fossils once they are unused, e.g. during the next cycle). - - we should stop applying live data changes to database as part of migration rules. The only changes that should be allowed should touch schema but not insert/update/delete actual records. (I know neutron is especially guilty of it in the past, but I believe we can stop doing it. ) - - instead of migrating data with alembic rules, migrate it in runtime. There should be a abstraction layer that will make sure that data is migrated into new schema fields and objects, while preserving data originally stored in 'old' schema elements. That would allow old neutron-server code to run against new schema (it will just ignore new additions); and new neutron-server code to gradually migrate data into new columns/fields/tables while serving user s. Note that all neutron-server instances are still expected to restart at the same time. There should be no neutron-servers of different versions running, otherwise older instances will undo migration work applied by new ones, and it may result in data loss, db conflicts, hell raise. We may think of how to support iterative controller restart without any downtime, but that's out of scope of the proposal. *Isn't it too crazy?* Not really. Other projects achieved this already. Specifically, Nova does it since Liberty. Heat, Cinder are considering it now. Nova needed to stop doing data migrations or non-additive changes to schema in Kilo already. It suggests that the nearest possible time we get actual online migration in neutron is M; that's assuming we adopt stricter rules for migrations *now*, before anything incompatible is merged in Liberty. Also note that I haven't checked *aas migration rules yet: if there are incompatible changes there, it means that for setups that rely on those services, online migrations will become reality in Nausea only. Since neutron joins the game late, we are in better position than nova was, since a lot of tooling and practices are already implemented. Specifically, I mean oslo.versionedobjects that would serve as an abstraction object middleware in between db and the rest of neutron. *The plan for Liberty* We can't technically achieve online migrations in Liberty, for reasons stated above. It does not mean that we have nothing to do this cycle though. We should prepare ourselves doing the following: - - adopt stricter rules for migrations; - - adopt oslo.versionedobjects to represent neutron resources. (It will buy us more benefits, like object interface instead of passing dicts around; clear versioning on RPC side of things; potentially, assuming we apply corresponding practices, transparent remote calls to controller from agent side using the same objects defined on neutron-server side). === So, keeping in mind that there can be concerns or conflicts with existing efforts (f.e. plugin decomp part 2) that I don't fully realize, or maybe some architectural issues that would not allow us to start on the road just now, I'd like to hear from others on whether the strict rules even make sense in context of neutron. Of course, I especially look forward to hear from our db gods: Henry, Ann, and others. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVgEOpAAoJEC5aWaUY1u57rzIIAKg6tgJ23OUzEx9WEWly8Evy YCRRSYAPjgX5rQ8UY1BLIPEH1j/FAdbE7RKuHuW+b2fcsKafFbh7EqW0HkCy75w7 5cja5VKZMoZ8MzR4A3TyLfR0C1IQ6FB9U+ISgaaDyqjrp/2pmr6Sobv+f9gtT6IR viLASdvsFyC8fQOGPNNG4Q2I5mnl+q1l8oji6jxp1uL49PETdStH6R88h6LWYBJg lGztStcVcAq1l0WVVdhgnJU8UaSJVYzlkUkTxzWiHscd8JSelCgR+Zq7rc6bx6RY +5uDmk8ZGVXDZIz9TEZbP2KgaF9tcIhYCPajCqS5wHFoJj/8UTz1MdsaqjHBv6w= =J+iJ -END PGP SIGNATURE-
Re: [openstack-dev] [neutron][db] online schema upgrades
On 6/16/15 11:41 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - instead of migrating data with alembic rules, migrate it in runtime. There should be a abstraction layer that will make sure that data is migrated into new schema fields and objects, while preserving data originally stored in 'old' schema elements. That would allow old neutron-server code to run against new schema (it will just ignore new additions); and new neutron-server code to gradually migrate data into new columns/fields/tables while serving user s. Hi Ihar - I was in the middle of writing a spec for neutron online schema migrations, which maintains expand / contract workflow but also maintains Alembic migration scripts. As I've stated many times in the past, there is no reason to abandon migration scripts, while there are many issues related to abandoning the notion of the database in a specific versioned state as well as the ability to script any migrations whatsoever. The spec amends Nova's approach and includes upstream changes to Alembic such that both approaches can be supported using the same codebase. - mike __ 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
