Others do something differently, and try to detect the right netmask before taking the cidr from the charm config option.
Like openstack-dashboard:
netmask = (get_netmask_for_address(vip) or config('vip_cidr'))
My observations:
a) maybe percona-cluster should be changed and also try to auto-detect the netmask, following the same pattern
b) maybe landscape should be setting vip_cidr in all cases. We know the cidr (we have to, since it's an argument to the MAAS API call that reserves a VIP). But all these charms other than percona-cluster would keep ignoring it and try the autodetect route first
c) maybe the charms should only be doing autodetection of the netmask if vip_cidr was NOT provided, i.e., it's at the charm config default value. If vip_cidr was set, then just use that.
percona-cluster (mysql) is the "only" charm (of those I checked) that will take the vip_cidr charm config option and apply as is:
vip_cidr = config('vip_cidr')
(vip, vip_cidr, vip_iface)
(...)
vip_params = 'params ip="%s" cidr_netmask="%s" nic="%s"' % \
Others do something differently, and try to detect the right netmask before taking the cidr from the charm config option.
Like openstack- dashboard: for_address( vip) or
config( 'vip_cidr' ))
netmask = (get_netmask_
My observations:
a) maybe percona-cluster should be changed and also try to auto-detect the netmask, following the same pattern
b) maybe landscape should be setting vip_cidr in all cases. We know the cidr (we have to, since it's an argument to the MAAS API call that reserves a VIP). But all these charms other than percona-cluster would keep ignoring it and try the autodetect route first
c) maybe the charms should only be doing autodetection of the netmask if vip_cidr was NOT provided, i.e., it's at the charm config default value. If vip_cidr was set, then just use that.