fuel-dev team mailing list archive

[Andrey Danin <adanin@xxxxxxxxxxxx>]

Dnsmasq can do it but Cobbler doesn't allow it.


On Mon, Jan 27, 2014 at 9:43 PM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> So why cant we just set the same IP on each interfaces mac in cobbler? we
> don't really care which one boots, just that the 'right' admin interface is
> saved after we reboot.
>
>
> On Sun, Jan 26, 2014 at 11:03 PM, Andrey Danin <adanin@xxxxxxxxxxxx>wrote:
>
>>  My scenario occurs when eth0 and eth1 are connected to PXE network and a
>> PortFast feature is not enabled on a switch. Eth0 can get a timeout from
>> time to time and if the Cobbler will know a eth0 MAC only, it'll boot it to
>> the bootstrap.
>>
>>
>>
>> On Mon, Jan 27, 2014 at 9:52 AM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx
>> > wrote:
>>
>>> Andrey,
>>>
>>> This is something a user could always fix himself. Typically you do
>>> DHCP on eth0, then eth1,etc.... and the only case I can think of where
>>> your scenario would occur is if we were trying to provision 50+ nodes
>>> with an underpowered master. But what's more likely is eth0 will start
>>> PXE boot and fail to receive the whole image and reboot and try again.
>>> If you have systems PXE booting on eth0 for bootstrap then eth1 for
>>> provision, then it's a really odd machine and I think we need to
>>> discount that case.
>>>
>>> If this scenario is real and reproducable, we can definitely work
>>> around it and create system records in Cobbler (but not reserve an IP
>>> for them) that correspond to all the other MAC addresses of the
>>> system. We could forward them to a special profile that tells cobbler
>>> to update its records for DNS and the system profile, then reboot it
>>> and provision again. Or at minimum a warning state that we can use to
>>> give feedback to the user that PXE is not working correctly on a
>>> particular node.
>>>
>>> If a user wants to deploy 100 nodes with 6 NICs in each system, a /24
>>> should be enough, but with our non-optimal logic, it requires a /22
>>> network to deploy: 100 IPs for bootstrap and 600 IPs for provisioning.
>>>
>>> The solution in place doesn't work and doesn't meet expectations of
>>> real use cases. We should pick an approach that will make the most
>>> people happy.
>>>
>>> -Matthew
>>>
>>> On Mon, Jan 27, 2014 at 9:40 AM, Andrey Danin <adanin@xxxxxxxxxxxx>
>>> wrote:
>>> > The problem is the Cobbler will force the node to boot to bootstrap if
>>> he
>>> > doesn't recognize it via known MAC. Here are the boot process diagrams.
>>> > The right one:
>>> >   # node's embedded PXE software starts a boot-up procedure via eht0
>>> >   # Cobbler knows eth0 MAC and puts to the node a PXE config to
>>> download and
>>> > run an installation image (CentOS)
>>> >   # The node goes to the provisioning state.
>>> >
>>> > The bad one:
>>> >   # node runs PXE procedure over eth1
>>> >   # Cobbler doesn't know eth1 MAC and sends to the node a PXE config
>>> with a
>>> > bootstrap image.
>>> >   # the node boots into bootstrap and an installation process fails.
>>> >
>>> >
>>> > On Mon, Jan 27, 2014 at 9:25 AM, Matthew Mosesohn <
>>> mmosesohn@xxxxxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> Andrey,
>>> >>
>>> >> We can use the same tactic we use in Ubuntu to ensure that CentOS
>>> >> starts installing on the correct MAC by adding the kernel parameter
>>> >> ks.device=$MACADDR. It will try to DHCP on that interface and
>>> >> eliminate the possibility of having 2 or more NICs on the same subnet
>>> >> as the PXE server.
>>> >>
>>> >> On Mon, Jan 27, 2014 at 9:14 AM, Andrey Danin <adanin@xxxxxxxxxxxx>
>>> wrote:
>>> >> > There is a little chance that a node will boot up via another
>>> interface
>>> >> > and
>>> >> > Cobbler will put it to the bootstrap stage instead of the target
>>> stage.
>>> >> > We
>>> >> > have to provide all MAC addresses of a node to Cobbler but it can't
>>> use
>>> >> > one
>>> >> > IP for all MACs. So we have to allocate a lot of IPs.
>>> >> >
>>> >> > We can improve our mechanism by the following:
>>> >> >   * Assign IP to the node's admin interface only. Use it as a
>>> default
>>> >> > behavior but add an UI switch to enable a greedy behavior.
>>> >> >   * Run a predeployment DHCP check in order to find all interfaces
>>> which
>>> >> > really can communicate with PXE network and assign IPs to these
>>> >> > interfaces
>>> >> > only.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Jan 23, 2014 at 12:29 AM, Ryan Moe <rmoe@xxxxxxxxxxxx>
>>> wrote:
>>> >> >>
>>> >> >> What is the reasoning behind assigning an IP from the admin
>>> network to
>>> >> >> all
>>> >> >> interfaces [1]? It has caused problems in deployments where IPs are
>>> >> >> tightly
>>> >> >> managed and/or machines have a large number of interfaces.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Ryan
>>> >> >>
>>> >> >> [1]
>>> >> >>
>>> >> >>
>>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/helpers.py#L435
>>> >> >>
>>> >> >> --
>>> >> >> Mailing list: https://launchpad.net/~fuel-dev
>>> >> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >> >> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >> >> More help   : https://help.launchpad.net/ListHelp
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Andrey Danin
>>> >> > adanin@xxxxxxxxxxxx
>>> >> > skype: gcon.monolake
>>> >> >
>>> >> > --
>>> >> > Mailing list: https://launchpad.net/~fuel-dev
>>> >> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >> > Unsubscribe : https://launchpad.net/~fuel-dev
>>> >> > More help   : https://help.launchpad.net/ListHelp
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Andrey Danin
>>> > adanin@xxxxxxxxxxxx
>>> > skype: gcon.monolake
>>>
>>
>>
>>
>> --
>> Andrey Danin
>> adanin@xxxxxxxxxxxx
>> skype: gcon.monolake
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> If google has done it, Google did it right!
>



-- 
Andrey Danin
adanin@xxxxxxxxxxxx
skype: gcon.monolake