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 <gjac...@apache.org>
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 <st...@apache.org> 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 <st...@apache.org> 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 <st...@cloudera.com>
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 <yanxi...@apache.org>
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 <vjas...@apache.org
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 <yanxi...@apache.org
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 <
ankitsingha...@gmail.com>
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 <
yanxi...@apache.org>
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 <
an...@apache.org>
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 cheng...@apache.org <
cheng...@apache.org>
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" <
chinmayskulka...@gmail.com
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 <
gjac...@apache.org>
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
<daniel.w...@salesforce.com.invalid> 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 <
yanxi...@apache.org>
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
st...@cloudera.com <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/>
------------------------------
