I would be fine with adding this only to 2.6 and 3.0. I only proposed the other branches because of the perceived low impact of the change. This change is not important enough to make a sooner release necessary.
If the change is accepted could I please get a review for the PR? https://github.com/apache/hbase/pull/4885 On Wed, Jan 4, 2023 at 3:17 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > +1 on releasing 2.6.0 sooner. > > And I think it is time to EOL 2.4.x after we release 2.6.0? > > Bryan Beaudreault <bbeaudrea...@hubspot.com.invalid> 于2023年1月3日周二 21:02写道： > > > > I think development is done on TLS. We are just waiting on requested > > testing. Andor was working on that, but I believe he had some stuff come > up > > at his work. > > > > I also want to get backups in place, but there is 1 backwards > compatibility > > issue to work through. Hoping to have that squared away soon. > > > > On Sat, Dec 31, 2022 at 9:32 PM Andrew Purtell <andrew.purt...@gmail.com > > > > wrote: > > > > > +1 > > > > > > If this is needed soon in a release we could start on 2.6.0? > > > > > > (How is TLS RPC coming along? - that would be the big ticket item.) > > > > > > > On Dec 23, 2022, at 7:06 AM, 张铎 <palomino...@gmail.com> wrote: > > > > > > > > This is a behavior change, it makes non admin users can clone > snapshot. > > > > > > > > For me I do not think we should include changes like this in a patch > > > > release, unless it is considered as a critical bug which must be > > > > fixed. > > > > > > > > Thanks. > > > > > > > > Szabolcs Bukros <szabo...@cloudera.com.invalid> 于2022年11月30日周三 > 00:06写道： > > > >> > > > >> This should not break any existing use case so I see no reason to > not > > > add > > > >> this to branch-2.5 and > > > >> branch-2.4. > > > >> > > > >>> On Thu, Nov 24, 2022 at 3:03 AM 张铎(Duo Zhang) < > palomino...@gmail.com> > > > wrote: > > > >>> > > > >>> I'm OK with this change. > > > >>> > > > >>> But maybe we still need to determine which branches we can apply > this > > > >>> change to? Is it OK to include this change for branch-2.5 and > > > >>> branch-2.4? > > > >>> > > > >>> Tak Lon (Stephen) Wu <tak...@apache.org> 于2022年11月22日周二 06:31写道： > > > >>>> > > > >>>> FYI the PR is https://github.com/apache/hbase/pull/4885 > > > <https://github.com/apache/hbase/pull/4885> > > > and > > > >>>> https://issues.apache.org/jira/browse/HBASE-27493 > > > <https://issues.apache.org/jira/browse/HBASE-27493> > > > . > > > >>>> > > > >>>> the proposal seems to be, should we allow cloning snapshot to any > > > >>>> namespace if they're not the global admin. > > > >>>> > > > >>>> logically, it should be fine because they're the admin for the > > > >>>> namespace, and should be able to do whatever within that > namespace. > > > >>>> > > > >>>> Thanks, > > > >>>> Stephen > > > >>>> > > > >>>> > > > >>>> On Mon, Nov 21, 2022 at 11:38 AM Szabolcs Bukros > > > >>>> <szabo...@cloudera.com.invalid> wrote: > > > >>>>> > > > >>>>> Hi Everyone, > > > >>>>> > > > >>>>> Creating a snapshot requires table admin permissions. But > cloning it > > > >>>>> requires global admin permissions unless the user owns the > snapshot > > > and > > > >>>>> wants to recreate the original table the snapshot was based on > using > > > >>> the > > > >>>>> same table name. This puts unnecessary load on the few users > having > > > >>> global > > > >>>>> admin permissions on the cluster. I would like to relax this > rule a > > > >>> bit and > > > >>>>> allow the owner of the snapshot to clone it into any namespace > where > > > >>> they > > > >>>>> have admin permissions regardless of the table name used. > > > >>>>> > > > >>>>> Please let me know what you think about this proposal. And if you > > > find > > > >>> it > > > >>>>> acceptable which branch do you think this could land on. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Szabolcs Bukros > > > >>> > > > > -- *Szabolcs Bukros* | Staff Engineer e. szabo...@cloudera.com 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/> ------------------------------
