1 of 1 people found this helpful
The November 2017 TKU provides complete OpenStack discovery.
3 of 4 people found this helpful
Provided you are running Discovery 11.2.
What I can see in the new TKU of november for BMC Discovery
1) you need Discovery 11.2
2) you need credential to access to the REST API of your OpenStack (more or less Admin credential with full access to all projects)
3) the Discovery of this kind of OpenStack needs new licences for Cloud Discovery ...
4) you need to create a Discovery Cloud job for each OpenStack
5) this Discovery will create a Cloud Provider, link this one to a Nova Provider (VMs) and Cinder Provider (VolumesStorage)
6) at this time I don't see any link between Nova and Cinder information (it seems he asks some information from Keystone, NeutronLoadBalancer too, but I don't know, it is not working at this time on my BMC Discovery)
I don't check Relation between Host and VM discovery by this method,
The bad points from my point of view :
1) New licence
2) It seems we don't have any link between real infrastructure discover before like my Storage stuff, you could obtain 2 views, one with your old discovery stuff, and a second with this cloud job, and I am not sure about the quality of the relation between, I will check that on monday.
3) One job by OpenStack
4) you don't have the same granularity and model as for VMware
At this time and from my point of view, we improve a little bit the reality when we say "provides complete OpenStack discovery". I hope I will find a way to have a better view of what BMC Discovery is able to do next week.
Hopefully, I already work by myself on OpenStack discovery with BMC Discovery 11.2 and the new REST API Discovery provide, so I succeed to have something more like that Hypervisor (OpenStack) -> Virtual Machine (Novaa) -> Volume Storage (Cinder) -> Storage Device
2 of 2 people found this helpful
Just a few points about scanning OpenStack:
Discovery can potentially see OpenStack from two directions:
1. By scanning the hosts running the OpenStack software (Keystone, Nova, Cinder etc) using ssh. In this case, Discovery will create SoftwareInstance nodes related to each Host. With access to the configuration files, the various SIs will be linked up with dependencies, including links to MariaDB and RabbitMQ. This will also see things like the KVM VMs (or whatever) for the Nova Compute instances, HA Proxies for Neutron LoadBalancers
2. By scanning the OpenStack cloud itself by the API. This requires a new credential which is specific to the OpenStack (Keystone) API. This doesn't NEED admin rights but there is a bunch of information you don't get without it (see below).
When scanning the OpenStack cloud, the patterns will look for existing VM and LoadBalancer nodes which represent the Nova compute/Neutron LB instances. If found, these nodes will also be linked to the cloud service giving you a view of how the infrastructure supports the private cloud. If existing nodes aren't found, then new nodes for the Nova/Neutron resources will be created: these will be destroyed on a subsequent scan if the Hosts running OpenStack have since been scanned (i.e. we try very hard to avoid having duplicate nodes to represent the same things)
However, without admin rights we can't tell which VMs are running on which hosts which makes it impossible to connect things together properly. In this case you WILL get two copies of each VM, one seen from the Host and one seen from Nova without any connection between them. We also can't access all projects, only those the user has access to - this may or may not be a problem.
You do currently have to set up a scan for each OpenStack instance you have. We have assumed that most customers wouldn't have very many separate installs?
You should see the linkage from Virtual Host -> Nova VM -> Cinder Volume -> Storage Device. It might require two scans to see it all as we can only perform the final linkage step from the Storage Device end.
Finally, I don't quite understand "ou don't have the same granularity and model as for VMware"?
Thanks for the clarification,
You are right to say OpenStack can be discovered by two ways. The sad fact, it seems at this time we don't do any relation between those ways.
It is really sad because I am pretty sure we can link Cinder/Nova by using information in the API, Nova can be link to Virsh, and Virsh is linked by your patterns to the Host, so with just a little bit of work we can have all the stacks (and impact) from the Storage/Hypervisor to Host/Software.
In your story, OpenStack CloudDiscovery is not useful for a big part of customers who uses OpenStack in their infrastructure. And the legacy Discovery who find the Virsh on the Hypervisor will not provide enough information compare to VMware Patterns. (nothing about storage for example)
1 of 1 people found this helpful
Thanks for the feedback. We are looking at ways to improve completeness of Openstack and will consider your comment above.
What is done with Cloud Discovery is definitely a step forward to Openstack customers. A point I also want to make is that there might be some misunderstanding in terms of how this is licensed: multi-cloud discovery is not an added cost above standard discovery (it is either or). Please PM me if you need more information.