[Rdo-list] [RDO-Manager] deploy
Mikyung Kang
mkkang at isi.edu
Mon Nov 30 19:37:22 UTC 2015
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 at 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 at isi.edu>
To: "Dan Sneddon" <dsneddon at redhat.com>
Cc: rdo-list at 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 at 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 at 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 at 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 at gpu6 ~]$ openstack overcloud deploy --templates
Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates
hang....?
[root at 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 at 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 at 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 at 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 at 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 at redhat.com>
To: "Mikyung Kang" <mkkang at isi.edu>, rdo-list at 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/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 (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 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
interface.
--
Dan Sneddon | Principal OpenStack Engineer
dsneddon at redhat.com | redhat.com/openstack
650.254.4025 | dsneddon:irc @dxs:twitter
More information about the dev
mailing list