[Rdo-list] [RDO-Manager] deploy
dsneddon at redhat.com
Tue Nov 17 20:58:37 UTC 2015
On 11/17/2015 12:32 PM, Mikyung Kang wrote:
> I'm trying RDO-manager:Liberty version on CentOS7.1.
> After adding /tftpboot/pxelinux.cfg/default [Using IPA] as follows, up to introspection step, it's OK (error=None, finished=True).
> [root at test tftpboot]# cat pxelinux.cfg/default (10.0.1.6 = undercloud IP)
> default introspect
> label introspect
> kernel agent.kernel
> append initrd=agent.ramdisk ipa-inspection-callback-url=http://10.0.1.6:5050/v1/continue systemd.journald.forward_to_console=yes
> ipappend 3
> But, when deploying 1 controller and 1 compute, those systems couldn't be booted from right deploy images.
> I can see two instances are spawned (1 controller-node instance and 1 compute-node instance) based on the default heat template. Then, the provisioning state is changed from available to deploying. On this deploying step, I can see deploy images/config are put to each instance's UUID directory @/httpboot/ directory. And then, the provisioning state is changed from [deploying] to [wait call-back]. Even though ipmitool turns on the system, those systems can't find deploy images.
> Actually, I have another dhcp server @other machine. It includes RDO testbeds' MAC and IP. So, I setup RDO testbeds' next-server as RDO undercloud IP @dhcpd.conf. Then, overcloud nodes could boot from agent.kernel/ramdisk from undercloud:/tftpboot properly. But, I don't know how overcloud nodes can get deploy/overcloud images.
> If above pxelinux.cfg/default is put as-is @undercloud, agent kernel/ramdisk is loaded again, not from deploy image. Then deploying step can't be proceeded further and then goes to timeout error. If that default file is removed, system is unable to locate tftp configuration. How can I make controller/compute boot from right deploy images? Should I setup something for the httpboot/ipxe?
> Rdo-list mailing list
> Rdo-list at redhat.com
> To unsubscribe: rdo-list-unsubscribe at redhat.com
What is supposed to happen when introspection completes is that the
Undercloud will add the MAC address of the newly-discovered system to
iptables in order to block DHCP requests from reaching
ironic-discovery's dnsmasq. If that doesn't happen, then you get a loop
where the discovery image boots instead of the deploy image.
Check your iptables and make sure that you see the MAC addresses added
to the "discovery" chain, like this:
Chain discovery (1 references)
target prot opt source destination
DROP all -- anywhere anywhere MAC 00:21:BA:17:0D:2B
DROP all -- anywhere anywhere MAC 00:3C:A6:BB:68:FC
DROP all -- anywhere anywhere MAC 00:92:5D:AE:62:37
Also, make sure that iptables is running, and that you don't have more
than one interface attached to the provisioning network on the
overcloud nodes. If you do, there is a workaround, but it's cleanest to
just make sure you have only one interface attached to the provisioning
Dan Sneddon | Principal OpenStack Engineer
dsneddon at redhat.com | redhat.com/openstack
650.254.4025 | dsneddon:irc @dxs:twitter
More information about the rdo-list