Once OpenStack has been deployed you can use the OpenStack dashboard (Horizon) to manage it by using a web UI. To get the URL of the dashboard use the dashboard-url command:
sunbeam dashboard-url
Sample output:
http://10.20.20.2:80/openstack-horizon
This URL points to Horizon login page. The credentials to use are stored in a previously generated credentials file (e.g. demo-openrc).
The login page asks for three pieces of information. For example:
User Name:demo Password: ******** Domain:users
The password is the value of variable OS_PASSWORD in the credentials file.
The login page looks like this:
After a successful login, you should see the landing page:
You can now start managing your OpenStack cloud (e.g. create additional users, launch VMs, etc.).
As I see the documentation, wouldn’t it be more interesting to specify the URL / IP / Network we want for the dashboard or the assumptions are :
Users have a proxy doing the redirection
Users access the dashboard of the locally deployed Openstack
I may be more specific on my remark.
Usually when we deploy an Openstack the dashboard needs to be exposed on an accessible IP, maybe on management network. When we follow this documentation it appears that its on the internal deployed Network. Isn’t it a problem? Or has it been considered that.
For short, please can you add details to expose dashboard on the “external” network on the documentation?
Don’t hesitate to ask me if its still unclear.
Thanks
By sudo socat -v tcp-listen:80,fork tcp:172.16.1.12:80 (where 172.16.1.12 is given by sunbeam dashboard-url) I can get access to the dashboard in a browser on my laptop.
I’m looking for equivalent iptables rules. What I use as below does not work!
The single-node quick start tutorial is completely sandboxed - no API’s or instances created are accessible from outside of the machine where MicroStack is installed. This is entirely intentional.
That said its pretty easy to perform an all-in-one install which is accessible outside of the machine; when providing the range of IP addresses for MetalLB during the bootstrap process provide a range from a subnet that the server is attached to, and do the same again when configuring the subnet and IP address range for access to instances.
In case of a multi-node deployment, you mean the whole both networks, mentioned on the guide , should be accessible from the outside, right? Then Doesn’t it create a security issue that the API and management range are the same? Because we are publishing the range API publicly! Some deployment methods, such as OpenStack-Ansible, isolate the API range on a separate bridge.
The network details in documents for both singl/multi node deploynent are the same!