Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-1525

FailureExecutor : Is it going to be maintained/used?

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Major
    • Resolution: Not A Problem
    • Affects Version/s: 0.8.0
    • Fix Version/s: 1.0.0
    • Component/s: tests
    • Labels:
      None

      Description

      Related to BIGTOP-1524 .

      Its important to carefully maintain and test it - its a great feature . Is anyone actually planning on using it or maintaining it ? Im mildly concerned about maintaining it -

      • i dont see any plans to continue working on it?
      • Should we put it in a branch possibly?
      • Or does someone have a plan for building it out ?

      If so lets get some more JIRAs for it, and add a vagrant recipe that auto-tests it, and so on.

      Dawson Choong Konstantin Boudnik Roman Shaposhnik might have feedback as you guys were on the original comment thread.

        Issue Links

          Activity

          Hide
          cos Konstantin Boudnik added a comment -
          • I don't know how to address the first and third questions: do you care to explain in more details?
          • Same for the second: why it needs to be moved to the branch as it's already in the master? What's the reasoning behind it?

          As for the vagrant recipe: the feature in question is a part of the test framework. The way to test it is two-fold:

          • have unit tests for it (check)
          • have failure injection tests (check)
            • add then as a part of our standard CI cycle
              The only missing piece I see is the last one, but after all our CI is still in the wood-works, so I don't see a problem with it. Could you please elaborate on how vagrant will play a role in running the integration failure tests?
          Show
          cos Konstantin Boudnik added a comment - I don't know how to address the first and third questions: do you care to explain in more details? Same for the second: why it needs to be moved to the branch as it's already in the master? What's the reasoning behind it? As for the vagrant recipe: the feature in question is a part of the test framework . The way to test it is two-fold: have unit tests for it (check) have failure injection tests (check) add then as a part of our standard CI cycle The only missing piece I see is the last one, but after all our CI is still in the wood-works, so I don't see a problem with it. Could you please elaborate on how vagrant will play a role in running the integration failure tests?
          Hide
          jayunit100 jay vyas added a comment -

          I agree that theoretically we could test the feature.
          And we could maintain it and so on.....

          But as happened with stuff like the hive tests, a great feature can bit rot
          If nobody cares to use it. Robots can't always verify everything.....

          right now there doesn't seem to be anybody actively trying to use it, or test it.

          ...vagrant is just an example of how a feature (like hbase) might be maintained and tested. Our users tend to be the ones to find bugs and patch them. Users also jump in to make easily tested vagrant or ci infra .

          Every feature needs to have some users who use it and find some way to test it.

          I'm just curious if we have users for this feature? If not it might just bit rot.

          Do you use it or know anyone that is interested in using it?

          I'm willing to help maintain it if so, but just want to confirm that the feature is important to people......

          I'm not yet using it myself although it's interesting...

          Show
          jayunit100 jay vyas added a comment - I agree that theoretically we could test the feature. And we could maintain it and so on..... But as happened with stuff like the hive tests, a great feature can bit rot If nobody cares to use it. Robots can't always verify everything..... right now there doesn't seem to be anybody actively trying to use it, or test it. ...vagrant is just an example of how a feature (like hbase) might be maintained and tested. Our users tend to be the ones to find bugs and patch them. Users also jump in to make easily tested vagrant or ci infra . Every feature needs to have some users who use it and find some way to test it. I'm just curious if we have users for this feature? If not it might just bit rot. Do you use it or know anyone that is interested in using it? I'm willing to help maintain it if so, but just want to confirm that the feature is important to people...... I'm not yet using it myself although it's interesting...
          Hide
          jayunit100 jay vyas added a comment -

          By the way am attaching a patch ironies in about 5 hrs.
          Hope your around for a quick review if your awake

          Show
          jayunit100 jay vyas added a comment - By the way am attaching a patch ironies in about 5 hrs. Hope your around for a quick review if your awake
          Hide
          cos Konstantin Boudnik added a comment -

          I agree that theoretically we could test the feature

          I don't think it is theoretical at this point: as a feature of the test framework it's getting unit-tested each time we build iTest. Hive tests aren't a good example for a number of reasons:

          1. Hive tests are very sensitive to data sets w/ combination to the Hive's version. As you correctly pointed out - no one is interested in Hive (and rightfully so, IMO)
          2. a feature of the test framework isn't the same as a test for a component of the stack. Former can be tested without a complex integration environment, e.g. a fully set cluster

          Every feature needs to have some users who use it and find some way to test it.
          I'm just curious if we have users for this feature? If not it might just bit rot.
          Do you use it or know anyone that is interested in using it?

          Yes there are users and demand for this: we are using it for multi-active namenode testing internally at WANdisco. And that's why we have contributed the feature: it can be easily used for ZK-based HA testing.

          Show
          cos Konstantin Boudnik added a comment - I agree that theoretically we could test the feature I don't think it is theoretical at this point: as a feature of the test framework it's getting unit-tested each time we build iTest. Hive tests aren't a good example for a number of reasons: Hive tests are very sensitive to data sets w/ combination to the Hive's version. As you correctly pointed out - no one is interested in Hive (and rightfully so, IMO) a feature of the test framework isn't the same as a test for a component of the stack. Former can be tested without a complex integration environment, e.g. a fully set cluster Every feature needs to have some users who use it and find some way to test it. I'm just curious if we have users for this feature? If not it might just bit rot. Do you use it or know anyone that is interested in using it? Yes there are users and demand for this: we are using it for multi-active namenode testing internally at WANdisco. And that's why we have contributed the feature: it can be easily used for ZK-based HA testing.
          Hide
          jayunit100 jay vyas added a comment -

          here we go, attached a quick patch which ensures that smoke-tests can no run w/ current iitest source , no JAR required. This will fix so all our docker and so on recipes are again working properly.

          quick review when you get a chance , thanks!

          Show
          jayunit100 jay vyas added a comment - here we go, attached a quick patch which ensures that smoke-tests can no run w/ current iitest source , no JAR required. This will fix so all our docker and so on recipes are again working properly. quick review when you get a chance , thanks!
          Hide
          cos Konstantin Boudnik added a comment -

          jay vyas, the patch belongs to BIGTOP-1524. Could you please move it there? Also, it has been already reviewed by me on that same JIRA.

          Show
          cos Konstantin Boudnik added a comment - jay vyas , the patch belongs to BIGTOP-1524 . Could you please move it there? Also, it has been already reviewed by me on that same JIRA.
          Hide
          jayunit100 jay vyas added a comment - - edited

          Konstantin Boudnik AWESOME to hear that you guys are using it ! Its quite relevant to us at red hat as well for our HCFS related work.... So we will also try it out as well. I just got impression it was a one off patch, and as commiter of it, i felt responsibility to make sure that i wasnt commiting something that nobody was using next time ill clarify it before hand.

          on to BIGTOP-1528 !

          Show
          jayunit100 jay vyas added a comment - - edited Konstantin Boudnik AWESOME to hear that you guys are using it ! Its quite relevant to us at red hat as well for our HCFS related work.... So we will also try it out as well. I just got impression it was a one off patch, and as commiter of it, i felt responsibility to make sure that i wasnt commiting something that nobody was using next time ill clarify it before hand. on to BIGTOP-1528 !
          Hide
          cos Konstantin Boudnik added a comment -

          Resolved incorrectly.

          Show
          cos Konstantin Boudnik added a comment - Resolved incorrectly.

            People

            • Assignee:
              Unassigned
              Reporter:
              jayunit100 jay vyas
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development