[DISCUSS] Making upgrade to a new minor release a manual step

[Samarth Jain <sa...@apache.org>]

(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

Re: [DISCUSS] Making upgrade to a new minor release a manual step

[Josh Elser <el...@apache.org>]

+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
>