Role that allows capturing the data structure of created objects

[tenletters10]

Is your feature request related to a problem? Please describe.
Junior developers new to AAP often struggle to define their data structures for creating objects used in the dispatch role. Although we have an internal document with examples of common object types (job templates, creds, controller projects, eda projects, inventories, eda rulebook activation, EEs, DEs, etc) they face challenges with the variety of configurations and nesting, especially with job templates. Often, these challenges involve obtaining the appropriate key or values required, or using the correct type of data (such as integers, strings, lists, bool, etc).

They frequently troubleshoot failed dispatch runs while trying to "codify" objects created manually in the GUI for deployment. Debugging the error messages from these failed deployments is often difficult for them.

Describe the solution you'd like
Have a role created that can be given any type of object that can be created currently by infra.aap_configuration be able to be targeted by object type and name and extract the values. I do know this data is available at the API view, but it is often hard for the developers and cumbersome to browse the API explorer to find the object.

Using the API explorer to obtain a configuration of an AAP object includes capturing all default values. It would be beneficial if this role had the capability to exclude keys and values that match the default for that object type, ensuring that only necessary definitions are provided back as the output of the role.

The output of the role would then just be the what the developer supply back for dispatch to use for creating that object. Then might change a few things about it by hand (Ex: organization) before submitting to source before dispatch uses it.

This tool can help customers who manually deployed objects in the GUI transition to using the dispatch role. It could allow them to export current configurations easily and parse objects in a loop to generate configurations for their deployed items in AAP.

This idea of a role might be better suited for this collection instead:
https://github.com/redhat-cop/aap_configuration_extended/

Describe alternatives you've considered
None come to mind outside of what we are doing by hand via going to the API explorer and grabbing the configuration and manually look at the page to identify which values match the default and can't be dropped out of the configuration that needs to be supplied to dispatch.

Additional context
None to provide.

[MallocArray]

We are currently exploring YAML schemas in VSCode so users working on related files can get auto-complete and suggestions for valid values based. It may accomplish a similar thing

[djdanielsson]

yes this type of effort would only exist in aap_configuration_extended if it were created, if you come up with something that does this and would like to contribute it to aap_configuration_extended, we would be happy to consider it. But I do not believe any of the current maintainers will work on this, our time is very limited already (this is not our day job but something we maintain when we find time) and we have other improvements that we would like to focus on that would have a bigger impact to the majority of our user base. I will move this to the aap_configuration_extended repo where it is a better fitting request.

[ivarmu]

Isn't this what the filetree_create role does?

[djdanielsson]

my understanding was they were looking for something to help them write their config but not take what is in their current config and write it which is what filetree_create does but maybe I misunderstood.

[tenletters10]

Thanks for the feedback and advice!

A few items to comment back on:

We are currently exploring YAML schemas in VSCode so users working on related files can get auto-complete and suggestions for valid values based. It may accomplish a similar thing

Very cool. Would love to use that with my users.

yes this type of effort would only exist in aap_configuration_extended if it were created, if you come up with something that does this and would like to contribute it to aap_configuration_extended, we would be happy to consider it. But I do not believe any of the current maintainers will work on this, our time is very limited already (this is not our day job but something we maintain when we find time) and we have other improvements that we would like to focus on that would have a bigger impact to the majority of our user base. I will move this to the aap_configuration_extended repo where it is a better fitting request.

Totally understand. I am currently working on getting my team the ability to contribute on code in public repos since the company I work on has heavy restrictions on where we can do it. Once I get that cleared we plan on working at adding this capability to the aap_configuration_extended collection.

Isn't this what the filetree_create role does?
AND
my understanding was they were looking for something to help them write their config but not take what is in their current config and write it which is what filetree_create does but maybe I misunderstood.

Actually we didn't notice filetree_create until you mentioned it. It is 95% there of exactly what we are looking for. Two gaps we have found:

1. It exports to files while we want it to export in an ansible.builtin.debug messge back so the user can easily grap it. We also perfer not to write out to some sort of file server.
2. We also want the ability to target an object by name and type and currently it only supports types and it gets all of them of that type

With that said once I can get the green light to let my team contribute to this pubically we can come back and add these capabilities to the filetree_create role that already exists.

For the time being we created a playbook that work around those two limitations to make it work, but filetree_create got us there a lot quicker for our "quick and dirty" approach for now.

Going to keep this open for now until we can make some headway on our end to add support to filetree_create to have a few more parameter options.