Exposing capabilities in the smart proxy

[ekohl]

@lzap

First, as I already said in the WIP POC PR, I don’t like mixed case for features (lower case) and capabilities (upper case). I would like to standardize on one or another, preferably lower case. These are all symbols, not constants and in Ruby world these has always been lower case.

You are talking about the Ruby DSL, not the API? I could see them as lower case in the DSL but in the REST API I think uppercasing them is cleaner since there they are just strings instead of symbols.

@lzap

Second, as we can see it was not good idea to return array as root element in JSON because it is not extendable. Your proposal is extendable, but it assumes the result is always hash of features. When we make decision to transform the endpoint into something more generic, it will be confusing output. Therefore I suggest to create wrapper - a root hash with key “features”.

If we make it authenticated, let’s add more info about proxy and rename it to something more generic like /status . It could return basic information about proxy - version, uptime (of smart-proxy process not OS) and one thing I was always wanting to show in foreman UI - current settings (the yaml tree).

I could see how that would make sense. We can bikeshed over status vs info vs something else. I have also thought about exposing which provider is used for debugging purposes.