Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux-HA: Dev

Patch to OCF Route

 

 

Linux-HA dev RSS feed   Index | Next | Previous | View Threaded


petersen at strands

Jul 10, 2008, 10:47 AM

Post #1 of 6 (361 views)
Permalink
Patch to OCF Route

This is my first adventure into OCF scripts, so I'm quite certain I have no
idea what I'm doing. However, the Route script recently posted was something that I've
been looking for recently, and needed a few tweaks to meet my requirements. In the spirit
of giving back, here are the changes I made - maybe they will be useful to someone.

In summary, I wanted to be able to manipulate both traditional "routes" as
well as "policy routes". Now that I made these changes, I'm thinking it might have been
more appropriate to just create a new PolicyRoute script to make the distinction more
clear.

In any event, I also wrote a wrapper script for heartbeat so I can now bring up
multiple routes and define a default gateway for each one, all from heartbeat. Which is
really neat.

Thanks!

-poul

--- Route.orig 2008-07-10 17:32:09.000000000 +0000
+++ Route 2008-07-10 17:34:59.000000000 +0000
@@ -63,7 +63,7 @@

<parameters>

-<parameter name="destination" unique="1" required="1">
+<parameter name="destination" unique="1" >
<longdesc lang="en">
The destination network (or host) to be configured for the route.
Specify the netmask suffix in CIDR notation (e.g. "/24").
@@ -93,12 +93,37 @@

<parameter name="source" unique="1">
<longdesc lang="en">
-The source IP address to be configured for the route.
+The source is the IP to prefer for routing outbound packets.
</longdesc>
<shortdesc lang="en">Source IP address</shortdesc>
<content type="string" default="" />
</parameter>

+<parameter name="from" unique="1">
+<longdesc lang="en">
+The "from" parameter is used by "ip rule" to define how to match
+packets based on their origin. This field should be in CIDR format: IP/NETMASK
+</longdesc>
+<shortdesc lang="en">From IP/MASK</shortdesc>
+<content type="string" default="" />
+</parameter>
+
+<parameter name="object" unique="1">
+<longdesc lang="en">
+The object type that is being manipulated: currently route or rule
+</longdesc>
+<shortdesc lang="en">Object Type</shortdesc>
+<content type="string" default="" />
+</parameter>
+
+<parameter name="table" unique="1">
+<longdesc lang="en">
+The route table in which to perform the action.
+</longdesc>
+<shortdesc lang="en">Table Integer</shortdesc>
+<content type="integer" default="" />
+</parameter>
+
</parameters>

<actions>
@@ -117,17 +142,40 @@
#######################################################################

create_route_spec() {
- # Creates a route specification for use by "ip route (add|del|show)"
- route_spec="to ${OCF_RESKEY_destination}"
+ # Creates a route specification for use by "ip ${OCF_RESKEY_object} (add|del|show)"
+
+ if [ -n "${OCF_RESKEY_destination}" ]; then
+ route_spec="to ${OCF_RESKEY_destination}"
+ fi
+
+ case ${OCF_RESKEY_object} in
+ rule)
+
+ if [ -n "${OCF_RESKEY_from}" ]; then
+ route_spec="${route_spec} from ${OCF_RESKEY_from}"
+ fi
+ ;;
+
+ route)
+
+ if [ -n "${OCF_RESKEY_gateway}" ]; then
+ route_spec="${route_spec} via ${OCF_RESKEY_gateway}"
+ fi
+
+ if [ -n "${OCF_RESKEY_source}" ]; then
+ route_spec="${route_spec} src ${OCF_RESKEY_source}"
+ fi
+ ;;
+ esac
+
if [ -n "${OCF_RESKEY_device}" ]; then
route_spec="${route_spec} dev ${OCF_RESKEY_device}"
fi
- if [ -n "${OCF_RESKEY_gateway}" ]; then
- route_spec="${route_spec} via ${OCF_RESKEY_gateway}"
- fi
- if [ -n "${OCF_RESKEY_source}" ]; then
- route_spec="${route_spec} src ${OCF_RESKEY_source}"
+
+ if [ -n "${OCF_RESKEY_table}" ]; then
+ route_spec="${route_spec} table ${OCF_RESKEY_table}"
fi
+
echo "$route_spec"
}

@@ -147,7 +195,7 @@
return $OCF_SUCCESS
fi
route_spec="$(create_route_spec)"
- if ip route add $route_spec; then
+ if ip ${OCF_RESKEY_object} add $route_spec; then
ocf_log info "${OCF_RESOURCE_INSTANCE} Added network route: $route_spec"
return $OCF_SUCCESS
else
@@ -162,7 +210,8 @@
case $status in
$OCF_SUCCESS)
route_spec="$(create_route_spec)"
- if ip route del $route_spec; then
+ocf_log "ip ${OCF_RESKEY_object} del $route_spec"
+ if ip ${OCF_RESKEY_object} del $route_spec; then
ocf_log info "${OCF_RESOURCE_INSTANCE} Removed network route: $route_spec"
return $OCF_SUCCESS
else
@@ -178,20 +227,34 @@
}

route_status() {
- show_output="$(ip route show $(create_route_spec) 2>/dev/null)"
- if [ $? -eq 0 ]; then
+
+ route_spec=$(create_route_spec)
+
+ case ${OCF_RESKEY_object} in
+ rule)
+ route_spec=`echo "$route_spec" | sed -e 's/table/lookup/g' -e 's/\/32//g' -e 's/^\ *//'`
+ show_output="$(ip ${OCF_RESKEY_object} show | grep "$route_spec" 2>/dev/null)"
+ ;;
+
+ route)
+
+ show_output="$(ip ${OCF_RESKEY_object} show $route_spec 2>/dev/null)"
+ ;;
+ esac
+
+ if [ $? -eq 0 ] || [ "${OCF_RESKEY_object}" = "rule" ]; then
if [ -n "$show_output" ]; then
- # "ip route show" returned zero, and produced output on
+ # "ip ${OCF_RESKEY_object} show" returned zero, and produced output on
# stdout. That is what we expect.
return $OCF_SUCCESS
else
- # "ip route show" returned zero, but produced no
+ # "ip ${OCF_RESKEY_object} show" returned zero, but produced no
# output on stdout. Assume the route was cleanly
# unconfigured.
return $OCF_NOT_RUNNING
fi
else
- # "ip route show" returned an error code. Assume something
+ # "ip ${OCF_RESKEY_object} show" returned an error code. Assume something
# went wrong.
return $OCF_ERR_GENERIC
fi
@@ -199,6 +262,11 @@

route_validate() {
# If we're running as a clone, are the clone meta attrs OK?
+
+ if [ "${OCF_RESKEY_object}" = "rule" ]; then
+ return $OCF_SUCCESS
+ fi
+
if [ "${OCF_RESKEY_CRM_meta_clone}" ]; then
if [ "${OCF_RESKEY_CRM_meta_clone_node_max}" -ne 1 ]; then
ocf_log error "Misconfigured clone parameters. Must set meta attribute \"clone_node_max\" to 1, got ${OCF_RESKEY_CRM_meta_clone_node_max}."
@@ -235,7 +303,7 @@
fi
# If a gateway address has been configured, is it reachable?
if [ -n "${OCF_RESKEY_gateway}" ]; then
- if ! ip route get ${OCF_RESKEY_gateway} >/dev/null 2>&1; then
+ if ! ip ${OCF_RESKEY_object} get ${OCF_RESKEY_gateway} >/dev/null 2>&1; then
ocf_log error "Gateway address ${OCF_RESKEY_gateway} is unreachable."
# same reason as with _device:
return $OCF_ERR_INSTALLED

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


florian.haas at linbit

Jul 15, 2008, 12:44 AM

Post #2 of 6 (320 views)
Permalink
Re: Patch to OCF Route [In reply to]

Thanks Poul; I will investigate that patch of yours and merge it into
mine if everything works out.

Dejan, not trying to be pushy here, but: should I submit my patch with
Poul's changes as one patch, or are you planning to commit my original
patch anytime soon, so we could add Poul's patch on top of that?

Cheers,
Florian

Poul Petersen wrote:
> This is my first adventure into OCF scripts, so I'm quite certain I
> have no
> idea what I'm doing. However, the Route script recently posted was
> something that I've
> been looking for recently, and needed a few tweaks to meet my
> requirements. In the spirit
> of giving back, here are the changes I made - maybe they will be useful
> to someone.
> [...]

--
: Florian G. Haas Tel +43-1-8178292-60 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna, Austria http://www.linbit.com :

This e-mail is solely for use by the intended recipient(s). Information
contained in this e-mail and its attachments may be confidential,
privileged or copyrighted. If you are not the intended recipient you are
hereby formally notified that any use, copying, disclosure or
distribution of the contents of this e-mail, in whole or in part, is
prohibited. Also please notify immediately the sender by return e-mail
and delete this e-mail from your system. Thank you for your co-operation.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


dejanmm at fastmail

Jul 15, 2008, 5:37 AM

Post #3 of 6 (322 views)
Permalink
Re: Patch to OCF Route [In reply to]

Hi,

On Tue, Jul 15, 2008 at 09:44:34AM +0200, Florian Haas wrote:
> Thanks Poul; I will investigate that patch of yours and merge it into
> mine if everything works out.
>
> Dejan, not trying to be pushy here, but: should I submit my patch with
> Poul's changes as one patch, or are you planning to commit my original
> patch anytime soon, so we could add Poul's patch on top of that?

Sorry for the delay. Was on vacation in the meantime. Just pushed
your patch, so you can use that as the starting point for further
changes:

changeset: 11990:9ac97992de2c
tag: tip
user: Florian Haas <florian.haas[at]linbit.com>
date: Tue Jul 15 14:35:32 2008 +0200
summary: Low: RA Route: new OCF RA to manage IP routes

Many thanks for the RA.

Cheers,

Dejan

> Cheers,
> Florian
>
> Poul Petersen wrote:
> > This is my first adventure into OCF scripts, so I'm quite certain I
> > have no
> > idea what I'm doing. However, the Route script recently posted was
> > something that I've
> > been looking for recently, and needed a few tweaks to meet my
> > requirements. In the spirit
> > of giving back, here are the changes I made - maybe they will be useful
> > to someone.
> > [...]
>
> --
> : Florian G. Haas Tel +43-1-8178292-60 :
> : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
> : Vivenotgasse 48, A-1120 Vienna, Austria http://www.linbit.com :
>
> This e-mail is solely for use by the intended recipient(s). Information
> contained in this e-mail and its attachments may be confidential,
> privileged or copyrighted. If you are not the intended recipient you are
> hereby formally notified that any use, copying, disclosure or
> distribution of the contents of this e-mail, in whole or in part, is
> prohibited. Also please notify immediately the sender by return e-mail
> and delete this e-mail from your system. Thank you for your co-operation.
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


florian.haas at linbit

Jul 15, 2008, 6:00 AM

Post #4 of 6 (322 views)
Permalink
Re: Patch to OCF Route [In reply to]

Dejan,

Dejan Muhamedagic wrote:
> Hi,
>
> On Tue, Jul 15, 2008 at 09:44:34AM +0200, Florian Haas wrote:
>> Thanks Poul; I will investigate that patch of yours and merge it into
>> mine if everything works out.
>>
>> Dejan, not trying to be pushy here, but: should I submit my patch with
>> Poul's changes as one patch, or are you planning to commit my original
>> patch anytime soon, so we could add Poul's patch on top of that?
>
> Sorry for the delay. Was on vacation in the meantime.

So I figured, no worries at all. :-)

> Just pushed
> your patch, so you can use that as the starting point for further
> changes:
>
> changeset: 11990:9ac97992de2c
> tag: tip
> user: Florian Haas <florian.haas[at]linbit.com>
> date: Tue Jul 15 14:35:32 2008 +0200
> summary: Low: RA Route: new OCF RA to manage IP routes

Roger that, will do.

> Many thanks for the RA.

Quite welcome.

Florian

--
: Florian G. Haas
: LINBIT Information Technologies GmbH
: Vivenotgasse 48, A-1120 Vienna, Austria
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


florian.haas at linbit

Jul 23, 2008, 4:22 AM

Post #5 of 6 (270 views)
Permalink
Re: Patch to OCF Route [In reply to]

Poul,

sorry it took me so long to reply.

A few questions:

- I can't wrap my head around why you want to disregard the return value
of create_route_spec when invoking route_status and being configured with
"${OCF_RESKEY_object}" = "rule". Can you explain please?

- what's the particular reason for not testing for [
${OCF_RESKEY_CRM_meta_clone_node_max} -eq 1 ]; does it make sense to
configure several incarnations of the same policy route on one host?

- would you mind re-submitting your patch so that it applies cleanly
against the current version of Route in the Mercurial repo?

Thanks in advance, and thanks for your patience.

Cheers,
Florian

Poul Petersen wrote:
> This is my first adventure into OCF scripts, so I'm quite certain I
> have no
> idea what I'm doing. However, the Route script recently posted was
something that I've
> been looking for recently, and needed a few tweaks to meet my
> requirements. In the spirit
> of giving back, here are the changes I made - maybe they will be useful
to someone.
> [...]






_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


petersen at strands

Jul 31, 2008, 5:18 PM

Post #6 of 6 (210 views)
Permalink
Re: Patch to OCF Route [In reply to]

> - I can't wrap my head around why you want to disregard the return value
> of create_route_spec when invoking route_status and being configured with
> "${OCF_RESKEY_object}" = "rule". Can you explain please?

I assume you're talking about this block?
---
route_status() {

route_spec=$(create_route_spec)

case ${OCF_RESKEY_object} in
rule)
route_spec=`echo "$route_spec" | sed -e 's/table/lookup/g' -e 's/\/32//g' -e 's/^\ *//'`
show_output="$(ip ${OCF_RESKEY_object} show | grep "$route_spec" 2>/dev/null)"
;;

route)

show_output="$(ip ${OCF_RESKEY_object} show $route_spec 2>/dev/null)"
;;
esac
---

The problem is that "ip rule show" won't take any arguments:

# ip rule show from 10.15.8.0/24
"ip rule show" does not take any arguments.

Moreover, when you create a rule with the "table" option, it then shows up in the
output of "ip rule show" with the keyword "lookup", just to make things difficult. So, if
OCF_RESKEY_object is "rule" then we rewrite the route spec to change table to lookup, and
then run the output of "ip rule show" thru grep and use the exit status of the grep to
validate the presence of the rule.

> - what's the particular reason for not testing for [
> ${OCF_RESKEY_CRM_meta_clone_node_max} -eq 1 ]; does it make sense to
> configure several incarnations of the same policy route on one host?

Ah, no, that's an oversight. There is no easy way to validate the presence
of a rule, in the manner that you can test a route. That is, there is no equivalence
of "ip link show" for a rule. The CRM test makes sense for rules, so the return should
probably come after that. I'm not certain if the other checks make sense for a rule, I'll
have to think about that.

> - would you mind re-submitting your patch so that it applies cleanly
> against the current version of Route in the Mercurial repo?
>

Sure! Sorry I didn't get back sooner, I have been on vacation and then
trying to catch up on things.

-poul
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Linux-HA dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.