Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Create initial tower objects when we start the worker #14283
These objects will be used for dynamically creating things like job templates during playbook runs from automate.
Requires #14377 for storing the ansible side ids with the provider.
All, marked as WIP until you all sign off on where this kind of stuff belongs. I tested out the logic on an appliance so I really just need opinions on where this should live. (Of course if the logic is wrong, please tell me that too
@blomquisg from a provider side view, is this where this kind of thing belongs? I don't know what the responsibilities of the provider/manager typically are so I added it here just because we already had a subclass for embedded ansible for the provider class.
@Fryguy I'm not sure I would want to add the other seeding stuff here. Maybe something in the worker for that as it's more system/filesystem related?
@gmcculloug Is this about what you guys need to create the job templates for the service runs? The provider instance will be accessible to you guys when you need this info I hope?
@Fryguy From a timing perspective, yes, it will be called from around there, but I'm not sold on where to put the code.
I felt like it would be a bit strange for the automate methods to call out to a worker class or instance to get the default values so I put everything on the provider.
Like I said, I think the rest of the plugin import stuff should belong with the worker, but I'm a bit split on this part.
Okay, spoke with @Fryguy and we're taking a bit of a new approach.
We're going to store these in custom attributes related to the provider. That way we don't have to rely on our modeling and potentially conflict with the refresher by adding fields (like a system flag or something) to the AR instances and we also don't have to constantly connect to the provider and match names to find things.
The custom attribute setter/getters will live in a concern and they will be used by the EmbeddedAnsibleWorker (for setting) and automate will use the getters when they need to create stuff referencing these objects.
We also won't need a migration, so that's good
…bleWorker::Runner This creates a concern around creating and removing objects in the embedded ansible instance. In particular we remove all of the demo data that is initialized for us during setup and we create just the objects that we need and save the ids to the provider.
Without this we were we were getting "502 Bad Gateway" errors when trying to remove the demo data through API calls to the embedded ansible instance. This was because even though the setup playbook finished, the server would take just a bit longer to start to serve requests.
Specifically I am aware of this one: https://github.com/ManageIQ/manageiq/blob/master/app/models/service_template_ansible_playbook.rb#L94