[Rdo-list] [RDO-Manager] deploy

Dan Sneddon dsneddon at redhat.com
Tue Nov 17 20:58:37 UTC 2015

On 11/17/2015 12:32 PM, Mikyung Kang wrote:
> Hello,
> I'm trying RDO-manager:Liberty version on CentOS7.1.
> https://repos.fedorapeople.org/repos/openstack-m/rdo-manager-docs/liberty/basic_deployment/basic_deployment_cli.html
> 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 ( = undercloud IP)
> default introspect
> label introspect
> kernel agent.kernel
> append initrd=agent.ramdisk ipa-inspection-callback-url= 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? 
> Thanks,
> Mikyung
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 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 mailing list