| 2015-12-15 19:24:14 |
Ryan Beisner |
bug |
|
|
added bug |
| 2015-12-15 19:27:52 |
Ryan Beisner |
description |
The one-shot specs are hard-coded to 10.5.0.0/16, rather than consuming the VIP and other network env vars that are passed by the test environment. This means that they can only be executed within a bastion instance wired to that subnet, and the spec cannot be automated until this is resolved in the spec.
In this example, Glance tries to connect to mysql on an IP which does not exist in the deployment on an address that is not part of the connected networks:
2015-12-15 15:29:41 INFO shared-db-relation-changed 2015-12-15 15:29:41.421 2994 CRITICAL glance [-] OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '10.5.100.1' (113)") None None
Note, that in this test run, the network for the deployed units was 172.17.107.0/24
mysql/0 active idle 1.25.0 18 172.17.107.197 Unit is ready
mysql-hacluster/0 active idle 1.25.0 172.17.107.197 Unit is ready and clustered
These are the environment variables were passed to the mojo job. Be aware that there are 20+ different networks, one per jenkins slave, and the mojo spec will need to consume and apply them accordingly.
00:03:40.021 + Setting network env vars:
00:03:40.021 NET_ID: a705dd0f-5571-4818-8c30-4132cc494668
00:03:40.021 GATEWAY: 172.17.107.1
00:03:40.021 NAME_SERVER: 10.5.8.242
00:03:40.021 CIDR_EXT: 172.17.107.0/24
00:03:40.021 FIP_RANGE: 172.17.107.200:172.17.107.249
00:03:40.021 AMULET_OS_VIP: 172.17.107.250
00:03:40.021 AMULET_OS_VIP00: 172.17.107.250
00:03:40.021 AMULET_OS_VIP01: 172.17.107.251
00:03:40.021 AMULET_OS_VIP02: 172.17.107.252
00:03:40.021 AMULET_OS_VIP03: 172.17.107.253
More detail @:
http://paste.ubuntu.com/14030619/
This dynamic variable consumption is already implemented by the non-HA specs which are in automation (full_stack/next, etc). The get_network_env_vars() helper in helper/utils/mojo_utils.py watches for env vars and consumes those to override values in from the network.yaml. |
The one-shot specs are hard-coded to 10.5.0.0/16, rather than consuming the VIP and other network env vars that are passed by the test environment. This means that they can only be executed within a bastion instance wired to that subnet, and the spec cannot be automated until this is resolved in the spec.
In this example, Glance tries to connect to mysql on an IP which does not exist in the deployment on an address that is not part of the connected networks:
2015-12-15 15:29:41 INFO shared-db-relation-changed 2015-12-15 15:29:41.421 2994 CRITICAL glance [-] OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '10.5.100.1' (113)") None None
Note, that in this test run, the network for the deployed units was 172.17.107.0/24
mysql/0 active idle 1.25.0 18 172.17.107.197 Unit is ready
mysql-hacluster/0 active idle 1.25.0 172.17.107.197 Unit is ready and clustered
These are the environment variables that were passed to the mojo job. Be aware that there are 20+ different networks, one per jenkins slave, and the mojo spec will need to consume and apply them accordingly.
00:03:40.021 + Setting network env vars:
00:03:40.021 NET_ID: a705dd0f-5571-4818-8c30-4132cc494668
00:03:40.021 GATEWAY: 172.17.107.1
00:03:40.021 NAME_SERVER: 10.5.8.242
00:03:40.021 CIDR_EXT: 172.17.107.0/24
00:03:40.021 FIP_RANGE: 172.17.107.200:172.17.107.249
00:03:40.021 AMULET_OS_VIP: 172.17.107.250
00:03:40.021 AMULET_OS_VIP00: 172.17.107.250
00:03:40.021 AMULET_OS_VIP01: 172.17.107.251
00:03:40.021 AMULET_OS_VIP02: 172.17.107.252
00:03:40.021 AMULET_OS_VIP03: 172.17.107.253
More detail @:
http://paste.ubuntu.com/14030619/
This dynamic variable consumption is already implemented by the non-HA specs which are in automation (full_stack/next, etc). The get_network_env_vars() helper in helper/utils/mojo_utils.py watches for env vars and consumes those to override values in from the network.yaml. |
|
| 2015-12-15 19:40:40 |
Ryan Beisner |
description |
The one-shot specs are hard-coded to 10.5.0.0/16, rather than consuming the VIP and other network env vars that are passed by the test environment. This means that they can only be executed within a bastion instance wired to that subnet, and the spec cannot be automated until this is resolved in the spec.
In this example, Glance tries to connect to mysql on an IP which does not exist in the deployment on an address that is not part of the connected networks:
2015-12-15 15:29:41 INFO shared-db-relation-changed 2015-12-15 15:29:41.421 2994 CRITICAL glance [-] OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '10.5.100.1' (113)") None None
Note, that in this test run, the network for the deployed units was 172.17.107.0/24
mysql/0 active idle 1.25.0 18 172.17.107.197 Unit is ready
mysql-hacluster/0 active idle 1.25.0 172.17.107.197 Unit is ready and clustered
These are the environment variables that were passed to the mojo job. Be aware that there are 20+ different networks, one per jenkins slave, and the mojo spec will need to consume and apply them accordingly.
00:03:40.021 + Setting network env vars:
00:03:40.021 NET_ID: a705dd0f-5571-4818-8c30-4132cc494668
00:03:40.021 GATEWAY: 172.17.107.1
00:03:40.021 NAME_SERVER: 10.5.8.242
00:03:40.021 CIDR_EXT: 172.17.107.0/24
00:03:40.021 FIP_RANGE: 172.17.107.200:172.17.107.249
00:03:40.021 AMULET_OS_VIP: 172.17.107.250
00:03:40.021 AMULET_OS_VIP00: 172.17.107.250
00:03:40.021 AMULET_OS_VIP01: 172.17.107.251
00:03:40.021 AMULET_OS_VIP02: 172.17.107.252
00:03:40.021 AMULET_OS_VIP03: 172.17.107.253
More detail @:
http://paste.ubuntu.com/14030619/
This dynamic variable consumption is already implemented by the non-HA specs which are in automation (full_stack/next, etc). The get_network_env_vars() helper in helper/utils/mojo_utils.py watches for env vars and consumes those to override values in from the network.yaml. |
The one-shot specs are hard-coded to 10.5.0.0/16, rather than consuming the VIP and other network env vars that are passed by the test environment. This means that they can only be executed within a bastion instance wired to that subnet, and the spec cannot be automated until this is resolved.
In this example, Glance tries to connect to mysql on an IP which does not exist in the deployment on an address that is not part of the connected networks:
2015-12-15 15:29:41 INFO shared-db-relation-changed 2015-12-15 15:29:41.421 2994 CRITICAL glance [-] OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '10.5.100.1' (113)") None None
Note, that in this test run, the network for the deployed units was 172.17.107.0/24
mysql/0 active idle 1.25.0 18 172.17.107.197 Unit is ready
mysql-hacluster/0 active idle 1.25.0 172.17.107.197 Unit is ready and clustered
These are the environment variables that were passed to the mojo job. Be aware that there are 20+ different networks, one per jenkins slave, and the mojo spec will need to consume and apply them accordingly.
00:03:40.021 + Setting network env vars:
00:03:40.021 NET_ID: a705dd0f-5571-4818-8c30-4132cc494668
00:03:40.021 GATEWAY: 172.17.107.1
00:03:40.021 NAME_SERVER: 10.5.8.242
00:03:40.021 CIDR_EXT: 172.17.107.0/24
00:03:40.021 FIP_RANGE: 172.17.107.200:172.17.107.249
00:03:40.021 AMULET_OS_VIP: 172.17.107.250
00:03:40.021 AMULET_OS_VIP00: 172.17.107.250
00:03:40.021 AMULET_OS_VIP01: 172.17.107.251
00:03:40.021 AMULET_OS_VIP02: 172.17.107.252
00:03:40.021 AMULET_OS_VIP03: 172.17.107.253
More detail @:
http://paste.ubuntu.com/14030619/
This dynamic variable consumption is already implemented by the non-HA specs which are in automation (full_stack/next, etc). The get_network_env_vars() helper in helper/utils/mojo_utils.py watches for env vars and consumes those to override values from the network.yaml. |
|
| 2016-01-19 16:19:02 |
David Ames |
branch linked |
|
lp:~thedac/openstack-mojo-specs/mojo-openstack-specs-handle-vips |
|
| 2017-11-09 16:29:21 |
David Ames |
branch linked |
|
lp:~thedac/openstack-mojo-specs/ha-automation |
|
| 2017-11-09 16:30:10 |
David Ames |
branch unlinked |
lp:~thedac/openstack-mojo-specs/mojo-openstack-specs-handle-vips |
|
|
| 2017-11-14 06:58:29 |
Chris MacNaughton |
openstack-mojo-specs: status |
New |
Fix Released |
|
