2:32 p.m.
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
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
3:32 p.m.
Hi Dan,
Thanks for the description. As you described, iptables is running and MAC addresses for
overcloud nodes are added as DROP rule properly. Only one interface is attached to the
provisioning interface. But, overcloud nodes still load agent.kernel/ramdisk images, not
deploy_kernel/ramdisk. Should I disable dhcp server @ other machine and setup new dhcp
server on the same undercloud node?
This is my log:
[stack@gpu6 ~]$ openstack baremetal introspection bulk start
Setting available nodes to manageable...
Starting introspection of node: ffe9edca-fa5e-45bf-97df-f49a2cce0c92
Starting introspection of node: 1dc404db-0352-4355-ba64-67fae456f12a
Waiting for introspection to finish...
Introspection for UUID ffe9edca-fa5e-45bf-97df-f49a2cce0c92 finished successfully.
Introspection for UUID 1dc404db-0352-4355-ba64-67fae456f12a finished successfully.
Setting manageable nodes to available...
Node ffe9edca-fa5e-45bf-97df-f49a2cce0c92 has been set to available.
Node 1dc404db-0352-4355-ba64-67fae456f12a has been set to available.
Introspection completed.
[stack@gpu6 ~]$ ironic node-list
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning
State | Maintenance |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | None | None | power off | available
| False |
| 1dc404db-0352-4355-ba64-67fae456f12a | None | None | power off | available
| False |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
[stack@gpu6 ~]$ openstack baremetal introspection bulk status
+--------------------------------------+----------+-------+
| Node UUID | Finished | Error |
+--------------------------------------+----------+-------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | True | None |
| 1dc404db-0352-4355-ba64-67fae456f12a | True | None |
+--------------------------------------+----------+-------+
Chain ironic-inspector (1 references)
target prot opt source destination
DROP all -- anywhere anywhere MAC 00:9C:02:A7:EA:36
DROP all -- anywhere anywhere MAC 00:9C:02:A5:4A:DA
ACCEPT all -- anywhere anywhere
[stack@gpu6 ~]$ openstack overcloud deploy --templates
Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates
hang....?
[root@gpu6 tftpboot]# nova list
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| ID | Name | Status | Task State |
Power State | Networks |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| 9a0c3ba9-5502-4bd7-a7f1-c2109200c19e | overcloud-controller-0 | BUILD | spawning |
NOSTATE | ctlplane=192.0.2.9 |
| 0e740a33-fbca-4690-a938-980fbe623223 | overcloud-novacompute-0 | BUILD | spawning |
NOSTATE | ctlplane=192.0.2.8 |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
[root@gpu6 tftpboot]# ls -al /httpboot/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/
total 92524
drwxr-xr-x. 2 ironic ironic 87 Nov 17 16:17 .
drwxr-xr-x. 5 ironic ironic 4096 Nov 17 16:17 ..
-rw-r--r--. 1 ironic ironic 956 Nov 17 16:17 config
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 deploy_kernel
-rw-r--r--. 3 ironic ironic 50630736 Nov 6 14:44 deploy_ramdisk
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 kernel
-rw-r--r--. 3 ironic ironic 34038813 Nov 6 14:44 ramdisk
[root@gpu6 tftpboot]# ls -al /httpboot/1dc404db-0352-4355-ba64-67fae456f12a/
total 92524
drwxr-xr-x. 2 ironic ironic 87 Nov 17 16:17 .
drwxr-xr-x. 5 ironic ironic 4096 Nov 17 16:17 ..
-rw-r--r--. 1 ironic ironic 956 Nov 17 16:17 config
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 deploy_kernel
-rw-r--r--. 3 ironic ironic 50630736 Nov 6 14:44 deploy_ramdisk
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 kernel
-rw-r--r--. 3 ironic ironic 34038813 Nov 6 14:44 ramdisk
[root@gpu6 tftpboot]# cat /httpboot/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/config
#!ipxe
dhcp
goto deploy
:deploy
kernel http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/deploy_kernel selinux=0
disk=cciss/c0d0,sda,hda,vda
iscsi_target_iqn=iqn.2008-10.org.openstack:ffe9edca-fa5e-45bf-97df-f49a2cce0c92
deployment_id=ffe9edca-fa5e-45bf-97df-f49a2cce0c92
deployment_key=LIUI374KDMT55F8ATYY56BIDFWY0RRA1 ironic_api_url=http://192.0.2.1:6385
troubleshoot=0 text nofb nomodeset vga=normal boot_option=local
ip=${ip}:${next-server}:${gateway}:${netmask} BOOTIF=${mac}
ipa-api-url=http://192.0.2.1:6385 ipa-driver-name=pxe_ipmitool coreos.configdrive=0
initrd http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/deploy_ramdisk
boot
:boot_partition
kernel http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/kernel root={{ ROOT }}
ro text nofb nomodeset vga=normal
initrd http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/ramdisk
boot
:boot_whole_disk
kernel chain.c32
append mbr:{{ DISK_IDENTIFIER }}
boot
[root@gpu6 tftpboot]# ironic node-list
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID |
Power State | Provisioning State | Maintenance |
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | None | 0e740a33-fbca-4690-a938-980fbe623223 |
power on | wait call-back | False |
| 1dc404db-0352-4355-ba64-67fae456f12a | None | 9a0c3ba9-5502-4bd7-a7f1-c2109200c19e |
power on | wait call-back | False |
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
Thanks,
Mikyung
----- Original Message -----
From: "Dan Sneddon" <dsneddon(a)redhat.com>
To: "Mikyung Kang" <mkkang(a)isi.edu>, rdo-list(a)redhat.com
Sent: Tuesday, November 17, 2015 3:58:37 PM
Subject: Re: [Rdo-list] [RDO-Manager] deploy
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
1:37 p.m.
The RDO deployment works fine w/o any problem. Our OS image was broken to access iPXE. All
RDO steps are working fine w/o any modification.
[stack@gpu6 ~]$ nova list
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| ID | Name | Status | Task State |
Power State | Networks |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| c71fdb92-1af1-4630-85ae-aabcc63aa812 | overcloud-controller-0 | ACTIVE | - |
Running | ctlplane=192.0.2.8 |
| 7999b4a2-80f5-449a-915c-9db29ad0297b | overcloud-novacompute-0 | ACTIVE | - |
Running | ctlplane=192.0.2.9 |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
Thanks,
Mikyung
----- Original Message -----
From: "Mikyung Kang" <mkkang(a)isi.edu>
To: "Dan Sneddon" <dsneddon(a)redhat.com>
Cc: rdo-list(a)redhat.com
Sent: Tuesday, November 17, 2015 4:32:38 PM
Subject: Re: [Rdo-list] [RDO-Manager] deploy
Hi Dan,
Thanks for the description. As you described, iptables is running and MAC addresses for
overcloud nodes are added as DROP rule properly. Only one interface is attached to the
provisioning interface. But, overcloud nodes still load agent.kernel/ramdisk images, not
deploy_kernel/ramdisk. Should I disable dhcp server @ other machine and setup new dhcp
server on the same undercloud node?
This is my log:
[stack@gpu6 ~]$ openstack baremetal introspection bulk start
Setting available nodes to manageable...
Starting introspection of node: ffe9edca-fa5e-45bf-97df-f49a2cce0c92
Starting introspection of node: 1dc404db-0352-4355-ba64-67fae456f12a
Waiting for introspection to finish...
Introspection for UUID ffe9edca-fa5e-45bf-97df-f49a2cce0c92 finished successfully.
Introspection for UUID 1dc404db-0352-4355-ba64-67fae456f12a finished successfully.
Setting manageable nodes to available...
Node ffe9edca-fa5e-45bf-97df-f49a2cce0c92 has been set to available.
Node 1dc404db-0352-4355-ba64-67fae456f12a has been set to available.
Introspection completed.
[stack@gpu6 ~]$ ironic node-list
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning
State | Maintenance |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | None | None | power off | available
| False |
| 1dc404db-0352-4355-ba64-67fae456f12a | None | None | power off | available
| False |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
[stack@gpu6 ~]$ openstack baremetal introspection bulk status
+--------------------------------------+----------+-------+
| Node UUID | Finished | Error |
+--------------------------------------+----------+-------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | True | None |
| 1dc404db-0352-4355-ba64-67fae456f12a | True | None |
+--------------------------------------+----------+-------+
Chain ironic-inspector (1 references)
target prot opt source destination
DROP all -- anywhere anywhere MAC 00:9C:02:A7:EA:36
DROP all -- anywhere anywhere MAC 00:9C:02:A5:4A:DA
ACCEPT all -- anywhere anywhere
[stack@gpu6 ~]$ openstack overcloud deploy --templates
Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates
hang....?
[root@gpu6 tftpboot]# nova list
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| ID | Name | Status | Task State |
Power State | Networks |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
| 9a0c3ba9-5502-4bd7-a7f1-c2109200c19e | overcloud-controller-0 | BUILD | spawning |
NOSTATE | ctlplane=192.0.2.9 |
| 0e740a33-fbca-4690-a938-980fbe623223 | overcloud-novacompute-0 | BUILD | spawning |
NOSTATE | ctlplane=192.0.2.8 |
+--------------------------------------+-------------------------+--------+------------+-------------+--------------------+
[root@gpu6 tftpboot]# ls -al /httpboot/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/
total 92524
drwxr-xr-x. 2 ironic ironic 87 Nov 17 16:17 .
drwxr-xr-x. 5 ironic ironic 4096 Nov 17 16:17 ..
-rw-r--r--. 1 ironic ironic 956 Nov 17 16:17 config
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 deploy_kernel
-rw-r--r--. 3 ironic ironic 50630736 Nov 6 14:44 deploy_ramdisk
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 kernel
-rw-r--r--. 3 ironic ironic 34038813 Nov 6 14:44 ramdisk
[root@gpu6 tftpboot]# ls -al /httpboot/1dc404db-0352-4355-ba64-67fae456f12a/
total 92524
drwxr-xr-x. 2 ironic ironic 87 Nov 17 16:17 .
drwxr-xr-x. 5 ironic ironic 4096 Nov 17 16:17 ..
-rw-r--r--. 1 ironic ironic 956 Nov 17 16:17 config
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 deploy_kernel
-rw-r--r--. 3 ironic ironic 50630736 Nov 6 14:44 deploy_ramdisk
-rw-r--r--. 3 ironic ironic 5029328 Nov 6 14:44 kernel
-rw-r--r--. 3 ironic ironic 34038813 Nov 6 14:44 ramdisk
[root@gpu6 tftpboot]# cat /httpboot/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/config
#!ipxe
dhcp
goto deploy
:deploy
kernel http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/deploy_kernel selinux=0
disk=cciss/c0d0,sda,hda,vda
iscsi_target_iqn=iqn.2008-10.org.openstack:ffe9edca-fa5e-45bf-97df-f49a2cce0c92
deployment_id=ffe9edca-fa5e-45bf-97df-f49a2cce0c92
deployment_key=LIUI374KDMT55F8ATYY56BIDFWY0RRA1 ironic_api_url=http://192.0.2.1:6385
troubleshoot=0 text nofb nomodeset vga=normal boot_option=local
ip=${ip}:${next-server}:${gateway}:${netmask} BOOTIF=${mac}
ipa-api-url=http://192.0.2.1:6385 ipa-driver-name=pxe_ipmitool coreos.configdrive=0
initrd http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/deploy_ramdisk
boot
:boot_partition
kernel http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/kernel root={{ ROOT }}
ro text nofb nomodeset vga=normal
initrd http://192.0.2.1:8088/ffe9edca-fa5e-45bf-97df-f49a2cce0c92/ramdisk
boot
:boot_whole_disk
kernel chain.c32
append mbr:{{ DISK_IDENTIFIER }}
boot
[root@gpu6 tftpboot]# ironic node-list
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID |
Power State | Provisioning State | Maintenance |
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
| ffe9edca-fa5e-45bf-97df-f49a2cce0c92 | None | 0e740a33-fbca-4690-a938-980fbe623223 |
power on | wait call-back | False |
| 1dc404db-0352-4355-ba64-67fae456f12a | None | 9a0c3ba9-5502-4bd7-a7f1-c2109200c19e |
power on | wait call-back | False |
+--------------------------------------+------+--------------------------------------+-------------+--------------------+-------------+
Thanks,
Mikyung
----- Original Message -----
From: "Dan Sneddon" <dsneddon(a)redhat.com>
To: "Mikyung Kang" <mkkang(a)isi.edu>, rdo-list(a)redhat.com
Sent: Tuesday, November 17, 2015 3:58:37 PM
Subject: Re: [Rdo-list] [RDO-Manager] deploy
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
3288
days inactive
3301
days old
3 comments
2 participants
participants (2)
-
Dan Sneddon -
Mikyung Kang