Can manage IQ create forms based on info autodiscovered?

[flechoide]

Hello, not sure if that's the right place to ask, we have an awx instance with Ansible playbooks,and we are willing to create forms for our internal teams in order to get something better than the awx survey ,but we realize it will take a lot of effort with custom scripts to get proper forms .

I would like to know if the "facts" that manageiq autodiscover are available when creating forms , from on premise servers or kubernetes clusters, or VMware infra or whatever, so for example if I want to modify some fata from a kubernetes namespace,the original data "autodiscovered" can be shown at the form ?

[Fryguy]

I'm not exactly sure what you are asking, so I have some questions. Is this for the service catalog? That is, are you looking to create a dialog when someone orders a catalog item with more dynamic fields?

[flechoide]

Hello, yes, for what Ive read from the getting started guide, I think its the service catalog . What Im looking for is for a tool that allows us to create complex forms populated by users and by data from our kubernetes clusters or our on premise servers running on kvm .

For example if we want to create a form that allows some project manager to modify an existing kubernetes service, we are looking for a tool that allows us to retrieve data from the kubernetes cluster and stores that data (like some kind of puppet or ansible facts) and allows us to create forms based on that data, for example showing up the labels inside the namespace etc .

[Fryguy]

I see, so there's a number of things you can do after the initial setup. What you would do is create a dynamic dialog with dynamic dropdowns that run some automate code. In the automate code you can do a lot, and I won't go into the detail here, but you can run Ruby or ansible, for example.

• If the data is already in the ManageIQ database, you can use it directly by having automate query the dataase throught the service model. For example, those kubernetes labels may already be available since we collect those already. This is likely the "best" solution, if possible, since you aren't making a live call to kube, but still getting near-real-time data.
• You can make a live call to kubernetes every time the dialog is run. This can be tricky if the API call fails and you will have to handle error conditions.
• You can write your own collector that stores the data as generic objects. The hook for running your collector would live in automate, and you can run it based on a schduled event or some kubernetes event, such as if something changes in kubernetes itself.

Hope that helps.

[flechoide]

That helped a lot, thats what we are looking for . Thanks!