Currently one plugin cannot communicate with another plugin, unless it references the plugin directly.
I suggest creating a new mechanism for such communication, similar to the concept of intents in android. This will reduce the need to directly reference plugins, for example we will be able to remove direct dependency between foreman_rh_cloud and Katello.
Would be interesting to hear other thoughts about it.
Why is referencing the plugin directly an issue?
I would like to avoid managing cross-plugin dependencies.
I think having a clear dependency tree is much clearer and allows more flexibility with deployments.
For example if we decide to split the plugins into different servers/containers - this will work as long as the plugins are standalone, but will not work if we have references between them.
I still have the same question as @MariaAga. The foreman_rh_cloud plugin requires functionality present in Katello. That feels fairly direct. Can you provide a more concrete example of what you mean?
Since the system is running right now, we can say that there is no acute need for a proper communication interface. So this whole suggestion is more of an improvement rather than fixing a blocker.
Having said that, I still think that the core should expose a proper abstract interface for data requests. Currently we already have a couple of places where this is implemented internally as a registry, but I think we can do better with properly defining an interface for this.
Once defined, it will define clear boundaries between plugins and core: the core would be responsible for transporting the requests, where the plugins will be responsible for getting the data.
Decoupling rh_cloud from Katello seems like a correct thing to do. As rh_cloud developer, I will not need to worry about the implementation details of how to get a certificate associated with an organization. If I think about it, I don’t really care even if Katello is the plugin that provides me the certificate, it could be any other plugin too.
Essentially it’s about formalizing the public facing interface of the plugin.
Another benefit that I can think of, is the tasks framework: currently the tasks process has to load all the rails app, because it cannot track which code dependencies the task will need. If we have a formal interface, we will be able to identify the dependency on call, and get the information into the process without actually loading the information retrieval code into task’s process.
Now let’s talk about extending the rh_cloud plugin for more cloud services. Currently I have to develop that feature as part of rh_cloud plugin. This implies linking the lifecycle of both parts of the plugin. While I can’t say that it’s wrong, I don’t think we have to have such a limitation. Ideally I would split the communication part into a common dependency, and have a plugin per each cloud service. Again, it’s not a must, but having an option to request communication services across plugins would be a much cleaner solution.
As the last reason, I can put the separate process per-plugin idea - while by itself it’s a wild one, I think in the long run creating more independence in the plugins world would be a good thing. The crazy idea is to put each plugin in a separate process/container and then having the core orchestrating them.
Hopefully my thought process is a bit more clear now.