+1 to the idea. Automatic upgrades on your behalf with knowledge can be
scary.
But, let me pose a hypothetical: say I upgrade from Phoenix X to Phoenix
Y. I have some application that using Phoenix X and I want to make sure
that before I finish my upgrade to Phoenix Y that things are "OK". It
seems like I have no ability to actually verify that things are working
before updating the catalog (and other metadata). I'm thinking about
something like HDFS's Namenode upgrade/rollback process for those who
have done that.
Additionally, the ability for admins/vendors to set
phoenix.autoupgrade.enabled=true and restore the old functionality is
great. We just need to make sure the change in functionality is doc'ed.
That's good.
I think it would be good to put some more thought into how we can verify
an upgrade before "finalizing it" (or create the ability to rollback an
upgrade), but I think that is a follow-on topic.
Samarth Jain wrote:
(Resending email with a proper subject)
Hello Phoenix folks,
The purpose of this email is two fold:
1) to introduce folks about the new optional upgrade process and,
2) to get a consensus on what should the default behavior of the process
be.
As you may already know, when a new minor release is rolled out, in order
to support new features Phoenix needs to update its internal metadata. This
update is done as part of the upgrade process that is automatically kicked
off when a Phoenix client for a new minor release connects to the HBase
cluster.
To provide more control on when this upgrade should be run, we wrote a new
feature which makes this upgrade optionally a manual step (see
https://issues.apache.org/jira/browse/PHOENIX-3174 for details). The
upgrade behavior is controlled by a client side config named
phoenix.autoupgrade.enabled. If the config is set to false, then Phoenix
won't kick off the upgrade process automatically. When ready to upgrade,
users can kick off the upgrade process by calling EXECUTE UPGRADE sql
command.
Keep in mind that till the upgrade is run, Phoenix won't let you execute
any other SQL commands using the new minor release client. Clients running
older versions of Phoenix though will continue to work as before.
I propose that we should by default have the config
phoenix.autoupgrade.enabled set to false. Providing users more control and
making the upgrade process an explicit manual step is the right thing to
do, IMHO.
Interested to know what do you all think.
Thanks,
Samarth