-
Notifications
You must be signed in to change notification settings - Fork 220
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
base: develop
Are you sure you want to change the base?
Conversation
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']) |
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.
Depends on theforeman/foreman#9423
|
||
# 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]) } |
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.
templates has a template_url
setting while registration uses the global foreman_url
setting.
def verify | ||
{ | ||
reverse_proxy: verify_reverse_proxy, | ||
} | ||
end |
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.
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?
How do you see this being different than if we were to implement a status API which is a common endpoint? |
I started with this because it was hard to verify if 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. |
The goal of this is to have an end-to-end verification of compatibility or provide concrete pointers to what failed.