Skip to content
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

Implement a verification API #847

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from

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