-
Notifications
You must be signed in to change notification settings - Fork 26
Groundwork for pull provider #64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ezr-ondrej
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to work with subscription manager generated UUID instead of hostname, that's where the yggdrassil client listens for mqtt messages :(
Well, since foreman doesn't know what the proxy side needs, we'll need to send both and let the proxy pick. That means we'll need an extension point on Foreman's side where katello can inject the uuid into the job. Proxy will get a list of "names" and either will pick one depending on the mode, or in case of pull it will make the job available under all of them. How does that sound? |
Sounds like exactly what we will need.
you mean to publish under the topics of the hostname AND uuid? sounds interesting, but probably better safe than sorry |
Probably not publish on mqtt using both, but through the api the job should be obtainable with a cert containing either of those |
|
Actually the mqtt topic depends on cert CN: |
ezr-ondrej
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few more typos and we work if we introduce a hack to check for the uuid as well as for the hostname.
| # Otherwise we have to wait it out | ||
| if input[:with_mqtt] | ||
| cleanup | ||
| payload = {} # TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ezr-ondrej What is the expected payload for job cancellation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to be quite up to us, there is not much documentation on the topic in https://github.com/RedHatInsights/cloud-connector#data tho I'd need to check wether it won't always try to fech content, but probably not if we ommit it.
then I'd go with data message, directive cancel ?
ezr-ondrej
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cancel is not exactly working and will need to be pollished (partly because of my missinformation), could we split that to a separate PR? All the other bits are working as they should, so I'd merge that and continue with just the cancalation.
| # Client was notified or is already running, dealing with this situation | ||
| # is only supported if mqtt is available | ||
| # Otherwise we have to wait it out | ||
| mqtt_cancel if input[:with_mqtt] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about switching the order, just in case mqtt_cancel fails for some reason?
| mqtt_cancel if input[:with_mqtt] | |
| mqtt_cancel and cleanup if input[:with_mqtt] |
| module Proxy::RemoteExecution::Ssh | ||
| class Plugin < Proxy::Plugin | ||
| SSH_LOG_LEVELS = %w[debug info warn error fatal].freeze | ||
| MODES = %i[ssh async-ssh pull pull-mqtt] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| MODES = %i[ssh async-ssh pull pull-mqtt] | |
| MODES = %i[ssh async-ssh pull pull-mqtt].freeze |
| require 'smart_proxy_remote_execution_ssh/version' | ||
| require 'smart_proxy_remote_execution_ssh/plugin' | ||
| require 'smart_proxy_remote_execution_ssh/webrick_ext' | ||
| require 'sequel' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we using it somewhere? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Removed the cancellation for now, will open another PR once this goes in |
- now uses in-memory sqlite - each job is identified by its uuid - get /jobs returns a list of job uuids available for a given host - get /jobs/:job_uuid returns the job contents - post /jobs/:job_uuid/update lets client upload updates for a job
Co-authored-by: Ondřej Ezr <[email protected]>
Co-authored-by: Ondřej Ezr <[email protected]>
|
Thanks @adamruzicka ! 👍 |
TODOs: