As I started to work on this I realized that while providing binary tarballs for each HBase profile is fine, this does not solve the maven artifact issue.
Are we OK with publishing a single phoenix-client maven artifact (for the oldest HBase), or do we want to publish a separate one for each HBase version ? I looked at publishing multiple client versions, but none of them are particularly easy or attractive. The best I could come up with is adding a separate maven module for (each version x embedded) (i.e 6 for 4.x, 8 for master), and activating them according to hbase.profile. This would also mean that we need to add the hbase version to the artifact id. i.e.: phoenix-client-hbase-2.1 Once we publish separate binaries for the HBase profiles, we can undo the change that excludes compat-module from phoenix-server, and shade it in again for the binary assemblies. In this case we'd also have to do something about the phoenix-server maven artifacts. Either they get the same treatment as phoenix-client, or we simply skip publishing them. I personally do not see anyone getting phoenix-server.jar from maven. The easiest version is * publish the oldest profile phoenix-client to maven * do not publish phoenix-server to maven * add compat-module to phoenix-server for the binary artifact regards Istvan On Fri, Jan 8, 2021 at 6:56 AM Istvan Toth <[email protected]> wrote: > On the release binaries: > > The current solution (which the default profile change has broken) was > based on Lars's idea at > > https://issues.apache.org/jira/browse/PHOENIX-5902?focusedCommentId=17125122&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17125122 > However, I agree that providing separate assemblies for each HBase profile > is better for our users, as they won't have to rebuild Phoenix to take > advantage of any new features, and to get the general improvements in > later HBase releases. > I have opened https://issues.apache.org/jira/browse/PHOENIX-6307 to track > this. > > On the 5.1 release: > > Yes, I do want to release 5.1 shortly. In fact $dayjob desperately needs > it ASAP. > I have a few older PRs waiting for review that fell between the cracks, > but as soon as those are merged, I want to cut the first RC. > It would be nice to have 4.16 and 5.1 as close as possible, and > PHOENIX-6211 seems to be ready, so I hope to include it in 5.1 too. > I will start an official 5.1 release thread and volunteer to be the > release manager soon. (unless you want to take that up too, Xinyi). > > > > On Fri, Jan 8, 2021 at 1:08 AM Xinyi Yan <[email protected]> wrote: > >> If we can modify the dev/create-release scripts and make them work for the >> 4.16 release with this hbase.profile option, it would make our life much >> easier to release multiple HBase profiles from the single branch in the >> future too(the master branch will have a release shortly right?). Geoffrey >> and Istvan, what do you think? >> >> Thanks, >> Xinyi >> >> On Thu, Jan 7, 2021 at 11:28 AM Geoffrey Jacoby <[email protected]> >> wrote: >> >> > Thanks for bringing up the default branch issue, Istvan, I've been >> meaning >> > to start a conversation about it on this list. >> > >> > As part of PHOENIX-5435, I changed the default 4.x HBase release to 1.5 >> and >> > the default 5.x HBase to 2.3 because the WAL annotation feature >> introduced >> > by 5435 only works with HBase 1.5+ or 2.3+. (It depends on a coproc hook >> > introduced in HBASE-22623). That means that all tests of that feature >> must >> > no-op when run against an earlier HBase, which means that it would >> never be >> > tested in our CI pipelines if the default was 1.3 or 2.1. >> > >> > This has come up quite a few times recently. In particular, the new >> > indexing framework runs in a degraded state against HBase 2.1 and 2.2 >> > (still better than the old indexing framework though!), because we lack >> > support in 2.1 for Filters on raw scans and can't use the "max lookback >> > age" feature with HBase 2.1 or 2.2, which keeps major compactions from >> > messing with index rebuilds. That's why lots of indexing tests no-op or >> > have to make different assertions when run against 2.1 or 2.2, so we >> only >> > properly test the indexing framework if CI and local developer >> > tests run against HBase 2.3 or up. >> > >> > As for the release, don't we usually release separate binaries that are >> > suitable for all the HBase versions we support? Back before we had a >> > unified 4.x branch, I believe we used to release from 3 different >> > 4.x-HBase-* branches each time. I've been assuming that part of the >> release >> > process would be generating binaries for 4.x-HBase-1.3, 4.x-HBase-1.4, >> > 4.x-HBase-1.5, and 4.x-HBase-1.6 (if that was different from 1.5). >> > >> > Geoffrey >> > >> > On Thu, Jan 7, 2021 at 11:19 AM Istvan Toth <[email protected]> wrote: >> > >> > > Two more issues came to my mind: >> > > >> > > In PHOENIX-5435 the default profile was changed to HBase 1.5.0 >> > > This causes two conflicts: >> > > - Our documentation says that the default profile is the lowest >> > supported, >> > > which is no longer true >> > > - Unless we change our binary release process, the published maven >> > > artifacts and binaries will also be built with HBase 1.5, thus they >> will >> > be >> > > incompatible with Hbase 1.3 and 1.4 >> > > >> > > This should be addressed before release. >> > > One possible solution: >> > > * Add an "oldest" hbase.profile option which always chooses the oldest >> > > supported version >> > > * Update the release scripts to specify this profile >> > > * Update the docs. >> > > >> > > I have also adopted the hbase release scripts to Phoenix, they are >> > present >> > > in dev/create-release in the master branch, but >> > > should be able to perform 4.16 release as well. I have used this for >> the >> > > phoenix-thirdparty, omid, and tephra releases, but no live phoenix >> > releases >> > > have been done with them yet, obviously. >> > > >> > > regards >> > > Istvan >> > > >> > > On Thu, Jan 7, 2021 at 8:19 AM Istvan Toth <[email protected]> wrote: >> > > >> > > > Hi! >> > > > >> > > > A question of process: Should we backport fixes to the 4.16 branch >> at >> > our >> > > > discretion, or is backporting those handled by the release manager >> > > (Xinyi) ? >> > > > >> > > > On Thu, Jan 7, 2021 at 5:42 AM Istvan Toth <[email protected]> >> wrote: >> > > > >> > > >> Hi! >> > > >> >> > > >> Thanks for everyone's effort on fixing the flakey tests. >> > > >> However, our ASF Jenkins runs are still very unstable, and I am >> afraid >> > > >> that the single clean 4.x run was down more to luck than to fixing >> the >> > > >> underlying problem. >> > > >> While I do not consider this a blocker, fixing this would make the >> > pre- >> > > >> and post commit tests far more useful, and let us start with a >> clean >> > > slate >> > > >> for the next release. >> > > >> I have created https://issues.apache.org/jira/browse/PHOENIX-6288 >> to >> > > >> track the generic cluster setup issue, but my attempts to fix >> this, or >> > > at >> > > >> least figure out the root cause have been unsuccessful so far. >> > > >> >> > > >> I ask for your help in fixing this issue. I have added some >> > inconclusive >> > > >> analysis to the ticket, and the full failsafe output directory is >> > > >> downloadable as artifacts from the failed multibranch runs (stored >> > for a >> > > >> few days), which should hold the answer to this riddle. >> > > >> >> > > >> regards, >> > > >> Istvan >> > > >> >> > > >> On Thu, Jan 7, 2021 at 4:58 AM Xinyi Yan <[email protected]> >> wrote: >> > > >> >> > > >>> Hi, >> > > >>> >> > > >>> We finally have a stable 4.x branch build after many flapper test >> > > fixing >> > > >>> contributions from the community. I'm going to fork a new >> > branch(4.16) >> > > >>> from >> > > >>> the current 4.x branch for the 4.16 release. As a cutoff, I will >> not >> > > >>> include any new features other than PHOENIX-6211 and bug fix. >> Please >> > > let >> > > >>> me >> > > >>> know if you have any questions or concerns. >> > > >>> >> > > >>> Thanks, >> > > >>> Xinyi >> > > >>> >> > > >>> On Wed, Dec 23, 2020 at 6:07 AM Viraj Jasani <[email protected]> >> > > wrote: >> > > >>> >> > > >>> > An update on test stability: >> > > >>> > >> > > >>> > As per recent 4.x build results, we are left with very few >> flappers >> > > and >> > > >>> > specifically >> > > >>> > with HBase profile 1.6, I can see recent 7 build (multibranch + >> PR >> > > >>> > precommit results) >> > > >>> > results without any test failure. >> > > >>> > >> > > >>> > >> > > >>> > On Tue, Dec 15, 2020 at 5:52 AM Xinyi Yan <[email protected]> >> > > wrote: >> > > >>> > >> > > >>> > > Yes, we are currently working on fixing the 4.x branch test >> > > flappers >> > > >>> > while >> > > >>> > > waiting for the PHOENIX-5435. After that, I will try to have >> an >> > RC >> > > >>> ASAP. >> > > >>> > > >> > > >>> > > On Sun, Dec 13, 2020 at 3:29 PM Ankit Singhal < >> > > >>> [email protected]> >> > > >>> > > wrote: >> > > >>> > > >> > > >>> > > > I see that both the blockers listed here PHOENIX-5712 and >> > > >>> PHOENIX-6241 >> > > >>> > > > have been resolved(Thanks to Xinyi), and also as per the >> JIRA >> > > query >> > > >>> > there >> > > >>> > > > is no Jira marked as a blocker for 4.16 except the one >> related >> > to >> > > >>> > > > documentation >> > > >>> > > > for "splittable catalog table". >> > > >>> > > > >> > > >>> > > > Xinyi, so are we good to start the release process now? >> > > >>> > > > >> > > >>> > > > On Wed, Dec 2, 2020 at 9:32 PM Xinyi Yan < >> [email protected]> >> > > >>> wrote: >> > > >>> > > > >> > > >>> > > > > Thanks for replying and providing suggestions. I looked at >> > the >> > > >>> wrong >> > > >>> > > > result >> > > >>> > > > > Jira list that Daniel provided and did some local testing, >> > and >> > > >>> here >> > > >>> > is >> > > >>> > > > the >> > > >>> > > > > result: >> > > >>> > > > > [resolved] PHOENIX-4116, PHOENIX-4419, and PHOENIX-4642: >> > cannot >> > > >>> > > reproduce >> > > >>> > > > > it. >> > > >>> > > > > [More information is required] PHOENIX-4504 cannot >> reproduce >> > it >> > > >>> but >> > > >>> > > > someone >> > > >>> > > > > claimed that he had a similar issue. >> > > >>> > > > > [unusual query] PHOENIX-4540 and PHOENIX-6217 >> > > >>> > > > > >> > > >>> > > > > Based on my finding, I think it's better to have more >> > frequent >> > > >>> > > > housekeeping >> > > >>> > > > > and resolve unreproducible bugs especially since many of >> them >> > > are >> > > >>> > > > > considering out of date (phoenix-4.11 or even >> phoenix-4.6). >> > > >>> Since I >> > > >>> > > still >> > > >>> > > > > need time to work on the blocker Jira(PHOENIX-5712, >> > > >>> PHOENIX-6241) and >> > > >>> > > fix >> > > >>> > > > > test flappers, if you want to fix "unusual query" bugs, >> feel >> > > >>> free to >> > > >>> > do >> > > >>> > > > so. >> > > >>> > > > > >> > > >>> > > > > >> > > >>> > > > > Sincerely, >> > > >>> > > > > Xinyi >> > > >>> > > > > >> > > >>> > > > > On Wed, Dec 2, 2020 at 12:41 AM Ankit Singhal < >> > > [email protected]> >> > > >>> > > wrote: >> > > >>> > > > > >> > > >>> > > > > > Thanks Daniel and appreciate the effort you put in >> getting >> > > the >> > > >>> list >> > > >>> > > > ready >> > > >>> > > > > > for bugs producing wrong results >> > > >>> > > > > > but none of them seems to be a blocker to me for 4.16 as >> > they >> > > >>> are >> > > >>> > not >> > > >>> > > > the >> > > >>> > > > > > regression and doesn't break the general functionality >> > > >>> > > > > > except for specific features, RVC/desc as Chenglei also >> > > >>> pointed out >> > > >>> > > > > (though >> > > >>> > > > > > I'll defer the assessment to RM "Xinyi"). >> > > >>> > > > > > Probably these can be a part of 4.16.1 or we can do >> 4.17.0 >> > > soon >> > > >>> > maybe >> > > >>> > > > > after >> > > >>> > > > > > a few weeks/month? >> > > >>> > > > > > >> > > >>> > > > > > Considering that we have already fixed 137 bugs and done >> > 85+ >> > > >>> > > > > > improvements/features in 4.16, >> > > >>> > > > > > it will not be a good idea to deprive the user from such >> > > fixes. >> > > >>> > > > > > It's been a year since our last 4.15 release, having no >> > > release >> > > >>> > > brings >> > > >>> > > > > more >> > > >>> > > > > > questions on the project >> > > >>> > > > > > rather than the bugs which affect a certain % of >> > > feature/users, >> > > >>> > would >> > > >>> > > > the >> > > >>> > > > > > release notes >> > > >>> > > > > > explaining the stability of certain features set the >> right >> > > >>> > > expectation >> > > >>> > > > > for >> > > >>> > > > > > those users who rely on these features to wait for a >> future >> > > >>> > release? >> > > >>> > > > > > >> > > >>> > > > > > Regards, >> > > >>> > > > > > Ankit Singhal >> > > >>> > > > > > >> > > >>> > > > > > On Tue, Dec 1, 2020 at 8:21 PM [email protected] < >> > > >>> > > > [email protected]> >> > > >>> > > > > > wrote: >> > > >>> > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > In my opinion, we should keep releases light and >> > frequent, >> > > >>> and >> > > >>> > for >> > > >>> > > > > some >> > > >>> > > > > > > unusual query bugs like RVC and DESC >> > > >>> > > > > > > we could delay fix to next release . I think we should >> > > >>> release >> > > >>> > > 4.16.0 >> > > >>> > > > > and >> > > >>> > > > > > > 5.1.0 as quickly as possible. In China, many users >> > > >>> > > > > > > in HBase&Phoenix User Group thought that Phoenix was >> > dead >> > > >>> > because >> > > >>> > > > our >> > > >>> > > > > > too >> > > >>> > > > > > > long interval release and stopped using >> > > >>> > > > > > > Phoenix. >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > >> > > >>> > > > > > > At 2020-12-02 08:45:46, "Chinmay Kulkarni" < >> > > >>> > > > [email protected] >> > > >>> > > > > > >> > > >>> > > > > > > wrote: >> > > >>> > > > > > > >I agree. These are all major bugs and we should aim >> at >> > > >>> solving >> > > >>> > > them >> > > >>> > > > > > after >> > > >>> > > > > > > >checking that they are still issues. I am +1 on 5833 >> > and I >> > > >>> think >> > > >>> > > > 5484 >> > > >>> > > > > > > would >> > > >>> > > > > > > >be a great addition to 4.16 as well. We should aim at >> > > >>> resolving >> > > >>> > > high >> > > >>> > > > > > > >priority bugs like this in every release. >> > > >>> > > > > > > > >> > > >>> > > > > > > >Sometimes we let these bugs slip without a resolution >> > > >>> before a >> > > >>> > > > > release, >> > > >>> > > > > > > >citing that these are "known issues" or "not >> regressions >> > > >>> from >> > > >>> > the >> > > >>> > > > last >> > > >>> > > > > > > >release". In some cases this may be fine since we >> want >> > to >> > > >>> keep >> > > >>> > > > > releases >> > > >>> > > > > > > >light and frequent, but perhaps we can track such >> issues >> > > >>> and aim >> > > >>> > > at >> > > >>> > > > > > > >reducing the number of bugs by x% in each release? >> This >> > > will >> > > >>> > also >> > > >>> > > > keep >> > > >>> > > > > > old >> > > >>> > > > > > > >Jiras alive since we will potentially periodically >> > review >> > > >>> them. >> > > >>> > > > > > > > >> > > >>> > > > > > > > >> > > >>> > > > > > > >On Tue, Dec 1, 2020 at 4:01 PM Geoffrey Jacoby < >> > > >>> > > [email protected]> >> > > >>> > > > > > > wrote: >> > > >>> > > > > > > > >> > > >>> > > > > > > >> I've got PHOENIX-5435 in review right now, and >> would >> > > like >> > > >>> to >> > > >>> > get >> > > >>> > > > it >> > > >>> > > > > in >> > > >>> > > > > > > 4.16 >> > > >>> > > > > > > >> / 5.1. >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> It's allowing the annotation of Phoenix metadata >> into >> > > >>> HBase >> > > >>> > WALs >> > > >>> > > > as >> > > >>> > > > > a >> > > >>> > > > > > > >> pre-req for the Phoenix Change Detection Capture >> > > framework >> > > >>> > > > > > > (PHOENIX-5442). >> > > >>> > > > > > > >> Since it has both client/server logic, and adds a >> > field >> > > to >> > > >>> > > > > > > System.Catalog, >> > > >>> > > > > > > >> it can't go in a patch release. >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> Depending on timing, I'd _like_ to get >> PHOENIX-6227, >> > > >>> which is >> > > >>> > > the >> > > >>> > > > > last >> > > >>> > > > > > > part >> > > >>> > > > > > > >> of CDC that will go into core Phoenix, into 4.16, >> but >> > > >>> since >> > > >>> > that >> > > >>> > > > > _can_ >> > > >>> > > > > > > go >> > > >>> > > > > > > >> in a patch release and I haven't started it yet, if >> > the >> > > >>> > release >> > > >>> > > > gets >> > > >>> > > > > > cut >> > > >>> > > > > > > >> before it's ready, no big deal. (The rest of CDC >> will >> > go >> > > >>> into >> > > >>> > > > > > > >> phoenix-connectors for a future release of that >> > > project.) >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> As for the correctness problems that Daniel points >> > out, >> > > I >> > > >>> > think >> > > >>> > > we >> > > >>> > > > > > > should >> > > >>> > > > > > > >> fix the ones that were detected with a recent >> version >> > > >>> (4.14 or >> > > >>> > > > > 4.15?), >> > > >>> > > > > > > and >> > > >>> > > > > > > >> test to see which of the older ones can still be >> > > >>> reproduced. >> > > >>> > > Once >> > > >>> > > > we >> > > >>> > > > > > > know >> > > >>> > > > > > > >> which bugs are real and which are just historical, >> we >> > > can >> > > >>> > better >> > > >>> > > > > judge >> > > >>> > > > > > > >> scope. And hopefully close a bunch of obsolete >> bugs. >> > > >>> (Thanks, >> > > >>> > > > > Daniel, >> > > >>> > > > > > > for >> > > >>> > > > > > > >> collecting that list!) >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> Geoffrey >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> On Tue, Dec 1, 2020 at 1:33 PM Daniel Wong >> > > >>> > > > > > > >> <[email protected]> wrote: >> > > >>> > > > > > > >> >> > > >>> > > > > > > >> > Hi, I wanted to bring up wrong results in Phoenix >> > and >> > > >>> some >> > > >>> > > JIRAs >> > > >>> > > > > > > around >> > > >>> > > > > > > >> > them that I think we should fix as the wrong >> result >> > > >>> lessens >> > > >>> > > the >> > > >>> > > > > end >> > > >>> > > > > > > >> user's >> > > >>> > > > > > > >> > trust in Phoenix. Releasing a new version >> without >> > > >>> > addressing >> > > >>> > > > > these >> > > >>> > > > > > > in a >> > > >>> > > > > > > >> > minor release hurts our visibility in that these >> > > >>> critical >> > > >>> > > issues >> > > >>> > > > > are >> > > >>> > > > > > > not >> > > >>> > > > > > > >> > addressed. >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > Jira's that I'm involved with for example: I've >> > > already >> > > >>> > given >> > > >>> > > a >> > > >>> > > > > > patch >> > > >>> > > > > > > >> > several months ago for 5833 and there is a >> chance it >> > > >>> may fix >> > > >>> > > > 5484. >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-5833 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-5484 >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > In addition, inspecting apache JIRA i see several >> > > other >> > > >>> > wrong >> > > >>> > > > > result >> > > >>> > > > > > > >> JIRAs >> > > >>> > > > > > > >> > from the community. Some of these certainly are >> > > >>> probably >> > > >>> > old >> > > >>> > > > > issues >> > > >>> > > > > > > or >> > > >>> > > > > > > >> > incorrect understanding but some of these are >> opened >> > > by >> > > >>> our >> > > >>> > > own >> > > >>> > > > > dev >> > > >>> > > > > > > >> > community and are likely real problems. >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-6217 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-5571 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-4642 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-4540 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-4504 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-4419 >> > > >>> > > > > > > >> > >> > https://issues.apache.org/jira/browse/PHOENIX-4116 >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > What is our stance on this type of issue? Are we >> > > going >> > > >>> to >> > > >>> > say >> > > >>> > > > > these >> > > >>> > > > > > > were >> > > >>> > > > > > > >> > issues prior to 4.15 and not address them? >> Should >> > we >> > > >>> have >> > > >>> > > > > > > requirements >> > > >>> > > > > > > >> for >> > > >>> > > > > > > >> > our releases to fix wrong results? >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > Daniel Wong >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > On Mon, Nov 30, 2020 at 7:30 PM Xinyi Yan < >> > > >>> > > [email protected]> >> > > >>> > > > > > > wrote: >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > > Hi all, >> > > >>> > > > > > > >> > > >> > > >>> > > > > > > >> > > It's time to discuss the Phoenix 4.16 release. >> > After >> > > >>> many >> > > >>> > > > > people's >> > > >>> > > > > > > >> > > contributions on the bug fixes, new features, >> and >> > > >>> other >> > > >>> > > works >> > > >>> > > > in >> > > >>> > > > > > the >> > > >>> > > > > > > >> past >> > > >>> > > > > > > >> > > few months, we are kind of close to the point >> to >> > > have >> > > >>> a RC >> > > >>> > > > > (still >> > > >>> > > > > > > need >> > > >>> > > > > > > >> to >> > > >>> > > > > > > >> > > fix test flappers). Please let me know if you >> > think >> > > >>> any >> > > >>> > JIRA >> > > >>> > > > > must >> > > >>> > > > > > be >> > > >>> > > > > > > >> part >> > > >>> > > > > > > >> > > of the Phoenix 4.16 release other than major >> > blocker >> > > >>> > > > > PHOENIX-5712. >> > > >>> > > > > > > >> > > >> > > >>> > > > > > > >> > > If no surprise comes up, I will not wait for >> any >> > new >> > > >>> major >> > > >>> > > > > > features >> > > >>> > > > > > > and >> > > >>> > > > > > > >> > > focus on the RC as soon as possible. >> > > >>> > > > > > > >> > > >> > > >>> > > > > > > >> > > Sincerely, >> > > >>> > > > > > > >> > > Xinyi >> > > >>> > > > > > > >> > > >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> > -- >> > > >>> > > > > > > >> > Daniel Wong >> > > >>> > > > > > > >> > Salesforce >> > > >>> > > > > > > >> > Mobile: 628.217.1808 >> > > >>> > > > > > > >> > >> > > >>> > > > > > > >> >> > > >>> > > > > > > > >> > > >>> > > > > > > > >> > > >>> > > > > > > >-- >> > > >>> > > > > > > >Chinmay Kulkarni >> > > >>> > > > > > > >> > > >>> > > > > > >> > > >>> > > > > >> > > >>> > > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > >> >> > > >> >> > > >> -- >> > > >> *István Tóth* | Staff Software Engineer >> > > >> [email protected] <https://www.cloudera.com> >> > > >> [image: Cloudera] <https://www.cloudera.com/> >> > > >> [image: Cloudera on Twitter] <https://twitter.com/cloudera> >> [image: >> > > >> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> > > >> Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > >> <https://www.cloudera.com/> >> > > >> ------------------------------ >> > > >> >> > > > >> > > >> > >> > > > -- > *István Tóth* | Staff Software Engineer > [email protected] <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> > <https://www.cloudera.com/> > ------------------------------ > -- *István Tóth* | Staff Software Engineer [email protected] <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
