OpenStack Infrastructure Integration

Developers
#1

sseago had a good question on IRC today that I wanted to bring up here: “why wouldn’t the [OpenStack] infra provider just take the place of the cloud provider for people who want to know about hosts?”

I found myself struggling to come up with a solid answer.

The best answer I have in my head is: we should do it this way initially because we’re eventually changing the way providers work in general and this functionality will end up finding a new home in a slightly different form then, anyway.

But, I suspect there’s a better answer around use cases and personas that could better answer this.

For instance, I would guess that there are ManageIQ users that would be more concerned with the management of the infrastructure layer of OpenStack (sysadmins, etc…) and other users who are more concerned with the cloudy side of OpenStack (self service users, etc…).

The main overlap here is that in both the infrastructure layer and the cloud layer, users will be able to (should be able to?) provision instances.

That becomes a technical problem to figure out how to tie together instances provisioned from the infrastructure side that show up in the inventory of the cloud side (or vice versa).

Thoughts?

#2

This:

Users with different roles would be able to see/interact with different aspects of the cloud/infrastructure.

However:

It’s not clear to me if users should be able to provision directly into an infrastructure on which a cloud is based. But then again, if they are managing the cloud at the infrastructure-level, they should know what they’re doing, so why restrict them.

#3
  1. If a user is not using TripleO or some other infrastructure based system, then they have to use the cloud way. This cannot change.
  2. Is the infra way a superset of the cloud way? That is, will it have all the data? Somehow I think it won’t, but that question would partially answer this. In that case someone might set up the infra vertical, but not the cloud vertical.
  3. I see the cloud being used by users for self-service provisioning, and infra being used by admins for backend stuff. These are two completely different points of view. A sideways relationship or sharing a similar backend object would allow us to figure out how they are interrelated.
#4

I see this boiling down to two different viewpoints.

  1. A purely functional view of what makes sense for implementation … i.e., what makes the most sense for coding this up?
  2. A view based on personas and user stories … i.e., what makes the most sense from the users’ point of view

I think for the purely functional view it’s a matter of what’s providing the data. In the case of OpenStack there’s going to be two separate Keystone servers providing access to a different set of services. Or, at least that’s my understanding.

When talking about ExtManagementSystems in ManageIQ, the definition of that object is the connection details for the appropriate API.

So, since there are two separate connection endpoints to get two separate collections of data, I guess it still makes sense to keep the Infra and Cloud pieces of the OpenStack provider split.

When thinking about the user perspective, I have a feeling that @Fryguy is right. I think the users who care about the infrastructure stuff will be different users who care about the cloud stuff. Except in only a few unique cases. For instance, the IT networking team would likely care about the network for the infrastructure (which we would probably not collect anyway) and the security groups setup in the cloud side.

But, as an example, scaling out VMs affects a very different user from scaling out physical hosts.

#5

I have a very specific enterprise production use case. We are proposing to provide a managed private cloud service to a client. The client wants self service, orchestration and automation. Our internal admins on the other hand want to be administer the cloud and the hosts on which it sits on.

So do correct me if I’m wrong but our customer’s instances is on the same infra that we manage. So how can we do both?

#6

Hello gio888,

this is a common and well understood use case. You can use the RBAC in the product to allow your customer to access the self-service catalog only, and set up a different access level for your administrators.

If this is a commerical offering I would recommend to talk to your Red Hat sales representative about CloudForms. CloudForms is the commercially supported and hardened version of ManageIQ. ManageIQ only get support via this community. Also there are no backports. Any security or stability issues are fixed in the master branch only and are not backported to the community release (currently Botvinnik). You’d have to wait until Capablanca to get the updates, or use master, or backport these yourself.

Feel free to PM me for more information.

Regards,
Geert

#7

Hi @geertj. Thanks for the reply.

I understand RBAC and the differences between MIQ and CFME.

What my question was is this: if we have 1 cloud environment where do I add it? As cloud or as infra? If cloud then we only get visibility up to instances level. But if infra I can get deeper visibility. Are those 2 mutually exclusive?

Pls do pardon me if I still don’t how this should be done.

#8

Only in the case of OpenStack, it can be added to both Cloud and Infra.

The Cloud side of OpenStack is the tenant level. It connects to the Nova and other APIs of the “normal” OpenStack that everybody knows

The Infra side is specific to OpenStack installations that have been deployed with RDO Manager/RDO Director or (in theory) other TripleO based installers. In such installations there is an “undercloud” OpenStack that manages the hardware. Instances in the undercloud are the hypervisors of the overcloud. The undercloud uses Ironic as the Nova driver.

Other providers don’t have this distinction. VMware, SC-VMM and RHEV are purely infra. AWS is purely cloud.

Does this answer your question?

#9

Yes. So to be able for us, a service provider, to provide both instance level management and host or node level management at the same time, we will have to do TripeO installation of OpenStack and add it as infrastructure. Thanks.