Issue #15 #14
Issue #15 #14
Conversation
Signed-off-by: ashiven <nevisha@pm.me>
Signed-off-by: ashiven <nevisha@pm.me>
… script, implement worker connect and registration endpoints Signed-off-by: ashiven <nevisha@pm.me>
…can belong to multiple configs Signed-off-by: ashiven <nevisha@pm.me>
Signed-off-by: ashiven <nevisha@pm.me>
…amiko.exec_command) Signed-off-by: ashiven <nevisha@pm.me>
Signed-off-by: ashiven <nevisha@pm.me>
…ost keys when using Paramiko Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Signed-off-by: ashiven <nevisha@pm.me>
|
There is one linter error/warning that I don't know how to fix. It says that executing commands on a remote host via paramiko.exec_command is potentially unsafe, but I don't know how else to get the system info from the remote host. Also, paramiko.RejectPolicy may need to be reverted to paramiko.AutoAddPolicy because otherwise we would need to add each worker and its public key to the known SSH hosts manually. Even though paramiko.AutoAddPolicy is marked as unsafe by CodeQL. |
Signed-off-by: ashiven <nevisha@pm.me>
Signed-off-by: ClProsser <clemens.prosser@gmail.com>
There was a problem hiding this comment.
Good job @ashiven. Some minor changes, otherwise suggestions.
Having multiple configurations per worker looks confusing to me. You might want to change that, if you agree.
Edit: I changed my mind. See the comment in workers/models.py
If those endpoints are API endpoints, please add them to the openapi.yaml.
Note that your branch has conflicts with the mainbranch. Please fix that.
embark/workers/urls.py
Outdated
| path('worker/scan/<int:configuration_id>/', views.config_worker_scan, name='embark-worker-scan'), | ||
| path('worker/connect/<int:configuration_id>/<int:worker_id>/', views.connect_worker, name='embark-worker-connect'), | ||
| path('worker/registered/<int:configuration_id>/', views.registered_workers, name='embark-worker-registered'), |
There was a problem hiding this comment.
If these are API endpoints, I'd add a prefix such as api to make it implicitly clear. E.g. api/worker/scan/<int:configuration_id>/
There was a problem hiding this comment.
I think it would make development easier for now to leave these endpoints as they are and maybe change them into api endpoints later on. Otherwise we would have to provide a valid api key whenever we want to test these endpoints or use them in developing the orchestrator and create documentation that might be subject to change
Signed-off-by: ashiven <nevisha@pm.me>
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
This PR introduces a new feature
What is the current behavior? (You can also link to an open issue here)
Currently it is not possible to scan for and register the workers belonging to a config or to connect to a specific worker
https://github.com/orgs/amosproj/projects/79/views/2?pane=issue&itemId=108209914&issue=amosproj%7Camos2025ss01-embark-orchestration-framework%7C15
What is the new behavior (if this is a feature change)? If possible add a screenshot.
It is now possible to scan for and register the workers in the IP range of a given config and then to connect to specific workers in order to gather information about their HW and OS type and version
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No