vip_cidr is not read from network in MAAS, it's left at a default of /24
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Landscape Server |
Fix Released
|
High
|
Данило Шеган | ||
15.07 |
Fix Released
|
High
|
Данило Шеган | ||
Cisco-odl |
Fix Released
|
Medium
|
Данило Шеган | ||
percona-cluster (Juju Charms Collection) |
Fix Released
|
High
|
Данило Шеган |
Bug Description
I'm not sure the errors that this could cause, but the broadcast address will be computed incorrectly, for one.
This appears to apply to the mysql hacluster only. The other services have the correct cidr_netmask set (255.255.0.0), which is a longhand of the cidr itself.
The other services, I'm not sure how they get the subnetmask set correctly. It's probalby worth looking into how they do.
Some useful commands:
sudo crm configure show
sudo crm configure edit
ip addr
sudo crm resource show
sudo crm status
It's a bit unconfirmed, but this appears to have a caused a clustering issue with mysql. Basically only one out of every 3 `nova list` commands would work, the others would get 500 errors. Fixing this setting in the charm, and then manually with `sudo crm configure edit` appears to have addressed the issue.
Related branches
- OpenStack Charmers: Pending requested
-
Diff: 117 lines (+67/-4)2 files modifiedhooks/percona_hooks.py (+4/-3)
unit_tests/test_percona_hooks.py (+63/-1)
- Chris Glass (community): Approve
- Ryan Beisner (community): Needs Fixing
-
Diff: 130 lines (+68/-5)3 files modifiedhooks/percona_hooks.py (+4/-3)
metadata.yaml (+1/-1)
unit_tests/test_percona_hooks.py (+63/-1)
Changed in landscape: | |
milestone: | none → 15.07 |
tags: | removed: kanban |
description: | updated |
description: | updated |
description: | updated |
Changed in landscape: | |
milestone: | 15.07 → none |
Changed in percona-cluster (Juju Charms Collection): | |
status: | In Progress → Fix Committed |
Changed in percona-cluster (Juju Charms Collection): | |
importance: | Undecided → High |
milestone: | none → 15.10 |
Changed in landscape: | |
milestone: | none → 15.08 |
Changed in landscape: | |
assignee: | nobody → Данило Шеган (danilo) |
Changed in landscape: | |
status: | Fix Committed → Fix Released |
milestone: | 15.08 → 15.07 |
Changed in percona-cluster (Juju Charms Collection): | |
status: | Fix Committed → Fix Released |
I did a fresh deploy and mysql was the only service with an incorrect netmask for the vip ip (in the output of ip addr): MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 3eff:fe93: 774b/64 scope link
19: eth0: <BROADCAST,
link/ether 00:16:3e:93:77:4b brd ff:ff:ff:ff:ff:ff
inet 10.96.8.45/16 brd 10.96.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.96.10.9/24 brd 10.96.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:
valid_lft forever preferred_lft forever
Note that the vip (10.9) also has the same scope as the other IP, instead of "scope global secondary" like the other services. For example: MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 3eff:fe27: ecc4/64 scope link
15: eth0: <BROADCAST,
link/ether 00:16:3e:27:ec:c4 brd ff:ff:ff:ff:ff:ff
inet 10.96.8.143/16 brd 10.96.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.96.10.108/16 brd 10.96.255.255 scope global secondary eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:
valid_lft forever preferred_lft forever