fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

Guys,
I did not have time today to update it to satisfy testing requirements and
Andrey Danin's request to rewrite two lines. You may submit a new patch set
sooner or wait till I get back Monday.
On Jan 30, 2014 9:26 PM, "Ryan Moe" <rmoe@xxxxxxxxxxxx> wrote:

> 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
>>
>>
>