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.wai...@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 <m...@stackhpc.com> > *Reply-To: *"openstack-dev@lists.openstack.org" <openstack-dev@lists. > openstack.org> > *Date: *Friday, July 28, 2017 at 5:08 AM > *To: *"openstack-dev@lists.openstack.org" <openstack-dev@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.wai...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
