I have been working with CloudForms/ManageIQ for almost a year and had issues when my customers requested to manage other objects than VM/Host/Datastore. As pointed out in the thread “Breaking Free from Virt Management”, it would be great if ManageIQ were able to handle other objects.
So I started playing around with the object model in Automate Engine datastore. While it is not a true object model, as in Object Oriented Programming, with a few conventions one can simulate a pretty good model. For example, I created a /Objects namespace (in a custom domain) that is meant to store new object classes. In this namespace, I created a class named Objects which is meant to be the mother of all other classes in the namespace and that sets the minimum requirements.
- A method called
get_object_type - A method called
get_object_provider - A method called
get_object_instance - A relationship called
attributesthat points to/Attributes/${#type}/${#provider}/${#instance} - A relationship called
methodsthat points to/Methods/${#type}/${#provider}/${#instance}
This is meant to implement a Factory-ish pattern.
One just has to create a sub-namespace per object type that will contain a single class named after the type. Let’s say we want to be able to manage stacks, we create the /Objects/Stack namespace and a class called Stack within this namespace. This class is an abstract class for all the stack objects and links to /Attributes/Stack// and /Methods/Stack// (how is it interpreted by ManageIQ ?) to set the attributes and methods of a generic stack, from ManageIQ point of view.
Then one creates a class for each provider, such as AmazonWebServices or OpenStack. For example, the OpenStack class points to /Attributes/Stack/OpenStack/ and /Methods/Stack/OpenStack/. This sets the extra attributes for an AWS or OpenStack stack.
At last, one creates an instance of stack in /Objects/Stack/OpenStack that sets the real attributes.
It would look like that :
/objects/
- object.class/
- meth: get_object_type
- meth: get_object_provider
- meth: get_object_instance
- rel: attributes => /Attributes/
- type/
- type.class
- attr3
- meth3
- provider.class/
- attr4
- meth4
- instance/
- attr5
- meth5
/attributes/
- /type
- /provider
- /${#instance}
/methods/
- /type
- provider.class/
- method1
- method2
I am now facing issues with inheritance in the thread Class inheritance in the AE Datastore. But knowing the behavior is a first step to adapt to it 
And then, one can imagine that existing built-in objects could also be exposed and managed through AE Model. And we could easier extend the current model.
Going further, we have an issue when we want to manage the objects through the WebUI. This subject might have a thread on its own, to figure the future of a dynamic UI. One of my thought would be using some kind of annotation that would make the objects available through WebUI. For example, an boolean attribute called ui and a set of methods to expose the data to the UI. It would require the UI module to have a bit of logic…
It is the same for reports. The generic objects won’t be available for reporting.
Your opinions/advices/… are welcome.
