2:58 p.m.
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...
After adding /tftpboot/pxelinux.cfg/default [Using IPA] as follows, up to introspection
step, it's OK (error=None, finished=True).
[root@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?
Thanks,
Mikyung
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)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
interface.
--
Dan Sneddon | Principal OpenStack Engineer
dsneddon(a)redhat.com | redhat.com/openstack
650.254.4025 | dsneddon:irc @dxs:twitter