Chrissie,
it's really nice to see again patch sent by you. There are few nitpicks
included (I've commented in patch).
+ icmap_get_string("totem.inaddr_any", &str);
+ if (strcmp(str, "yes") == 0)
+ totem_config->inaddr_any = 1;
+ else
+ totem_config->inaddr_any = 0;
+
icmap_get_string returns newly allocated string or NULL. So it's good
idea to check return value of icmap_get_string, and free str if it was
successful.
+When in updu mode, setting this to "yes" tells corosync to bind the network
+sockets to INADDR_ANY rather than the local IP address. This might be
There are two trailing whitespace (I can recommend to set
[color]
diff = auto
status = auto
branch = auto
ui = auto
in your gitconfig, and then trailing whitespace is marked red ... so
very well visible).
Eventho, I'm still unsure if this will make corosync properly works in
floating-ip environment. Let's Steve to test it.
Other then that, patch looks great.
Regards,
Honza
Christine Caulfield napsal(a):
> Here's a patch you might like to try
>
> Xx
> Chrissie
>
>
> On 01/03/13 15:26, Steven Dake wrote:
>> On 03/01/2013 05:26 AM, Jan Friesse wrote:
>>> Steven Dake napsal(a):
>>>> Hi,
>>>>
>>>> Speaking with Angus who spoke with Andrew about the problem of getting
>>>> Corosync to run inside cloud guests, specially OpenStack, spawned this
>>>> conversation...
>>>>
>>>> Currently the problem is that with UDPU mode and a bindnetaddr set, the
>>>> interface binding code first searches for the ip address, then once
>>>> found, determines the interface which that ip address is connected to.
>>>>
>>>> This would work great if cloud guests had static ip addresses which
>>>> they
>>>> are assigned, but in most cases this is not the case. IP addresses are
>>>> assigned dynamically from an address pool. This means on restart,
>>>> without detailed knowledge of the cloud deployment, it is not possible
>>>> to set a bindnetaddr up that works consistently. Further complicating
>>>> matters is that the target node list IP addresses change in the
>>>> non-floating-ip model.
>>>>
>>>> One simple solution is to use the following config model:
>>>> 1. obtain a floating ip address from OpenStack
>>>> 2. configure the guest vms with the floating IPs
>>>> 3. hold floating IP for lifetime of application
>>>>
>>>> The way floating IPs work (atleast in OpenStack) is that they create
>>>> iptables on the host to represent the ip address. As a result, using
>>>> floating IPs with the current totemip behavior doesn't solve the
>>>> problem
>>>> because totemip will still desire to bind to a specific address.
>>>> Unfortunately the floating IPs don't present a physical interface
>>>> inside
>>>> the guest VM, but are handled externally by iptables. This makes
>>>> binding impossible.
>>>>
>>>> One solution to this problem is to add a new mode "inaddr_any" for
>>>> bindnetaddr. Then when corosync starts, it will bind to INADDR_ANY
>>>> interface and the udpu traffic will be routed properly by iptables.
>>>>
>>> I've found following problems with your solution:
>>> - Corosync is inserting bind IP address (system_from filed) of all rings
>>> to every packet. So it's needed to know WHAT IP address is in use. How
>>> we will find it with inaddr_any? (Ignoring fact that this field may be
>>> ignored because it should be used in multiring which is not implemented)
>>> - Because we don't know IP addresses, how we will fill udpu members
>>> list? How will corosync know what are other nodes to contact them?
>>>
>>
>> Totem trusts all "system_from" fields in each message header, meaning it
>> doesn't actually look at the receipt address from the kernel IP system.
>> One solution to this problem is to put the host's floating IP address
>> in t
>>
>> This all starts out at instance->my_id which is set in:
>> https://github.com/corosync/corosync/blob/needle-2.2/exec/totemsrp.c#L4549
>>
>>
>> Which comes from totemip.
>>
>> Regards
>> -steve
>>
>>>> Any thoughts on a simpler solution or on this solution?
>>>>
>>> Actually I believe only way to achieve correct functionality will be
>>> much harder solution of proper OpenStack integration... Hopefully I'm
>>> wrong in there.
>>>
>>>> Regards
>>>> -steve
>>> Regards,
>>> Honza
>>
>> _______________________________________________
>> discuss mailing list
>> discuss@xxxxxxxxxxxx
>> http://lists.corosync.org/mailman/listinfo/discuss
>
>
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
