[mq][mariadb] What kind of reasons are considered when choosing the mq/mariadb version
Hi all
We are using kolla to build the OpenStack, use kolla-ansible to deploy
rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release
rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release
what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?
what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?
If you can provide an explanation, or key explanation, we would be very grateful.
Thanks.
brinzhang
Hi Brin,
most of the time the distribution dictates the new version. However, sometimes it is forced due to issues with new versions of OpenStack and old versions of these dependencies (for example MariaDB 10.1 would fail to work with newer releases due to lack of MySQL compatibility). Newer versions usually mean new features that are useful for end users. In this case RabbitMQ 3.8 shines with its new Prometheus exporter. We generally try to avoid needless updates but still stay current enough to receive proper support from upstreams and satisfy the users.
-yoctozepto
On Fri, Sep 4, 2020 at 10:54 AM Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi all
We are using kolla to build the OpenStack, use kolla-ansible to deploy
rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release
rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release
what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?
what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?
If you can provide an explanation, or key explanation, we would be very grateful.
Thanks.
brinzhang
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
Prometheus exporter was depended on rabbitmq 3.8, so if vendor distribution doesn’t contain Prometheus, rabbitmq v3.7.10 would be ok or not ?
I suggest the community that it add a doc page about why openstack version chooses the common component like 'mq/db/memcache' version.
When openstack version is released , in addition to release note is published , community releases this doc page to statement the reason of the common component version choice.
thx
Sheldon Hu | 胡玉鹏
CBRD | 云计算与大数据研发部
T: 18663761785
E: huyp@inspur.com
浪潮电子信息产业股份有限公司
Inspur Electronic Information Industry Co.,Ltd.
山东省济南市历城区东八区企业公馆A7-1
Building A7-1, Dongbaqu Office Block, Licheng District, Jinan,Shandong Province, PRC 浪潮云海
-----邮件原件----- 发件人: Radosław Piliszek [mailto:radoslaw.piliszek@gmail.com] 发送时间: 2020年9月4日 18:16 收件人: Brin Zhang(张百林) zhangbailin@inspur.com 抄送: openstack-discuss@lists.openstack.org; Sheldon Hu(胡玉鹏) huyp@inspur.com 主题: Re: [mq][mariadb] What kind of reasons are considered when choosing the mq/mariadb version
Hi Brin,
most of the time the distribution dictates the new version. However, sometimes it is forced due to issues with new versions of OpenStack and old versions of these dependencies (for example MariaDB 10.1 would fail to work with newer releases due to lack of MySQL compatibility). Newer versions usually mean new features that are useful for end users. In this case RabbitMQ 3.8 shines with its new Prometheus exporter. We generally try to avoid needless updates but still stay current enough to receive proper support from upstreams and satisfy the users.
-yoctozepto
On Fri, Sep 4, 2020 at 10:54 AM Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi all
We are using kolla to build the OpenStack, use kolla-ansible to deploy
rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release
rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release
what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?
what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?
If you can provide an explanation, or key explanation, we would be very grateful.
Thanks.
brinzhang
Hi Sheldon,
On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) huyp@inspur.com wrote:
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
I just reviewed this and it was even earlier - in Train: https://bugs.launchpad.net/kolla/+bug/1841907 afair, some other projects also introduced such incompatibilities due to testing against MySQL.
-yoctozepto
Hi Radoslaw.
I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
"op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
brinzhang
Hi Sheldon,
On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) huyp@inspur.com wrote:
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
I just reviewed this and it was even earlier - in Train: https://bugs.launchpad.net/kolla/+bug/1841907 afair, some other projects also introduced such incompatibilities due to testing against MySQL.
-yoctozepto
Hi Brin,
the issue is that, per the bug report, MariaDB 10.1 cannot handle such changes to foreign keys: Cannot change column 'network_id': used in a foreign key constraint 'subnets_ibfk_1' It received support later.
Is there a particular reason you are trying to keep MariaDB 10.1?
-yoctozepto
On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi Radoslaw.
I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
"op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
brinzhang
Hi Sheldon,
On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) huyp@inspur.com wrote:
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
I just reviewed this and it was even earlier - in Train: https://bugs.launchpad.net/kolla/+bug/1841907 afair, some other projects also introduced such incompatibilities due to testing against MySQL.
-yoctozepto
Hi Brin,
the issue is that, per the bug report, MariaDB 10.1 cannot handle such changes to foreign keys:
Cannot change column 'network_id': used in a foreign key constraint 'subnets_ibfk_1'
It received support later.
Is there a particular reason you are trying to keep MariaDB 10.1?
No, we want to upgrade openstack release, but I don’t know upgrade MariaDB whether is necessary (used 10.1 now), your suggestion will be very helpful to our choice. Therefore, for features that are highly dependent, or bug fixes, further verification is required.
Thanks.
-yoctozepto
On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi Radoslaw.
I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
"op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
brinzhang
Hi Sheldon,
On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) huyp@inspur.com wrote:
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
I just reviewed this and it was even earlier - in Train: https://bugs.launchpad.net/kolla/+bug/1841907 afair, some other projects also introduced such incompatibilities due to testing against MySQL.
-yoctozepto
On Sun, 6 Sep 2020 at 09:06, Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi Brin,
the issue is that, per the bug report, MariaDB 10.1 cannot handle such changes to foreign keys:
Cannot change column 'network_id': used in a foreign key constraint 'subnets_ibfk_1'
It received support later.
Is there a particular reason you are trying to keep MariaDB 10.1?
No, we want to upgrade openstack release, but I don’t know upgrade MariaDB whether is necessary (used 10.1 now), your suggestion will be very helpful to our choice. Therefore, for features that are highly dependent, or bug fixes, further verification is required.
Hi Brin, as always it would be helpful to know exactly the problem you are facing, and if there is a reason why you are considering to choose a version of these key components that differs from the versions tested upstream. Are you using an external DB & MQ outside of kolla that you do not have control over?
Thanks.
-yoctozepto
On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi Radoslaw.
I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
"op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
brinzhang
Hi Sheldon,
On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) huyp@inspur.com wrote:
Thx for reply
As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
I just reviewed this and it was even earlier - in Train: https://bugs.launchpad.net/kolla/+bug/1841907 afair, some other projects also introduced such incompatibilities due to testing against MySQL.
-yoctozepto
participants (5)
-
Brin Zhang(张百林)
-
Mark Goddard
-
Radosław Piliszek
-
Sheldon Hu(胡玉鹏)
-
Tom Black