Bigtop
  1. Bigtop
  2. BIGTOP-1373

Add a mechanism of obtaining source for components from SCM

    Details

    • Type: Improvement Improvement
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.8.0
    • Fix Version/s: None
    • Component/s: build
    • Labels:
      None

      Description

      This was brought up here (https://issues.apache.org/jira/browse/BIGTOP-1363) as a much wanted feature for our build system so we can build against branches. I have two approaches to doing this that I'll be posting up Patch files for and seeing which approach everyone likes better.

      1. BIGTOP-1373.patch
        2 kB
        Julien Eid
      2. BIGTOP-1373-extrafile.patch
        16 kB
        Julien Eid
      3. BIGTOP-1373-noextrafile.patch
        3 kB
        Julien Eid

        Issue Links

          Activity

          Hide
          Mark Grover added a comment -

          I will, in a few days.

          On Tue, Dec 30, 2014 at 12:45 AM, Konstantin Boudnik (JIRA) <jira@apache.org

          Show
          Mark Grover added a comment - I will, in a few days. On Tue, Dec 30, 2014 at 12:45 AM, Konstantin Boudnik (JIRA) <jira@apache.org
          Hide
          Konstantin Boudnik added a comment -

          Not really sure. Is any one of original champions for this can take a look?

          Show
          Konstantin Boudnik added a comment - Not really sure. Is any one of original champions for this can take a look?
          Hide
          Konstantin Boudnik added a comment -

          Not really sure. Is any one of original champions for this can take a look?

          Show
          Konstantin Boudnik added a comment - Not really sure. Is any one of original champions for this can take a look?
          Hide
          Roman Shaposhnik added a comment -

          Konstantin Boudnik it seems that the gradle side of the patch is all stubbed out. Is there actually anything to apply here?

          Show
          Roman Shaposhnik added a comment - Konstantin Boudnik it seems that the gradle side of the patch is all stubbed out. Is there actually anything to apply here?
          Hide
          Konstantin Boudnik added a comment -

          Anything?

          Show
          Konstantin Boudnik added a comment - Anything?
          Konstantin Boudnik made changes -
          Link This issue is related to BIGTOP-1527 [ BIGTOP-1527 ]
          Hide
          Konstantin Boudnik added a comment -

          So, what's the consensus here? The patch was provided a long time ago and it should either go in or else.

          One other comment on the patch - let's add a description of the functionality into README.md

          Show
          Konstantin Boudnik added a comment - So, what's the consensus here? The patch was provided a long time ago and it should either go in or else. One other comment on the patch - let's add a description of the functionality into README.md
          Hide
          Konstantin Boudnik added a comment -

          I think the argument is about a non-issue. There's no limitations on how many stacks one can produce using some variance of the definition files (aka bigtop.mk). All one needs to do to produce a stack then is to create a tailored definitions and run build with that particular file, instead of the standard bigtop.mk. Will the custom file override bits and pieces of the base one, or will be a separate full stack definition - is up to the particular implementation. It doesn't matter for this discussion IMO. The only functionality we need to support, as Roman Shaposhnik pointed out, is to be able to download bits from more protocol URLs than just http and ftp, supported right now.

          Are we all talking about the same thing, btw?

          Show
          Konstantin Boudnik added a comment - I think the argument is about a non-issue. There's no limitations on how many stacks one can produce using some variance of the definition files (aka bigtop.mk). All one needs to do to produce a stack then is to create a tailored definitions and run build with that particular file, instead of the standard bigtop.mk. Will the custom file override bits and pieces of the base one, or will be a separate full stack definition - is up to the particular implementation. It doesn't matter for this discussion IMO. The only functionality we need to support, as Roman Shaposhnik pointed out, is to be able to download bits from more protocol URLs than just http and ftp, supported right now. Are we all talking about the same thing, btw?
          Konstantin Boudnik made changes -
          Component/s build [ 12322208 ]
          Konstantin Boudnik made changes -
          Affects Version/s 0.8.0 [ 12324841 ]
          Hide
          Mark Grover added a comment - - edited

          Thanks, Roman.

          Here are my thoughts:

          we already agree that Makefile-based builds are getting removed in 0.9.0. No point in massaging that functionality.

          That'd be fine by me but since we have the change made to Makefile as well, I can't see it hurting if we commit that.

          in our current Gradle-based infrastructure everything is keyed-off of the URL and hence is trivial to add custom logic to handle different types of protocols (even imaginary ones).

          The reason I have favored a separate .mk from day 1 is because of my personal desire to make Apache Bigtop a better integration platform for the ecosystem. I think given that we currently bundle released apache components prevents us from catching Integration issues in other projects before they are released.

          Here is what I am thinking and maybe there are other ways of achieving the same and if you have alternatives, I'd love to hear.
          I personally would like to see this change being done in a backwards compatible manner which means nothing in the way we build or test our Bigtop stack should change. If we were to override existing bigtop.mk with new protocols, then we can either do the regular Bigtop build that downloads the existing releases of Apache projects and packages/tests them, OR we can do a Bigtop build of projects pulled down from the trunk of their github repos. But, more importantly, to switch between the two, one would have to make code changes to bigtop.mk. I think it would be great to have the ability to build both the status quo builds and the component trunk based builds using the exact same code in the repo. I can think of 2 ways we can possibly do that:
          1. We can introduce new properties in the existing bigtop.mk file but that's more than just an extra _SITE variable because we would also need to update the PKG_VERSION etc. based on what the trunk is pointing to.
          2. We can introduce a separately bigtop.mk file and add functionality in our Makefile/Gradle scripts to override which .mk gets used. That way we could have a jenkins job that would build every night off of component trunks and nothing in the existing workflow changes for building off of released apache artifacts.

          So, I preferred #2, which is what I think this JIRA intends to do. Does that make sense?

          Show
          Mark Grover added a comment - - edited Thanks, Roman. Here are my thoughts: we already agree that Makefile-based builds are getting removed in 0.9.0. No point in massaging that functionality. That'd be fine by me but since we have the change made to Makefile as well, I can't see it hurting if we commit that. in our current Gradle-based infrastructure everything is keyed-off of the URL and hence is trivial to add custom logic to handle different types of protocols (even imaginary ones). The reason I have favored a separate .mk from day 1 is because of my personal desire to make Apache Bigtop a better integration platform for the ecosystem. I think given that we currently bundle released apache components prevents us from catching Integration issues in other projects before they are released. Here is what I am thinking and maybe there are other ways of achieving the same and if you have alternatives, I'd love to hear. I personally would like to see this change being done in a backwards compatible manner which means nothing in the way we build or test our Bigtop stack should change. If we were to override existing bigtop.mk with new protocols, then we can either do the regular Bigtop build that downloads the existing releases of Apache projects and packages/tests them, OR we can do a Bigtop build of projects pulled down from the trunk of their github repos. But, more importantly, to switch between the two, one would have to make code changes to bigtop.mk. I think it would be great to have the ability to build both the status quo builds and the component trunk based builds using the exact same code in the repo. I can think of 2 ways we can possibly do that: 1. We can introduce new properties in the existing bigtop.mk file but that's more than just an extra _SITE variable because we would also need to update the PKG_VERSION etc. based on what the trunk is pointing to. 2. We can introduce a separately bigtop.mk file and add functionality in our Makefile/Gradle scripts to override which .mk gets used. That way we could have a jenkins job that would build every night off of component trunks and nothing in the existing workflow changes for building off of released apache artifacts. So, I preferred #2, which is what I think this JIRA intends to do. Does that make sense?
          Hide
          Roman Shaposhnik added a comment -

          Sorry for coming to the party rather late, but here's what I'm confused about:

          1. we already agree that Makefile-based builds are getting removed in 0.9.0. No point in massaging that functionality.
          2. in our current Gradle-based infrastructure everything is keyed-off of the URL and hence is trivial to add custom logic to handle different types of protocols (even imaginary ones).

          Based on the two points above, shouldn't the point of this JIRA be about making sure that whatever URL you put in bigtop.mk as a _SITE/_ARCHIVE that the protocol gets handled correctly? Today we only handle http:// and file:// but there shouldn't be any reason not to add things like git:// as first class citizens.

          Am I missing something?

          Show
          Roman Shaposhnik added a comment - Sorry for coming to the party rather late, but here's what I'm confused about: we already agree that Makefile-based builds are getting removed in 0.9.0. No point in massaging that functionality. in our current Gradle-based infrastructure everything is keyed-off of the URL and hence is trivial to add custom logic to handle different types of protocols (even imaginary ones). Based on the two points above, shouldn't the point of this JIRA be about making sure that whatever URL you put in bigtop.mk as a _SITE/ _ARCHIVE that the protocol gets handled correctly? Today we only handle http:// and file:// but there shouldn't be any reason not to add things like git:// as first class citizens. Am I missing something?
          Hide
          Konstantin Boudnik added a comment -

          Guo Ruijing, the download and build parts are already decoupled. The latter clearly depends on the former. However, it is done by different tasks of the build system. Your 2nd point is actually incorrect: current logic is using ASF releases as default, but there's a way to switch to a BOM that uses github (or something else) if desired. I fill like I am getting confused more and more. If someone see a flaw in my comments - please point out.

          Show
          Konstantin Boudnik added a comment - Guo Ruijing , the download and build parts are already decoupled. The latter clearly depends on the former. However, it is done by different tasks of the build system. Your 2nd point is actually incorrect: current logic is using ASF releases as default, but there's a way to switch to a BOM that uses github (or something else) if desired. I fill like I am getting confused more and more. If someone see a flaw in my comments - please point out.
          Hide
          Guo Ruijing added a comment -

          download.sh try to resolve to 2 issues:

          1) decouple source code download/checkout and build
          2) existing download functionality is to download source code from github. download.sh try to check out from any SCM or download source code.

          Show
          Guo Ruijing added a comment - download.sh try to resolve to 2 issues: 1) decouple source code download/checkout and build 2) existing download functionality is to download source code from github. download.sh try to check out from any SCM or download source code.
          Hide
          Konstantin Boudnik added a comment -

          Wait, but download functionality is already implemented in both gradle and make. And the source URLs are expressed in bigtop.mk BOM. What problem download.sh with hardcoded URLs will be solving?

          Show
          Konstantin Boudnik added a comment - Wait, but download functionality is already implemented in both gradle and make. And the source URLs are expressed in bigtop.mk BOM. What problem download.sh with hardcoded URLs will be solving?
          Hide
          Guo Ruijing added a comment -

          1. gradle/makefile can call download.sh $component

          2. vendor can change download.sh according to their needs.

          Show
          Guo Ruijing added a comment - 1. gradle/makefile can call download.sh $component 2. vendor can change download.sh according to their needs.
          Hide
          Guo Ruijing added a comment -

          download.sh example:

          case $1 in
          hadoop)
          cd components; wget http://apache.osuosl.org/hadoop/common/hadoop-2.5.0/hadoop-2.5.0-src.tar.gz; tar xzvf hadoop-2.5.0-src.tar.gz
          ;;
          zookeeper)
          cd components/; git clone https://github.com/apache/zookeeper.git; cd zookeeper; git checkout -b branch-3.5
          ;;
          hbase)
          cd components/hbase; wget https://github.com/apache/hbase/archive/0.98.zip; unzip 0.98.zip
          ;;
          *)
          echo Componnet Not Found
          ;;
          esac

          Show
          Guo Ruijing added a comment - download.sh example: case $1 in hadoop) cd components; wget http://apache.osuosl.org/hadoop/common/hadoop-2.5.0/hadoop-2.5.0-src.tar.gz ; tar xzvf hadoop-2.5.0-src.tar.gz ;; zookeeper) cd components/; git clone https://github.com/apache/zookeeper.git ; cd zookeeper; git checkout -b branch-3.5 ;; hbase) cd components/hbase; wget https://github.com/apache/hbase/archive/0.98.zip ; unzip 0.98.zip ;; *) echo Componnet Not Found ;; esac
          Hide
          Konstantin Boudnik added a comment -

          where download.sh will be getting the source URL information?

          Show
          Konstantin Boudnik added a comment - where download.sh will be getting the source URL information?
          Hide
          Guo Ruijing added a comment -

          I'd like to propose to decouple SCM and bigtop build (makefile or gradle)

          1) more and more components come into bigop and some components may not be in github.

          2) more vendors can use bigtop as distribution reference (different vendor uses different SCM)

          Proposal detail:

          1. bigtop directory layout as:

          bigtop/components/
          bigtop/components/zookeeper/
          bigtop/components/hadoop/
          bigtop/components/hbase/
          bigtop/components/hive/

          2. makefile or gradle can directly build from the above directories

          3. download.sh will download source code from apache release or github or svn or git

          Show
          Guo Ruijing added a comment - I'd like to propose to decouple SCM and bigtop build (makefile or gradle) 1) more and more components come into bigop and some components may not be in github. 2) more vendors can use bigtop as distribution reference (different vendor uses different SCM) Proposal detail: 1. bigtop directory layout as: bigtop/components/ bigtop/components/zookeeper/ bigtop/components/hadoop/ bigtop/components/hbase/ bigtop/components/hive/ 2. makefile or gradle can directly build from the above directories 3. download.sh will download source code from apache release or github or svn or git
          Hide
          Mark Grover added a comment -

          Seems like we are all leaning towards the bigtop-github.mk patch. Julien, is there anything else that needs to be changed there or is this good to go?
          I noticed that it only had the github values for HBase, all other components had rather dummy values copied from bigtop.mk. It would be good to update them to be github based as well. Apart from that, it's looking good to me.

          Thanks again for working on this!

          Show
          Mark Grover added a comment - Seems like we are all leaning towards the bigtop-github.mk patch. Julien, is there anything else that needs to be changed there or is this good to go? I noticed that it only had the github values for HBase, all other components had rather dummy values copied from bigtop.mk. It would be good to update them to be github based as well. Apart from that, it's looking good to me. Thanks again for working on this!
          Hide
          Konstantin Boudnik added a comment -

          I think my comment wasn't too clearly expressed. I am not advocating for having in-line changes in the existing bigtop.mk. In fact I am all for the 'separation of concerns' approach. What I said is that we don't need to fully duplicate bigtop.mk => bigtop-github.mk and then forever make two set of changes we need to update a release version of a component.

          Instead a way more surgical and elegant way of doing things is to only put those components into bigtop-github.mk that one wants to pull off of github. During build defines from bigtop-github.mk will override bigtop.mk producing expected BOM. Did I expressed it better now?

          BTW, JIRA isn't a right way to gauge communal preferences, IMO.

          Show
          Konstantin Boudnik added a comment - I think my comment wasn't too clearly expressed. I am not advocating for having in-line changes in the existing bigtop.mk . In fact I am all for the 'separation of concerns' approach. What I said is that we don't need to fully duplicate bigtop.mk => bigtop-github.mk and then forever make two set of changes we need to update a release version of a component. Instead a way more surgical and elegant way of doing things is to only put those components into bigtop-github.mk that one wants to pull off of github. During build defines from bigtop-github.mk will override bigtop.mk producing expected BOM. Did I expressed it better now? BTW, JIRA isn't a right way to gauge communal preferences, IMO.
          Hide
          Sean Mackrory added a comment -

          I see that only a few components in the new bigtop-github.mk will be taken off github

          I believe the intention was to see which approach the community preferred before fully implementing that approach. Right? on that note, I agree with Mark's preference for the separate Makefile.

          Show
          Sean Mackrory added a comment - I see that only a few components in the new bigtop-github.mk will be taken off github I believe the intention was to see which approach the community preferred before fully implementing that approach. Right? on that note, I agree with Mark's preference for the separate Makefile.
          Hide
          Konstantin Boudnik added a comment -

          Ah, right - I see it now: missed on the first sight. Yup, looks legit.
          One improvement suggestions - might be done later: I see that only a few components in the new bigtop-github.mk will be taken off github. And the rest of the are still being downloaded from Apache site/mirrors. Hence and obvious improvement is to only keep github specific parts of the BOM in the new .mk file and simply use it to override definitions from the main bigtop.mk. Thus we'll avoid quite a big or unnecessary duplications and maintenance. What do you think?

          Show
          Konstantin Boudnik added a comment - Ah, right - I see it now: missed on the first sight. Yup, looks legit. One improvement suggestions - might be done later: I see that only a few components in the new bigtop-github.mk will be taken off github. And the rest of the are still being downloaded from Apache site/mirrors. Hence and obvious improvement is to only keep github specific parts of the BOM in the new .mk file and simply use it to override definitions from the main bigtop.mk. Thus we'll avoid quite a big or unnecessary duplications and maintenance. What do you think?
          Hide
          Mark Grover added a comment -

          No, I was just using that as an example. The patch implements both gradle and make changes so both are supported.

          Show
          Mark Grover added a comment - No, I was just using that as an example. The patch implements both gradle and make changes so both are supported.
          Hide
          Konstantin Boudnik added a comment -

          Does it mean that functionality isn't going to work in Gradle build?

          Show
          Konstantin Boudnik added a comment - Does it mean that functionality isn't going to work in Gradle build?
          Hide
          Mark Grover added a comment -

          Thanks Julien, I much prefer the separate make file. That way people who download Bigtop source and build a released version of, say HBase, can build it without making any code changes to the .mk file, while Bigtop jenkins, on the other hand, could hook on to HBase github and do a nightly build a different version of HBase, without any code changes as well.

          If we went with same Makefile, code changes will definitely be required across these 2 use-cases because the BASE_VERSION is shared with them.

          Your patch looks good to me, I will wait for a day or two for anyone to post their opinion and then go ahead and commit it.

          Thanks for doing this! This is super valuable to the Bigtop community and goes a long way in helping us find integration problems in the ecosystem sooner!

          Show
          Mark Grover added a comment - Thanks Julien, I much prefer the separate make file. That way people who download Bigtop source and build a released version of, say HBase, can build it without making any code changes to the .mk file, while Bigtop jenkins, on the other hand, could hook on to HBase github and do a nightly build a different version of HBase, without any code changes as well. If we went with same Makefile, code changes will definitely be required across these 2 use-cases because the BASE_VERSION is shared with them. Your patch looks good to me, I will wait for a day or two for anyone to post their opinion and then go ahead and commit it. Thanks for doing this! This is super valuable to the Bigtop community and goes a long way in helping us find integration problems in the ecosystem sooner!
          Julien Eid made changes -
          Attachment BIGTOP-1373-noextrafile.patch [ 12656939 ]
          Hide
          Julien Eid added a comment -

          This is the other method of implementing this patch where you modify bigtop.mk to download the source of the project from Github. Both of these patches (noextrafile and extrafile) both work, it is up to the communities preference on which method they like more.

          Show
          Julien Eid added a comment - This is the other method of implementing this patch where you modify bigtop.mk to download the source of the project from Github. Both of these patches (noextrafile and extrafile) both work, it is up to the communities preference on which method they like more.
          Julien Eid made changes -
          Attachment BIGTOP-1373-extrafile.patch [ 12656937 ]
          Hide
          Julien Eid added a comment -

          This is one method of implementing this feature request where you have an extra file called bigtop-github.mk that when you do make hbase-deb-git, it will include bigtop-github.mk instead of bigtop.mk

          Show
          Julien Eid added a comment - This is one method of implementing this feature request where you have an extra file called bigtop-github.mk that when you do make hbase-deb-git, it will include bigtop-github.mk instead of bigtop.mk
          Hide
          Konstantin Boudnik added a comment -

          I am not particularly worried about having something in ASF git that isn't mirrored to github. What I am saying that I don't want to be tighten up to github It's ok, I guess, to have it this way as the first pass, but let's think how we can advance it to the support of a more generic git backend. Makes sense?

          Also, I agree with mark - duplicating the whole set of entries in the BOM file looks too excessive. Can we devise a better way of doing this?

          Show
          Konstantin Boudnik added a comment - I am not particularly worried about having something in ASF git that isn't mirrored to github. What I am saying that I don't want to be tighten up to github It's ok, I guess, to have it this way as the first pass, but let's think how we can advance it to the support of a more generic git backend. Makes sense? Also, I agree with mark - duplicating the whole set of entries in the BOM file looks too excessive. Can we devise a better way of doing this?
          Hide
          Julien Eid added a comment -

          Konstantin Boudnik I am confused by what you mean by Apache git. Do you mean that there are projects repo's hosted on Apache git that are not mirrored to Github? From what I'm seeing, all components in Bigtop are mirrored onto Github from their Apache git or svn repo's like https://github.com/apache/hbase

          The reason why I use Github is their download commit as .zip feature which allowed me to quickly write this up and not make large changes to package.mk to handle actually doing git and svn checkouts. We simple wget the .zip and treat it like any other release of a project. This is really useful where if someone forks lets say HBase and applies a bunch of patches on top of a release and they want to try and build Bigtop using that fork, they can just specify the repo and branch they want to build and it will do it. The other useful use case is if we want to build against various branches in a projects repo for the future where we want to test builds against master and stuff like that. Since the projects repo is mirrored to Github, you can build against master or anything else easily.

          Do you know of a project that is not mirrored to Github or any other use case that this patch won't support?

          Show
          Julien Eid added a comment - Konstantin Boudnik I am confused by what you mean by Apache git. Do you mean that there are projects repo's hosted on Apache git that are not mirrored to Github? From what I'm seeing, all components in Bigtop are mirrored onto Github from their Apache git or svn repo's like https://github.com/apache/hbase The reason why I use Github is their download commit as .zip feature which allowed me to quickly write this up and not make large changes to package.mk to handle actually doing git and svn checkouts. We simple wget the .zip and treat it like any other release of a project. This is really useful where if someone forks lets say HBase and applies a bunch of patches on top of a release and they want to try and build Bigtop using that fork, they can just specify the repo and branch they want to build and it will do it. The other useful use case is if we want to build against various branches in a projects repo for the future where we want to test builds against master and stuff like that. Since the projects repo is mirrored to Github, you can build against master or anything else easily. Do you know of a project that is not mirrored to Github or any other use case that this patch won't support?
          Hide
          Konstantin Boudnik added a comment -

          As a small not: I think limiting this functionality to github won't fly. A lot of Apache projects are now using Apache git, and I think it is important to be able to use it.

          Show
          Konstantin Boudnik added a comment - As a small not: I think limiting this functionality to github won't fly. A lot of Apache projects are now using Apache git, and I think it is important to be able to use it.
          Hide
          Mark Grover added a comment -

          Thanks for this Julien!

          I took a look and here is what I think. I think the 'steady state' use case of this is going to be that bigtop trunk would support building a HBase package that was based off of a recent release of HBase (use case #1) but also building from an arbitrary branch of HBase from it's github repo (use case #2).

          Now, today, if someone has use case #1, they don't have to make any changes, they clone the bigtop repo and issue a command to build a package. I want to be able to do something similar for use case #2, so for that, if the user is happy with the github branch that Bigtop currently builds against, then all the user has to do is issue a simple command.

          So, what follows is we can't clobber the existing variables in bigtop.mk, right? I personally don't want users to switch between flags or change code to be able to build from a github branch instead of an hbase release. That kinds leaves us with just one option in my opinion, that's to introduce new commands like 'make hbase-github-rpm' in addition to the 'make hbase-rpm'. For that we will need a new set of properties that we would need to set for HBase.

          Again, we can't clobber existing properties, we have to introduce a completely additive set of new properties, which we need to set for every component. That new additive set can reside in bigtop.mk, but could also reside in another .mk file like bigtop-github.com. I think I have a slight preference to the latter i.e. using bigtop-github.mk. What do you think?

          Also, I think the patch is incomplete but i suppose that was intentional since you are just getting our thoughts

          Show
          Mark Grover added a comment - Thanks for this Julien! I took a look and here is what I think. I think the 'steady state' use case of this is going to be that bigtop trunk would support building a HBase package that was based off of a recent release of HBase (use case #1) but also building from an arbitrary branch of HBase from it's github repo (use case #2). Now, today, if someone has use case #1, they don't have to make any changes, they clone the bigtop repo and issue a command to build a package. I want to be able to do something similar for use case #2, so for that, if the user is happy with the github branch that Bigtop currently builds against, then all the user has to do is issue a simple command. So, what follows is we can't clobber the existing variables in bigtop.mk, right? I personally don't want users to switch between flags or change code to be able to build from a github branch instead of an hbase release. That kinds leaves us with just one option in my opinion, that's to introduce new commands like 'make hbase-github-rpm' in addition to the 'make hbase-rpm'. For that we will need a new set of properties that we would need to set for HBase. Again, we can't clobber existing properties, we have to introduce a completely additive set of new properties, which we need to set for every component. That new additive set can reside in bigtop.mk, but could also reside in another .mk file like bigtop-github.com. I think I have a slight preference to the latter i.e. using bigtop-github.mk. What do you think? Also, I think the patch is incomplete but i suppose that was intentional since you are just getting our thoughts
          Konstantin Boudnik made changes -
          Link This issue is duplicated by BIGTOP-1375 [ BIGTOP-1375 ]
          Konstantin Boudnik made changes -
          Link This issue supercedes BIGTOP-1375 [ BIGTOP-1375 ]
          Julien Eid made changes -
          Attachment BIGTOP-1373.patch [ 12655611 ]
          Hide
          Julien Eid added a comment -

          Added patch to JIRA. Also on Review Board.

          Show
          Julien Eid added a comment - Added patch to JIRA. Also on Review Board.
          Julien Eid made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Hide
          Julien Eid added a comment -

          Put up a review for one method of doing this here: https://reviews.apache.org/r/23457/

          Show
          Julien Eid added a comment - Put up a review for one method of doing this here: https://reviews.apache.org/r/23457/
          Hide
          Konstantin Boudnik added a comment -

          There is an unfinished effort earlier to do the same.
          If you think ticket takes over BIGTOP-848, let's close the latter.

          Show
          Konstantin Boudnik added a comment - There is an unfinished effort earlier to do the same. If you think ticket takes over BIGTOP-848 , let's close the latter.
          Konstantin Boudnik made changes -
          Field Original Value New Value
          Link This issue relates to BIGTOP-848 [ BIGTOP-848 ]
          Julien Eid created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Julien Eid
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development