The topic of Providers and Managers in the ManageIQ codebase comes up from time to time, but since we’re in the middle of looking at re-architecture strategies for core ManageIQ, this seems like a fitting time to actually tackle this problem.
Who should stop reading now?
If you’ve never looked at the ManageIQ data model, or if you’ve never cared about the relationships between provider-specific model objects. If you haven’t had coffee yet. If really really like spaghetti code and want it to stay that way. If you have never been struck with omphaloskepsis.
Problem
Some provider integrations use the Provider model, and others don’t. Some providers don’t seem to need it, while others that might benefit from it don’t use it. It boils down to: consistency.
But, like anything, once I started thinking about this, I started peeling back the layers of the onion and finding underlying problems that either could be fixed at the same time, or need to be addressed to move this topic forward.
So, I wanna lay out what I’m seeing, and I want others to chime in with what they’ve come across and any ideas they have for making this a better model.
Background (in semi-nonfictional prose)
Originally, there was ext_management_system, and it was good. It served the purpose of modeling virtual infrastructure management systems wherein each installation (or, endpoint) was a singular self-contained thing, and it was not overly complicated.
Enter OpenStack, stage left. This guy strolled into town and upended many classical ideas. Namely, that it’s possible for a single connection definition to carry the burden of an entire management system. So began hard coding, like what endpoint to use when fetching events from OpenStack.
But, OpenStack and Amazon teamed up to say, “What if you only want certain pieces of AWS or OpenStack (like Storage or Networking), and not the whole thing?” And, you better believe that the PMs were excited over this!
Engineering began wrestling code that enabled the idea of splitting out parts of providers into separate managers. And, from the rooftops, they shouted: "Ext_management_system is dead! Long live ext_management_system." Because the Manager was born, and it was ext_management_system that would maintain control over the various type of managers in a provider.
But, it wasn’t the end of the journey, because in a smoke-filled room sat @kbrock and @bdunne conspiring to make solid the amorphous nature of this new “provider” concept. Through whatever incantations were used that day, the Provider model was born. But, only the Foreman provider knew anything about the new model. And, it would remain so for countless days.
The great provider namespacing was well underway by this time, which would be lauded by some and berated by others. But, in the end, all provider implementations were relegated to their namespaces, to live out their days in isolation. Little did they know that this was only the beginning, and while namespacing separated brother from brother, the separation of repositories that followed would literally tear code families apart.
There lived the code, separated. And, never knowing that only some of their distant relative provider integrations were using the Provider model, while others were not.
Seriously though … why are you still reading?
Because, this is a real problem. If for nothing else other than consistency, we should figure out the right way to model Providers. But, there are lots of concepts to consider.
Rules for the game
Before diving in, let’s set some ground rules:
- Forget what you already know about the
ProviderandManagermodels. Let’s assume we can start from scratch. It’s possible that later we’ll have to guide this conversation back to “How does this fit with the current model?” But, let’s cross that bridge later. - Ignore ManageIQ
zonesandregions…for now. I don’t know what’s happening with those after the re-architecture (maybe nothing), but I don’t want to get caught up in those details right now. - Let’s not go too far down the rabbit hole. I don’t want to talk about the details of each provider’s idiosyncratic model objects. It’s less important for this discussion to know that Container Management has pods or that Physical Infrastructure has firmware. It’s more important to know that some cloud managers use a “master account” while others use “subscriptions”.
Where do we start?
I don’t know. But, I’ll take a stab.
Provider accounts and tenants
One of the things that I think is going to drive this discussion is how providers create boundaries around things ManageIQ might consider “accounts”. Today, a provider in ManageIQ can have only one account.
For AWS this means that you have to decide whether you’re going to select a Master Account or a subsidiary account when setting up the provider.
Azure, on the other hand, has a concept of Subscriptions that are being used to segregate billing. Currently ManageIQ treats each subscription as a unique provider instance.
For OpenStack, there’s really only one account, but OpenStack has tenants that create barriers between objects inside the provider.
And, vSphere has no real concept of tenants or any way to reliably separate objects into useful groups.
It’s important to understand all of the scenarios here and ensure that we’re capturing the concepts in a way that doesn’t immediately alienate other providers.
I think if @bascar, @jonnyfiveiq, and @loicavenel can collectively brainstorm here a bit on what we want the different Provider Accounts to look like here from ManageIQ’s perspective, we can have a good discussion about how that model shapes up.
Provider services
ManageIQ eventually dealt with the problem of connecting to multiple services by introducing endpoints. But, this still heavily relies on the legacy authentications model that serves two very different masters: Provider connection credentials and provider object connection credentials.
Wait, what?!
The authentications table holds credentials for connecting to provider accounts (i.e., the provider API connection) and the same table holds credentials for connecting to hosts and VMs inside the provider. In general, this seems like a fine idea. It’s all just a bunch of credentials, but it’s the relationships and assumptions made about those relationships in the AuthenticationMixin that make it hard to tease apart these two concepts.
Nonetheless, I believe that we have to deal with the notion that Providers have several services they offer. Those services can usually be categorized as one of:
- Inventory API
- Disk API (SmartState)
- Event stream
- Metrics data
Maybe it’s time to actually model this concept. Maybe that fits into the endpoints model. Not sure…
Providers and Managers
Some of the initial business driver from separating out the Managers from Providers was to create an isolation context such that someone might someday be able to use, say, AWS S3 without having to setup or care about an entire AWS provider (e.g., I don’t care about EC2 and instances, I only want S3 and buckets).
But, I don’t know that this is actually happening in the field. Or, maybe we didn’t do a good enough job separating it to be able to leverage it this way. It’s completely unclear to me. What I do know is that we ended up implementing something that doesn’t seem to be used the way we thought it would.
So, do we even need to expose this notion of separate managers at all? I mean, internally, it might make sense to segregate certain functionality into different scopes. But, what’s the point of exposing that concept to the end user, unless it’s going to be used in some interesting way?
User Experience
We have a lot of learning to do here, imo. We have separated out Networking, Storage, and Compute. But, while we support Virt Infra, Cloud, Containers, and Physical Infra for Compute, we only really support Cloud for Networking and Storage. Meaning that while we have top level navigation that shows Networking, you’re only going to find cloudy things there. But, if you look in Compute, you’re going to find all kinds of objects intermingling.
If I setup an AWS provider today, I automagically get a Networking and Storage manager. But, I didn’t know those things were created. If I go look at Networking and Storage later, I may be surprised to see things there relating back to AWS. And, I can’t create a Networking or Storage manager. I can only see them once their created after adding a Cloud Compute manager.
I don’t know how to clearly define what the user experience should be. I can just say that even when I limit the scope to just Providers and Managers, I’m overwhelmed and confused as a user. And, I want to make absolutely clear here that I’m not laying blame on the UI team for this. The notions behind Providers and Managers was a massive cross-team effort, from PM, Backend Eng., and UI Eng.
Others?
Probably … I got tired typing though. I’ll try to revisit this. But, I wanted to get this out in the open and start the discussion.
If you have feedback, questions, comments, disagreements, tomatoes, or accolades, please don’t hesitate to add comments.
…
for tackling this, the multiple managers thing makes sense in theory but I’ve never seen the benefits in reality coupled with “duplicate” refresh/event workers it’s always seemed to be more trouble than it’s worth. Maybe splitting the managers at the ext_management_system level was too far up the stack?