Operation callbacks fix #207
Conversation
If the operation is called with the operation name given by symbol, instead of the string. It's performed correctly on the agent, but the failure callback is called.
For ruby 2.2 travis uses a version of bundler that is not resolving dependencies correctly. Adding command to update bundler's version to make the build not fail due to dependencies wrongly resolved.
|
Do we really need to fix that with v2.8.1? Can't they use v2.9 ? |
Maybe the server (hawkular-services) is too new for v2.8. If we are going to support old versions we should consider on specifying a hawkular-services version to test against instead of using the latest version. |
|
@josejulio Well... I would say yes. But by doing that, some VCR cassettes in MiQ will need to be re-recorded. I want to avoid that since that BZ is happening in CFME 5.8.0, which is based in MiQ "fine", which is only receiving bug-fixes. |
|
@israel-hdez " is echoed saying that hawkular-services was the one that failed to perform an operation." I think the agent inside h-services is set to immutable (as we are running in-container in Travis) and thus operations can indeed not be peformed. I think @josejulio had a fix for this some time ago? |
|
Supporting multiple minor versions and back-porting stuff may complicate the whole process, but sooner or later we have to probably do that anyway. @josejulio perhaps it make sense to run the live tests only for the master branch and PRs against master (?) lgtm, I'd merge it despite the travis red, if anyone doesn't object |
|
What versions of hawkular-services are we going to support with Live testing was working since v.2.8. If we aren't going to support latest (hawkular-services) version we should run the tests with the latest hawkular-services supported version by Having tests running on old cassettes (about 6 months ago) is almost as having no tests, but that's just my opinion :) |
I'm not sure what would be the problem on recording the tests again, we might need to support less stuff this way. |
@josejulio You resist to bring support, haha. But I understand you ;) I would have to sync with other people also using the gem, so that they also re-record their cassettes. I just want to avoid that hassle. Anyway, tonight my pillow suggested me a way to fix the BZ in MiQ/fine side. I can apply that fix and we can forget about this PR. However, MiQ/fine will still be a "user" of v2.8.0 and that forces us to bring support to that version if something else arises. |
I understand it can be a hassle. But think about it, If 2.8 is failing on live tests, its a hint that something may be wrong. |
|
@josejulio a short discussion about bumping the version happened in ManageIQ/manageiq-gems-pending#102. Even with semantic versioning the suggestion was to lock to a specific version, and that's the reason why I am keeping Well.... Too much discussion about support/not-support previous versions. So, I placed ManageIQ/manageiq#14851 to fix the BZ in MiQ side. We should agree on how to handle these kind of issues. If we are going to support previous versions, I can fix the specs as you @josejulio suggested in your last comment to have a green on 2.8.x branch. |
That would be awesome, thanks! |
|
I'll close this. It doesn't apply anymore, because MiQ fine was updated to use 3.0.1. |
Created branch 2.8.x on the repo from v2.8.0 tag. On top of that branch/tag, cherry-picked commit 49fc84a. I will need this released as v2.8.1.
This is required to fix BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1443005.
Note 1: v2.9.0 included that commit/fix, so there is no problem in that version.
Note 2: Travis is raising errors when testing on live servers. I don't know why that's happening 😞. In travis log, something is echoed saying that hawkular-services was the one that failed to perform an operation. So, may be the problem is somewhere else?