Open Stack

On Thu, 2020-04-16 at 20:28 +0200, Ruslanas Gžibovskis wrote:
> Hi all,
> 
> Introspection of remote node passes, but when I run provide, or I run
> introspect and provide at same time, it fails:
> (undercloud) [stack at remote-u ~]$ overcloud node introspect --provide
> 489f0081-0ebb-4c70-af6d-de844623f89c 
> Waiting for introspection to finish...
> Waiting for messages on queue 'tripleo' with no timeout.
> Introspection of node 489f0081-0ebb-4c70-af6d-de844623f89c completed.
> Status:SUCCESS. Errors:None
> Successfully introspected 1 node(s).
> Waiting for messages on queue 'tripleo' with no timeout.
> [{u'result': u'Node 489f0081-0ebb-4c70-af6d-de844623f89c did not
> reach state "available", the state is "[u\'clean wait\', u\'clean
> wait\']", error: [None, None]'}]
> Failed to set nodes to available state: Node 489f0081-0ebb-4c70-af6d-
> de844623f89c did not reach state "available", the state is "[u'clean
> wait', u'clean wait']", error: [None, None]

The 'clean_wait' state is most likely ironic wating for ironic-python-
agent to boot->callback->clean the node.

> (undercloud) [stack at remote-u ~]$ baremetal port list
> +--------------------------------------+-------------------+
> | UUID                                 | Address           |
> +--------------------------------------+-------------------+
> | 0e76f1eb-0a73-43db-b6ec-44a34bcdac55 | b4:96:91:13:ff:c0 |
> | ea97d28c-b78e-4b1d-8662-a4254fad38fc | 24:6e:96:14:a1:a4 |
> +--------------------------------------+-------------------+
> (undercloud) [stack at remote-u ~]$ baremetal port show ea97d28c-b78e-
> 4b1d-8662-a4254fad38fc
> +-----------------------+------------------------------------------
> ----------------+
> | Field                 | Value                                      
>              |
> +-----------------------+------------------------------------------
> ----------------+
> | address               | 24:6e:96:14:a1:a4                          
>              |
> | created_at            | 2020-04-16T10:24:08+00:00                  
>              |
> | extra                 | {}                                        
>               |
> | internal_info         | {}                                        
>               |
> | is_smartnic           | False                                      
>              |
> | local_link_connection | {u'port_id': u'568', u'switch_id':
> u'80:ac:ac:f8:14:c0'} |
> | node_uuid             | 489f0081-0ebb-4c70-af6d-de844623f89c      
>               |
> | physical_network      | remote-provision                          
>               |
> | portgroup_uuid        | None                                      
>               |
> | pxe_enabled           | True                                      
>               |
> | updated_at            | 2020-04-16T15:26:43+00:00                  
>              |
> | uuid                  | ea97d28c-b78e-4b1d-8662-a4254fad38fc      
>               |
> +-----------------------+------------------------------------------
> ----------------+
> (undercloud) [stack at remote-u ~]$
> 
> any ideas?
> 

Looks like you got the physical_network correct, since you are in
clean_wait state I belive the port binding worked.

I would a) Look at the console of the server try to figure out why it
did'nt boot. b) tcpdump the traffic in the neutron qdhcp namespace, is
it reciving/responding to DHCP requests? Look for tftp logs, is it
transferring the network boot program?

Is the dhcp-relay service relaying request to both dhcp server?
Inspector and cleaning/provisioning uses different dhcp servers which
bind to different IPs.


--
Harald

> 
> On Tue, 14 Apr 2020 at 23:49, Harald Jensås <hjensas at redhat.com>
> wrote:
> > Hi Ruslanas,
> > 
> > The tripleo documentation have a decent section[1] on deploying an
> > overcloud with overcloud nodes on a routed network. It shows how to
> > configure the remote networks in undercloud configuration, what
> > addresses the dhcp-relay should forward requests to and how to set
> > the
> > baremetal port's physical network attribute (i.e what maps host A
> > to
> > network A, and host B to network B).
> > 
> > 
> > --
> > Harald
> > 
> > [1] 
> > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/routed_spine_leaf_network.html
> > 
> > 
> > On Tue, 2020-04-14 at 08:19 +0200, Ruslanas Gžibovskis wrote:
> > > Hi all,
> > > 
> > > My remote network is a different one: 10.41.94.240/28, just in
> > case
> > > :)
> > > 
> > > Should I add the remote network or subnet to my existing network
> > in
> > > undercloud? Or new subnet, which is configured on remote site? 
> > > if yes,
> > >   how to specify, that A host should be used on the A network,
> > and B
> > > host on the B network.
> > >   how to add it? 
> > > fi
> > > 
> > > I believe FW is all to all. But at this stage, my main concern is
> > > that I do not get any info into log in dnsmasq.log
> > > 
> > > Any thoughts?
> > > 
> > > 
> > > On Sun, 12 Apr 2020 at 21:39, Ruslanas Gžibovskis <
> > ruslanas at lpic.lt>
> > > wrote:
> > > > Hi all,
> > > > 
> > > > Could someone help me, I do not get, I try to boot remote host
> > > > (behind Firewall). I have dhcp-relay configured. And finally, I
> > see
> > > > the DHCP request, but nothing else happens... except me crying
> > ;'(
> > > > "D
> > > > 
> > > > 
> > > > DHCP request captured on undercloud vnet5 where dhcp is
> > listening
> > > > also on eth1, But I am not able to load a remote host. I had a
> > > > thought, maybe DHCP is generally not working, but one node
> > which is
> > > > local, I am able to introspect and provide it.
> > > > completely nothing in /var/log/containers/ironic-
> > > > inspector/dnsmasq.log
> > > > 
> > > > Any suggestions?
> > > > 
> > > > My network, which I used and have configured on undercloud host
> > is:
> > > > 10.120.191.80/28 and IP for DHCP which is configured as dhcp
> > relay
> > > > is 94.
> > > > 
> > > > output from tcpdump:
> > > > 21:19:00.058565 40:a6:77:4b:07:cb > 52:54:00:20:c1:dc,
> > ethertype
> > > > IPv4 (0x0800), length 590: (tos 0x0, ttl 58, id 60458, offset
> > 0,
> > > > flags [none], proto UDP (17), length 576)
> > > >     10.41.94.241.67 > 10.120.191.94.67: [udp sum ok]
> > BOOTP/DHCP,
> > > > Request from 24:6e:96:14:a1:a4, length 548, hops 1, xid
> > 0x9614a1a4,
> > > > secs 12, Flags [Broadcast] (0x8000)
> > > >  Gateway-IP 10.41.94.241
> > > >  Client-Ethernet-Address 24:6e:96:14:a1:a4
> > > >  Vendor-rfc1048 Extensions
> > > >    Magic Cookie 0x63825363
> > > >    DHCP-Message Option 53, length 1: Discover
> > > >    Parameter-Request Option 55, length 36: 
> > > >      Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
> > > >      IEN-Name-Server, Domain-Name-Server, RL, Hostname
> > > >      BS, Domain-Name, SS, RP
> > > >      EP, RSZ, TTL, BR
> > > >      YD, YS, NTP, Vendor-Option
> > > >      Requested-IP, Lease-Time, Server-ID, RN
> > > >      RB, Vendor-Class, TFTP, BF
> > > >      Option 128, Option 129, Option 130, Option 131
> > > >      Option 132, Option 133, Option 134, Option 135
> > > >    MSZ Option 57, length 2: 1260
> > > >    GUID Option 97, length 17:
> > > > 0.68.69.76.76.57.0.16.56.128.80.200.192.79.56.68.50
> > > >    ARCH Option 93, length 2: 0
> > > >    NDI Option 94, length 3: 1.2.1
> > > >    Vendor-Class Option 60, length 32:
> > > > "PXEClient:Arch:00000:UNDI:002001"
> > > > 
> > > > -- 
> > > > Ruslanas Gžibovskis
> > > > +370 6030 7030
> > > 
> > > 
> > 
> 
>