fuel-dev team mailing list archive

[Ryan Moe <rmoe@xxxxxxxxxxxx>]

There was already a bug for this:
https://bugs.launchpad.net/fuel/+bug/1269726. You can also see Matt's patch
for it here: https://review.openstack.org/#/c/69617/.


On Thu, Jan 30, 2014 at 8:52 AM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> Doesn't Ryan's patch already do this?
>
>
> https://github.com/xarses/fuel-web/commit/11f4cb27f8abf5882d13e98557fb1529518ac45b
>
> When in use, cobbler generates interfaces with macs, but only one has an
> IP address
> I've created bug https://bugs.launchpad.net/fuel/+bug/1274590 to track
> this
>
> I've on a related, note, we also need to think about overlapping the dhcp
> pool range with the fuelweb_admin NetwrokGroup range. We have found that we
> are easily running out of addresses. I will test some changes and track
> them on bug https://bugs.launchpad.net/fuel/+bug/1274595
>
>
>
>
> On Tue, Jan 28, 2014 at 12:41 AM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx
> > wrote:
>
>> I just remembered another option. You can configure multiple NICs for
>> a given system so that when its mac addr requests PXE install, it can
>> do install (but not need a reserved address or DNS entry). No matter
>> what, we can start install regardless of which NIC starts install. We
>> can still specify which NIC to do DHCP on in anaconda/preseed. Since
>> we're already creating all NICs for a given system, we can just leave
>> the IP address blank.  I'll write up a quick patch for this.
>>
>> On Tue, Jan 28, 2014 at 12:24 PM, Andrey Danin <adanin@xxxxxxxxxxxx>
>> wrote:
>> > 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
>>
>
>
>
> --
> If google has done it, Google did it right!
>
> --
> 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
>
>