Skip to content

Conversation

@adamruzicka
Copy link
Contributor

@adamruzicka adamruzicka commented Aug 12, 2021

TODOs:

Copy link
Member

@ezr-ondrej ezr-ondrej left a 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 :(

@adamruzicka
Copy link
Contributor Author

We need to work with subscription manager generated UUID instead of hostname

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?

@ezr-ondrej
Copy link
Member

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.

Sounds like exactly what we will need.

in case of pull it will make the job available under all of them

you mean to publish under the topics of the hostname AND uuid? sounds interesting, but probably better safe than sorry

@adamruzicka
Copy link
Contributor Author

you mean to publish under the topics of the hostname AND uuid?

Probably not publish on mqtt using both, but through the api the job should be obtainable with a cert containing either of those

@ezr-ondrej
Copy link
Member

Copy link
Member

@ezr-ondrej ezr-ondrej left a 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
Copy link
Contributor Author

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?

Copy link
Member

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 ?

Copy link
Member

@ezr-ondrej ezr-ondrej left a 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]
Copy link
Member

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?

Suggested change
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]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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'
Copy link
Member

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? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adamruzicka
Copy link
Contributor Author

Removed the cancellation for now, will open another PR once this goes in

@ezr-ondrej
Copy link
Member

Thanks @adamruzicka ! 👍

@adamruzicka adamruzicka deleted the mqtt branch October 21, 2021 10:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants