Groundwork for pull provider#64
Conversation
ezr-ondrej
left a comment
There was a problem hiding this comment.
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.
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.
@ezr-ondrej What is the expected payload for job cancellation?
There was a problem hiding this comment.
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.
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.
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.
| 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.
Are we using it somewhere? 🤔
There was a problem hiding this comment.
|
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 <ezrik12@gmail.com>
Co-authored-by: Ondřej Ezr <ezrik12@gmail.com>
|
Thanks @adamruzicka ! 👍 |
TODOs: