Skip to content

Conversation

@ekohl
Copy link
Member

@ekohl ekohl commented Sep 14, 2022

The goal of this is to have an end-to-end verification of compatibility or provide concrete pointers to what failed.

The goal of this is to have an end-to-end verification of compatibility
or provide concrete pointers to what failed.

status = JSON.parse(response.body)
unless status.key?('remote_ip')
message = if ::Gem::Dependency.new('', '>= 3.5.0').match?('', status['version'])
Copy link
Member Author

Choose a reason for hiding this comment

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


# Only needed for templates / registration
# TODO: make this more generic
return true unless ::Proxy::Plugins.instance.any? { |p| p[:state] == :running && ['templates', 'registration'].include?(p[:name]) }
Copy link
Member Author

Choose a reason for hiding this comment

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

templates has a template_url setting while registration uses the global foreman_url setting.

Comment on lines +11 to +15
def verify
{
reverse_proxy: verify_reverse_proxy,
}
end
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm thinking about the format. Perhaps it should have some global status and then a hash for modules.

{
  "global": {},
  "modules": {
    "templates": {
      "status": true,
      "reverse_proxy": true,
    },
    "registration": {
      "status": true,
    }
  }
}

Perhaps also a summary?

What if it doesn't? Should we use error codes? Human readable strings? both?

@ehelms
Copy link
Member

ehelms commented Sep 14, 2022

How do you see this being different than if we were to implement a status API which is a common endpoint?

@ekohl
Copy link
Member Author

ekohl commented Sep 14, 2022

I started with this because it was hard to verify if request.remote_ip inside Foreman was set correctly. That's how I came to /verify. Hadn't considered a status API.

I think a status API shouldn't reach out to external sources unless they're critical. Reaching out can be expensive.

That does make me think about more things. For example, if a plugin (or provider) has an external connection (think Puppet -> Puppetserver or isc_dhcp -> dhcpd) that should be verified. So this endpoint should be pluggable and the plugin API should provide some DSL to verify.

But this PR is the start of a discussion IMHO: what do we need to verify to say "this Smart Proxy works" and how can we provide hints if it doesn't.

We should also consider if this endpoint should be authenticated. Probably yes if it reaches out to external services. Otherwise it may be used for DoS attacks.

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