Merge lp:~mpontillo/maas/beaconing-multicast-helper into lp:~maas-committers/maas/trunk
Proposed by
Mike Pontillo
Status: | Merged |
---|---|
Approved by: | Mike Pontillo |
Approved revision: | no longer in the source branch. |
Merged at revision: | 6079 |
Proposed branch: | lp:~mpontillo/maas/beaconing-multicast-helper |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
93 lines (+89/-0) 1 file modified
scripts/maas-multicast-helper (+89/-0) |
To merge this branch: | bzr merge lp:~mpontillo/maas/beaconing-multicast-helper |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Lee Trager (community) | Approve | ||
Mike Pontillo (community) | Abstain | ||
Blake Rouse (community) | Approve | ||
Review via email: mp+325134@code.launchpad.net |
Commit message
Add a helper script to join or leave the MAAS multicast groups.
MAAS will need to execute this on each monitored interface before listening for beacons, so that the NIC knows to forward beacon traffic up the OS (rather than dropping it before even copying it from the hardware buffer).
This approach is necessary in order to receive beacons on interfaces which may not have an IP address configured, and thus will not respond positively to socket-layer multicast join operations.
To post a comment you must log in.
Another question ,
Why are we using helpers I stead of integrating this into the code?
When power scripts were effectively scripts/helpers, we decided that we
were going to move away from that in order to be more robust inside the
MAAS code base. Now with all the discovery stuff we are going again for
adding helper after helper.
Why simply not be more robust and integrate this with the code base and
stop creating helpers!?
On Tue, Jun 6, 2017 at 6:16 AM Blake Rouse <email address hidden>
wrote:
> Review: Needs Information maas-multicast- helper' maas-multicast- helper 1970-01-01 00:00:00 +0000 maas-multicast- helper 2017-06-06 01:27:48 +0000 /www.iana. org/assignments /multicast- addresses/ multicast- addresses. xhtml /www.iana. org/assignments /ipv6-multicast -addresses/ ipv6-multicast- addresses. xhtml "224.0. 0.118" "33:33: 00:00:01: 5a" $(($SUCCESSES+ 1))
>
>
>
> Diff comments:
>
> > === added file 'scripts/
> > --- scripts/
> > +++ scripts/
> > @@ -0,0 +1,92 @@
> > +#!/bin/sh -euf
> > +# Copyright 2017 Canonical Ltd. This software is licensed under the
> > +# GNU Affero General Public License version 3 (see the file LICENSE).
> > +
> > +# Helper script to join or leave MAAS-reserved multicast groups.
> > +# See the IANA registries for more information:
> > +#
> https:/
> > +#
> https:/
> > +
> > +IP="/sbin/ip"
> > +
> > +# Note: asking the 'ip' command to join this IPv4 multicast group will
> result
> > +# in the MAC address "e0:00:00:76:00:00" being listened for on the
> interface.
> > +# Be aware that the "ip maddr show dev <ifname>" command will show the
> > +# link-layer listen address, not the IPv4-format address.
> > +IPV4_GROUP=
> > +
> > +# Note: The 'ip' command doesn't support IPv6 addresses yet.
> > +# This is the equivalent of the MAAS variable-scope multicast group, and
> > +# corresponds to the link-local scoped group "ff02::15a".
> > +IPV6_GROUP=
> > +
> > +usage()
> > +{
> > + echo "Usage: $0 <leave | join> [ifname...]" 1>&2
> > + echo " Attempts to join or leave the MAAS multicast groups." 1>&2
> > + echo " If no interfaces are specified, joins or leaves on all "`
> > + `"interfaces." 1>&2
> > +
> > +}
> > +
> > +if [ $# -lt 1 ]; then
> > + usage
> > + exit 1
> > +
> > +fi
> > +
> > +SUCCESSES=0
> > +FAILURES=""
> > +
> > +success()
> > +{
> > + SUCCESSES=
> > + echo "$*"
> > +}
> > +
> > +join()
> > +{
> > + "$IP" maddr add "$IPV4_GROUP" dev "$1" 2> /dev/null && \
> > + success "$1: joined $IPV4_GROUP" || true
> > + "$IP" maddr add "$IPV6_GROUP" dev "$1" 2> /dev/null && \
> > + success "$1: joined $IPV6_GROUP" || true
> > +}
> > +
> > +leave()
> > +{
> > + "$IP" maddr del "$IPV4_GROUP" dev "$1" 2> /dev/null && \
> > + success "$1: left $IPV4_GROUP" || true
>
> Let say an interface was plugged in after MAAS has started and it doesn't
> have the multicast address. When MAAS goes to leave that group for an
> interface that doesn't have it will this fail? I believe the '|| true' will
> cause it not to fail but placing it after the '&& success' might actually
> allow it to fail.
>
> > + "$IP" maddr del "$IPV6_GROUP" dev "$1" 2> /dev/null && \
> > + success...