CarlosJuncher03 commented on issue #7991: URL: https://github.com/apache/hop/issues/7991#issuecomment-5327914918
I apologize if I didn't explain the idea well before. Also, sometimes the translation makes the explanation a little difficult. In my previous comment, I was trying to separate the proposal into two different situations. The first is the simplest and relates only to the integration between Hop GUI and an existing Hop Server. Today, for example, I might have a project that uses environment variables and also files or other dependencies located within the project's own structure. For this project to run correctly on a Hop Server, the server needs to start execution using the correct project and environment. If the Hop Server infrastructure is already prepared and already has access to the project, environments, and other dependencies, it wouldn't be necessary for Hop GUI to send all these files again. The idea, in this first scenario, would be simply to allow the Hop GUI, when requesting remote execution, to also inform the Hop Server of something equivalent to: project = X environment = Y Thus, the Hop Server would use the project and environment already available on that server to execute the pipeline or workflow with all the necessary context. Currently, I can prepare this context manually on the server. What I would like is for this selection to be part of the remote execution initiated by the Hop GUI itself. The second situation is different and would be an additional functionality related to Kubernetes. In this case, it would be interesting if a Run Configuration could use a pre-configured integration with Kubernetes to create an ephemeral pod for that execution. The flow would be approximately: The Hop GUI requests the execution of a pipeline or workflow. The configuration informs the image to be used and the project/environment of the execution. Kubernetes creates a temporary pod. The pipeline or workflow is executed within this pod. The Hop GUI monitors the execution, including status and logs. Upon completion, the pod is terminated/removed. The infrastructure would remain responsible for providing the necessary resources to the pod, such as project, environment files, plugins, drivers, secrets, PVCs, or other resources. The goal of this second scenario would be to allow me, during development, to validate a pipeline with real or representative data in an environment similar to production, but still initiate and monitor this execution directly through the Hop interface. Therefore, these are really two proposals at different levels: first, improve the existing remote execution between Hop GUI and Hop Server, allowing the project and environment to be specified; then, eventually allow one of -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
