On Wed, Jul 28, 2010 at 10:24, Manuel Franceschini <[email protected]> wrote:
> On Wed, Jul 28, 2010 at 4:12 PM, Iustin Pop <[email protected]> wrote:
>> On Wed, Jul 28, 2010 at 07:56, Manuel Franceschini <[email protected]> 
>> wrote:
>>> Hi all,
>>>
>>> I'm not sure about a couple of somehow related design decisions, so I
>>> thought I'd ask here.
>>>
>>> As of now Ganeti binds its daemons to '0.0.0.0' per default. This,
>>> obviously, becomes an issue if we want to support both IPv4 and IPv6.
>>> We want to support the following setups:
>>>
>>> a) pure IPv4
>>> b) IPv6 as primary and IPv4 as secondary
>>>
>>> In case b) we need to bind the daemons to '::'. To achieve that we
>>> have the following options:
>>>
>>> i) Pass a different bind_address for each daemon startup
>>> ii) Let lib/daemon.py get the primary ip version (which will be a
>>> future cluster parameter) from the config, and bind '0.0.0.0' or '::'
>>> accordingly.
>>>
>>> To me option ii) seems cleaner. I'm not sure, however, to retrieve the
>>> primary ip version from the config or ssconf. It seems, the primary ip
>>> version would be a good candidate for ssconf. What do you guys think?
>>> Any feedback/suggestions is more than welcome!
>>
>> primary ip version? as in primary IP family?
>
> I thought the external interface would use ip version (v4 or v6) and
> internally we would use address family (AF_INET or AF_INET6).
>
>> Also note that for some OSes, when you bind to an IPv6 socket, don't
>> automatically make you listen on IPv4 too (e.g. recent Debian). So
>> with a single socket it's either IPv4 *or* IPv6.
>
> Yes, we will not assume that an IPv6 socket listens for IPv4-mapped
> requests. What I was more concerned about is the issue of getting the
> information of which 'any address' to bind to.

Ack.

So I think the workflow is like this:
- at cluster init, the user selects either ipv4 or ipv6
- once that is fixed, we require at each node add, that the new node
resolves to an IP in that family
- also based on that, we select what to bind on

So this attribute should be exported in ssconf.

Does this make sense?

iustin

Reply via email to