Can't reach Openstack dashboard on my experiment

[Gautam Thaker]

I am new to openstack. I followed the tutorial at:

https://docs.emulab.net/openstack-tutorial.html

I have profile OpenStack-Ansible  swapped in w/ default settings. (earlier I had swapped in profile=OpenStack and had similar experiences.)  Some of the flow was different from the tutorial, for example I never saw an option about selecting which cloud cluster I would be using, but I assume that is ok. After the experiment swaps in I am not sure how to get to the dashboard. I see:

"Basic Instructions
Once your experiment nodes have booted, and this profile's configuration scripts have finished configuring OpenStack inside your experiment, you'll be able to visit the OpenStack Dashboard WWW interface (approx. 5-15 minutes)." 

but clicking that link tries to open:

horizon/auth/login/?next=/horizon/project/instances/

and it fails. I was not sure so I  even did a   

apt install openstack-dashboard

which completed ok but did not help. Then I realized it was likely the link just does not set up the correct URL, so I manually visited:

http://pc742.emulab.net/horizon/auth/login/?next=/horizon/project/instances/

and I get:  Unable to establish connection to keystone endpoint.

Are there newer/updated instructions to follow?

I did check for 

sudo cat  /root/setup/setup-controller.log
cat: /root/setup/setup-controller.log: No such file or directory

Any help welcome.  (I did wait a few minutes and tried again as suggested.) Same result.

[David M. Johnson]

On 8/4/23 16:03, Gautam Thaker wrote:
> I am new to openstack. I followed the tutorial at:
>
> https://docs.emulab.net/openstack-tutorial.html
>
> I have profile OpenStack-Ansible  swapped in w/ default settings.

Sorry, this profile isn't supported, so I have restricted its use.

> (earlier I had swapped in profile=OpenStack and had similar

The regular Openstack profile
(https://www.emulab.net/portal/instantiate.php?profile=OpenStack&project=emulab-ops)
is supported, up to date. I ran a test just now, changing only the Node
Type parameter to d430, and it came up fine. I was able to start up
VMs, give one a floating IP, ping across the virtual network, using a
block device; stats from ceilometer and gnocchi were present in the
grafana dashboard. Please try again with this profile and the d430 node
type, and if it fails, provide a link to your experiment status page.
Thanks!

> experiences.)  Some of the flow was different from the tutorial, for
> example I never saw an option about selecting which cloud cluster I

Sorry, the cloud cluster selection instructions do not apply to the
Emulab portal that you are using, since it is not "federated" with other
facilities, unlike Cloudlab. The Emulab portal provides access only to
the Emulab cluster, so the selector is not present when creating an
experiment.

David

[Gautam Thaker]

OK, so I am able to run fine using OpenStack profile. I spun up a couple of VMs, gave them floating addresses and I am able to ssh into them etc.

As for the Emulab node CP-1 itself , which is now a d430 running Ubuntu 22.04.2 LTS, I also ran some standard  TCP  socket program that was compiled on another Ubuntu 22.04.2 LTS and brought over.  For some reason  getifaddrs() call returned an answer with  ifa_addr  being zero, and I had not see nthis before in my other testing at many places with this code, baremetal or VMWare, StarLabs VMs, etc so not sure what to make of that but I modified the code to check on that and not deref that if zero. (It may be fine for ifa_addr to be zero in some cases, I just don't know, but sharing FYI.)

My test is to see about networking latencies and thruput on single baremetal d430 two processes (or between two d430s) versus 2 VMs on a single d430 or two VMs spread over two physical d430s with various  openVSwitch etc in between.   This mainly to learn more about software  networks and switches.

Gautam

NAME
       getifaddrs, freeifaddrs - get interface addresses

SYNOPSIS
       #include <sys/types.h>
       #include <ifaddrs.h>

       int getifaddrs(struct ifaddrs **ifap);

       void freeifaddrs(struct ifaddrs *ifa);

DESCRIPTION
       The getifaddrs() function creates a linked list of structures describing the network interfaces of the local system, and stores the address
       of the first item of the list in *ifap.  The list consists of ifaddrs structures, defined as follows:

           struct ifaddrs {
               struct ifaddrs  *ifa_next;    /* Next item in list */
               char            *ifa_name;    /* Name of interface */
               unsigned int     ifa_flags;   /* Flags from SIOCGIFFLAGS */
               struct sockaddr *ifa_addr;    /* Address of interface */                  # <<<<< this was NULL in my run on d430, I have not investigated in depth, may be proper.

[Gautam Thaker]

I  noticed that on my two instances which have their floating IP addresses which I am able to use from the Internet to ssh/rsync in, if I do "ifconfig"  on one of them I don't see the 155.98.37.97 floating IP address on any interface. I only  see the 10.254.1.111 address. 

Is it possible to find a detailed network diagram of my experiment, including showing any VSwitches or any other virtualization SW layers?

My experiment:

https://www.emulab.net/portal/status.php?uuid=c6e10767-3325-11ee-9f39-e4434b2381fc

is using 2 nodes, PC858 and PC852, and it appears both my VMs are on the "CP-1" node (I believe this is PC852). The other node is called "CTL".  If I had 2 compute nodes, how can I control where the VMs get spun up? (May be there was an option to control this, I just dont' remember.) Anyway, I would like to know, if not too difficult, what are all the pathways as pkts travel from VM node a-1  to VM node a-2 (and back.)

Thanks.

[Gautam Thaker]

OK, I found the network topology tab and am able to see this image that I attach. I understand better now. But what is the purpose of flat-lan-1-net?

GHT

[David M. Johnson]

On 8/6/23 20:43, Gautam Thaker wrote:
> OK, I found the network topology tab and am able to see this image that
> I attach. I understand better now. But what is the purpose of
> flat-lan-1-net?

Hi Gautam. The purpose is to allow VMs to communicate directly with
bare-metal hosts (which also have IP addrs on the flat-lan-1-net
subnet), without requiring a floating IP, or some other arrangement.

> GHT

David

[Gautam Thaker]

I don't know if this is important but on pc858  which is ctl box using OpenStack profile, using 'getifaddrs()' call returns  'tun0' interface twice, with first time its address->ifa_addr value is NULL.

# gethostname: ctl.openstack-test-2.corbatests.emulab.net
# Test_start_time: since_epoch 1691592353  asctime Wed Aug  9 14:45:53 2023
# Interfaces returned by getifaddrs()
# tun0             address->ifa_addr  is NULL Mac : 00:00:00:00:00:00
# lo               IPv4  127.0.0.1                       Mac : 00:00:00:00:00:00  Intf. 1, up
# tun0             IPv4  192.168.0.1                     Mac : 00:00:00:00:00:00  Intf. 10, up, full duplex, 10 Mbps
# br-ex            IPv4  155.98.36.158                   Mac : 44:a8:42:48:11:11  Intf. 12, up
# br-flat-lan-1    IPv4  10.11.10.1                       Mac : a0:36:9f:85:82:2c  Intf. 14, up
# lo               IPv6  ::1                             Mac : 00:00:00:00:00:00  Intf. 1, up
# eno1             IPv6  fe80::46a8:42ff:fe48:1111%eno1   Mac : 44:a8:42:48:11:11  Intf. 2, up, full duplex, 1000 Mbps
# enp6s0f0         IPv6  fe80::a236:9fff:fe85:822c%enp6s0f0 Mac : a0:36:9f:85:82:2c  Intf. 5, up, full duplex, 1000 Mbps
# tun0             IPv6  fe80::cf83:1319:766c:4d61%tun0   Mac : 00:00:00:00:00:00  Intf. 10, up, full duplex, 10 Mbps
# br-ex            IPv6  fe80::46a8:42ff:fe48:1111%br-ex Mac : 44:a8:42:48:11:11  Intf. 12, up
# br-flat-lan-1    IPv6  fe80::a236:9fff:fe85:822c%br-flat-lan-1 Mac : a0:36:9f:85:82:2c  Intf. 14, up
# gre_sys          IPv6  fe80::d039:18ff:fe13:5229%gre_sys Mac : 2e:d4:df:e6:ae:02  Intf. 19, up
# tapcdee33cf-48   IPv6  fe80::f816:3eff:fecc:d3f0%tapcdee33cf-48 Mac : fa:16:3e:cc:d3:f0  Intf. 20, up
# End of Interfaces.

[David M. Johnson]

On 8/9/23 08:50, Gautam Thaker wrote:
> I don't know if this is important but on pc858  which is ctl box using
> OpenStack profile, using 'getifaddrs()' call returns  'tun0' interface
> twice, with first time its address->ifa_addr value is NULL.

`getifaddrs` will return an entry for each address family, so this is
expected on most interface types. See pc858:/root/testif{.c} for an
example. And in response to your earlier message about ->ifa_addr being
NULL, this is valid, although uncommon. If you create a new tuntap
device (`sudo ip tuntap add tun99 mode tun`), you'll see this. Most
like this is the point-to-point addr, but I didn't look to verify.

David

> #gethostname: ctl.openstack-test-2.corbatests.emulab.net

> # Test_start_time: since_epoch 1691592353  asctime Wed Aug  9 14:45:53 2023
> # Interfaces returned by getifaddrs()
> # tun0             address->ifa_addr  is NULL Mac : 00:00:00:00:00:00
> # lo               IPv4  127.0.0.1 Mac : 00:00:00:00:00:00  Intf. 1, up
> # tun0             IPv4  192.168.0.1 Mac : 00:00:00:00:00:00  Intf. 10,
> up, full duplex, 10 Mbps
> # br-ex            IPv4  155.98.36.158 Mac : 44:a8:42:48:11:11  Intf. 12, up
> # br-flat-lan-1    IPv4  10.11.10.1 Mac : a0:36:9f:85:82:2c  Intf. 14, up
> # lo               IPv6  ::1 Mac : 00:00:00:00:00:00  Intf. 1, up
> # eno1             IPv6  fe80::46a8:42ff:fe48:1111%eno1 Mac :
> 44:a8:42:48:11:11  Intf. 2, up, full duplex, 1000 Mbps
> # enp6s0f0         IPv6  fe80::a236:9fff:fe85:822c%enp6s0f0Mac :
> a0:36:9f:85:82:2c  Intf. 5, up, full duplex, 1000 Mbps
> # tun0             IPv6  fe80::cf83:1319:766c:4d61%tun0 Mac :
> 00:00:00:00:00:00  Intf. 10, up, full duplex, 10 Mbps
> # br-ex            IPv6  fe80::46a8:42ff:fe48:1111%br-ex Mac :
> 44:a8:42:48:11:11  Intf. 12, up
> # br-flat-lan-1    IPv6  fe80::a236:9fff:fe85:822c%br-flat-lan-1Mac :
> a0:36:9f:85:82:2c  Intf. 14, up
> # gre_sys          IPv6  fe80::d039:18ff:fe13:5229%gre_sysMac :
> 2e:d4:df:e6:ae:02  Intf. 19, up
> # tapcdee33cf-48   IPv6  fe80::f816:3eff:fecc:d3f0%tapcdee33cf-48Mac :
> fa:16:3e:cc:d3:f0  Intf. 20, up
> # End of Interfaces.
>

> --
> You received this message because you are subscribed to the Google
> Groups "emulab-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emulab-users...@googlegroups.com
> <mailto:emulab-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emulab-users/50de9a8b-765d-467f-8524-2da008acf970n%40googlegroups.com <https://groups.google.com/d/msgid/emulab-users/50de9a8b-765d-467f-8524-2da008acf970n%40googlegroups.com?utm_medium=email&utm_source=footer>.