Open Stack

I'm going to assume we're talking about a typical environment with nova and
neutron here. There are two separate boots to consider:

1. The IPA deployment ramdisk, which writes the user's image to the node's
disk.
2. The user's image.

Prior to 1, ironic communicates with neutron to apply additional DHCP
options required for network booting to the DHCP response issued to the
deployment ramdisk during provisioning.

When the user's image boots (assuming the node is configured for localboot
rather than netboot), it is not really any different than a typical nova
VM. The image, often using a service such as cloud-init, should arrange for
the appropriate interface(s) to start a DHCP client. Neutron will be
configured to provide a DHCP response.

The missing piece that enables the use of multiple network interfaces is
physical network awareness [1]. This feature will be available in the Pike
release, and allows an operator to tag ironic ports with the physical
network to which they are attached. With this information, ironic is able
to correctly map the virtual neutron ports passed by the user via nova to
the physical ironic ports. Previously, this mapping was essentially random
and would lead to the node's DHCP requests landing at the wrong neutron
DHCP server instance in some cases.

[1] https://bugs.launchpad.net/ironic/+bug/1666009

Mark

On 28 July 2017 at 12:29, Waines, Greg <Greg.Waines at windriver.com> wrote:

> Thanks for the info Mark.
>
>
>
> A dumb question ... can’t seem to find the answer in ironic documentation
> ...
>
> ·         I understand how the interface over which the bare metal
> instance network boots/installs gets configured ...
> i.e. thru DHCP response/configuration from the ironic conductor dhcp/boot
> server
>
> ·         but how would other interfaces, get configured on the bare
> metal server by ironic ?
>
>
>
>
>
> Greg.
>
>
>
> *From: *Mark Goddard <mark at stackhpc.com>
> *Reply-To: *"openstack-dev at lists.openstack.org" <openstack-dev at lists.
> openstack.org>
> *Date: *Friday, July 28, 2017 at 5:08 AM
> *To: *"openstack-dev at lists.openstack.org" <openstack-dev at lists.
> openstack.org>
> *Subject: *Re: [openstack-dev] [magnum] Interface configuration and
> assumptions for masters/minions launched by magnum
>
>
>
> Hi Greg,
>
>
>
> Magnum clusters currently support using only a single network for all
> communication. See the heat templates[1][2] in the drivers.
>
> .
>
> On the bare metal side, currently ironic effectively supports using only a
> single network interface due to a lack of support for physical network
> awareness. This feature[3] will be added in the Pike release, at which
> point it will be possible to create bare metal instances with multiple
> ports.
>
>
>
> [1] https://github.com/openstack/magnum/tree/master/
> magnum/drivers/k8s_fedora_atomic_v1/templates
>
> [2] https://github.com/openstack/magnum/tree/master/magnum/
> drivers/k8s_coreos_v1/templates
>
> [3] https://bugs.launchpad.net/ironic/+bug/1666009
>
>
>
> Mark
>
>
>
> On 17 July 2017 at 14:27, Waines, Greg <Greg.Waines at windriver.com> wrote:
>
> When MAGNUM launches a VM or Ironic instance for a COE master or minion
> node, with the COE Image,
>
> What is the interface configuration and assumptions for these nodes ?
>
> e.g.
>
> - only a single interface ?
>
> - master and minion communication over that interface ?
>
> - communication to Docker Registry or public Docker Hub over that
> interface ?
>
> - public communications for containers over that interface ?
>
>
>
> Greg.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170801/b2a50b14/attachment.html>