On 13 Jun 2016, at 14:33, Lucas Ponce wrote:
I am not sure if there have been some progress on this topic.
Lucas is right. We had a lot of discussions and many pros and cons
so that we have to now take a direction and move on.
We should go with one single gem - even with the danger that
other groups may veto its use inside of ManageIQ until we have
fixed the issue they are seeing.
If we were to split the gem into two the only sensible way from
my point of view would be metrics and other.
This would on one side allow us to make 'random' changes to the
'other' part, but also require duplication of the code (or some clever
build magic) for everything that is in the base client and deals with
connection handling etc.
Such a split would also not solve the issue that the 'metrics' part
needs to deal with hawkular-metrics version 0.8 servers and
hawkular-metrics version 0.15+.
Splitting to have 2 versions of the metrics gem for each api-version
is not an option either as consumers like ManageIQ may very well
need to simultaneously talk to different instances of
Hawkular-metrics that run different api-versions.
With respect of the valid question about changes being vetoed:
- breaking (Ruby) api changes (especially in the metrics area)
must not happen in the same major version of the gem
- adding of new api methods is still possible
- we need to be transparent what we do in the changelog
- I expect that other groups also have tests, that are run when
we upgrade the gem version in MiQ, so that the pull-request
checks show breakage
- If s* hits the fan, we need to be quick to react.
So going forward:
- 1 gem
- metrics-client reads on connect the /status endpoint and
remembers the hawkular-metrics rest-api version
- Endpoints for calls to metrics need to switch according to the
- For inventory we do not need to support the old rest-api
once the new one is available in hawkular-services