Open Stack

(This thread carries on from the bare-metail list, sorry).

On Tue, Oct 30, 2012 at 8:57 PM, VTJ NOTSU Arata <notsu at virtualtech.jp> wrote:
>> Right now we have a demo environment working with only one NIC,
>> putting bogus data in for the second NIC - I'd like to understand what
>> we should expect to go wrong :)
>
>
> Booting itself will be successful. But, when it goes cloud-init, it will
> fail
> since network is timed out. Of course we cannot connect to fixed/floating
> IP.

cloud-init works fine, as long as your network layer knows a) a
default route and b) your gateway DNATs 169.254.169.254.

>> Also, it would be great if you can explain the dependencies so that we
>> can start working on them?
>
>
> OK, I try to explain it. But, I'm not confident at all about what I write
> here since I have not examined an idea of single-nic...
>
> First, we have to make bare-metal's pxe server and nova's dhcp server work
> together on the same network. Second, we treats a pxe nic specially in
> nova-compute, at mapping NICs and at injection of /etc/network/interfaces
> (and so on?). Change them to treat the pxe nic as a normal nic.

The bare metal PXE really should just be nova's dhcp / quantums dhcp
agent. There is no need for a separate one, just a small amount of
orchestration to control boot parameters.

I agree that we need to know the MAC for PXE to happen, but once we
teach nova that an instance may have a predefined MAC [not tenant
accessible, this is an internal consideration], then it just becomes:
 - when provisioning the instance, the bm db is consulted for NIC MAC
as an override
 - tell nova/quantum DHCP the next-server and filename for PXE in
addition to the NIC MAC.
 - After image copy, update the nova/quantum DHCP record.

Am I missing something?
-Rob