Hi
I have deployed Openstack with maas and juju charms ,
All the juju charms services are green
admin project is not created in the dashboard , Not able to see any compute nodes ,
i am missing any operation here .
There are many things which can easily cause network/service errors that will not affect the ability of the charms to properly deploy and configure the services when it comes to the advanced networking requirements of openstack. The charms deploy and manage the configuration of the services and software, however, they are not fully responsible for day to day failures of the software. Monitoring software can help in that case. It would likely be useful to see an exported bundle (sanitized to remove any passwords/secret data/public network information/etc) from your cloud to delve further into possible configuration issues as well.
Some things I’ll note from your screenshot, it appears that Horizon is able to properly communicate with Keystone, as you’ve properly received a token and logged into the admin project under the admin_domain. The errors listed relate to neutron and cinder API services being unavailable from horizon. I recommend investigating the access to the endpoints listed in “openstack endpoint list” (via openstack cli with your novarc credentials) from the openstack-dashboard unit(s) of your cloud to ensure proper network access between the units, and then check the status of the services running.
You may also find usefulness in the nagios and nrpe charms to add monitoring of service status, load/disk/ram health, and any errors with hacluster units, if deployed, which may indicate operational errors within your stack.
juju deploy nagios
juju deploy nrpe
juju add-relation nagios nrpe
juju add-relation nrpe nova-compute
juju add-relation nrpe nova-cloud-controller
juju add-relation nrpe cinder
juju add-relation nrpe neutron-api
etc...
Any charm with an nrpe-external-master relation can be related to nrpe to add monitors into nagios.
You can then retrieve the nagiosadmin credentials per the documentation of the nagios charm, and view anything that may be alerting in your cloud that might provide clues to the underlying problem.
1 Like
If you attempted to deploy stein on bionic with SSL communication it simply won’t work… At least for the next couple of days/weeks.
This is a known issue with nova. There is a fix in the pipeline which has gone through the gating and should be landing soon. Today is T-1 release milestone so if everything goes fine all stable branches will receive a new package version. Once released there might be a delay before seeing this in thr upstream.
You can also simply manually patch it.
Info here : https://bugs.launchpad.net/bugs/1808951
i removed everything deployed bundle again Having only public names of VIP , it worked fine … Now everything is working fine .
======
i want to add the ssl to have https enable when i used below command it is giving me error did i miss anything
This appears to be a CLI limitation and you will probably have better success using a bundle.yaml file or charm-config.yaml file to add these configs.
Hi Dears @afreiberger @fguitton , I have deployed openstack bundle but I have some problem in the dashboard. I can access to the main page and perform any operation in Project section of the dashboard, but I can’t access or perform anything in the Admin and Identity section as below screenshot. I am suspecting wrong binding to network space related to the dashboard which is:
openstack-dashboard:
charm: cs:openstack-dashboard-280
num_units: 3
bindings:
"": *oam-space
public: *public-api
shared-db: *internal-space
I find some examples binding the dashboard default endpoint to public network space but what I did is mapping the default to juju mgmt space (which the only one have net access) and binded public endpoint to public space. is this possible or it is the cause for my problem?
Certain cloud admin functions must happen in keystone to the admin endpoint, which may be what you are experiencing.
Make sure your admin: binding on keystone and your identity-service: binding on horizon match up would be my first thought. It appears from your screenshot that all your endpoints are the same oam-space for keystone, and your default binding on dashboard is oam-space, so this shouldn’t be an issue. I’d check your horizon and keystone logs for more details.
You can dump your deployed model (juju export-bunde) and check what the keystone admin binding is being set to. if it’s being set to *oam-space, your config appears as if it should work, but there are many variables when it comes to networking that are not easily able to be troubleshot by bundle configs alone.
Beyond this, you may wish to consider our Ubuntu Advantage support for Ubuntu, Juju, and Openstack.
Hello hshtel,
Can you post your bundle.yaml I like to see how is configured?