You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sentry.apache.org by Alexander Kolbasov <ak...@cloudera.com> on 2017/04/05 02:17:13 UTC
Re: [DISCUSS] Merging Sentry HA branch with master
I would like to make a more concrete proposal and I am interested in opinion from Sentry PMC members on this.
I would propose the following approach for merging Sentry HA into Sentry master:
Cherry-pick any commits that happened since sentry-ha-redesign was forked, except a few described below
Exclude big refactoring commit (SENTRY-1205) and related commits (SENTRY-1436, SENTRY-1438, SENTRY-1406)
Rename master to a dev branch
Rename sentry-ha-redesign to master
What does community think about such approach?
- Alex
> On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <ak...@cloudera.com> wrote:
>
> Hello,
>
> I would like to start the discussion on merging sentry-ha-redesign branch with master.
>
> As of now most of the changes from master are merged into sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the code for sentry-provider-db and create sentry-service module) and associated issues. This refactoring is very hard to port, especially since there is very little information in the JIRA on why it was done and how it was done - was it merely moving files around or more then that. I would seriously consider not including this change in 1.8.
>
> So in regards to the merge we have several options:
>
> Attempt to merge master into sentry-ha-redesign, resolve any conflicts and later commit the merge to master. This will cause merge commit on master
> Finish work on sentry-ha-redesign, make sure that relevant commits are ported from master, and then making this a master branch and making current master a special branch left for reference purposes. This will likely leave SENTRY-1205 and related issues out.
> What does community think about this?
>
> - Alex
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Colm O hEigeartaigh <co...@apache.org>.
Have you tried to contact the author of the patch for SENTRY-1205 to get
their opinion? If there are major conflicts between the two branches then I
think your proposal is ok for 1.8, as the new feature should take
precedence over a refactoring effort.
However, in future, I think it is not a good idea to maintain a branch for
active development that diverges so far from master, as it inevitably leads
to this kind of conflict.
Colm.
On Wed, Apr 5, 2017 at 3:17 AM, Alexander Kolbasov <ak...@cloudera.com>
wrote:
> I would like to make a more concrete proposal and I am interested in
> opinion from Sentry PMC members on this.
>
> I would propose the following approach for merging Sentry HA into Sentry
> master:
>
> Cherry-pick any commits that happened since sentry-ha-redesign was forked,
> except a few described below
> Exclude big refactoring commit (SENTRY-1205) and related commits
> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> Rename master to a dev branch
> Rename sentry-ha-redesign to master
>
> What does community think about such approach?
>
> - Alex
>
>
> > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
> >
> > Hello,
> >
> > I would like to start the discussion on merging sentry-ha-redesign
> branch with master.
> >
> > As of now most of the changes from master are merged into
> sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the
> code for sentry-provider-db and create sentry-service module) and
> associated issues. This refactoring is very hard to port, especially since
> there is very little information in the JIRA on why it was done and how it
> was done - was it merely moving files around or more then that. I would
> seriously consider not including this change in 1.8.
> >
> > So in regards to the merge we have several options:
> >
> > Attempt to merge master into sentry-ha-redesign, resolve any conflicts
> and later commit the merge to master. This will cause merge commit on master
> > Finish work on sentry-ha-redesign, make sure that relevant commits are
> ported from master, and then making this a master branch and making current
> master a special branch left for reference purposes. This will likely leave
> SENTRY-1205 and related issues out.
> > What does community think about this?
> >
> > - Alex
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Alexander Kolbasov <ak...@cloudera.com>.
Sergio,
thank you for clarifying the Hive version story.
Do we have any explicit policy about compatibility with other components and Hive specifically? Do we need to support older versions of Hive or supporting the current released Hive 1.x version is sufficient?
At least it seems that we need to address
SENTRY-1323 Bump the hive version to 1.2.0
to move forward.
- Alex
> On Apr 19, 2017, at 8:34 AM, Sergio Pena <se...@cloudera.com> wrote:
>
> Pointing the branch to master sounds good.
>
> I just have one concern regarding the Hive dependency that Sentry HA needs.
> This new feature requires that the Hive version running with Sentry master
> has HMS notification logs enabled. Hive 1.1.0 (currently officially
> supported by Sentry 1.7) started this HMS notification feature but seems it
> is unstable. At least I found a bug on Hive 1.1.0 that it might make Sentry
> unusable with this version + others required fixes and improvements that
> exist only on Hive 2.x.
>
> This bug is fixed on Hive 1.2.0:
> HIVE-9501: DbNotificationListener doesn't include dbname in create
> database notification and does not include tablename in create table
> notification.
>
> To make things complicated, bumping Sentry to support Hive 1.2.0 is not an
> easy task due to the new authorization v2 hooks that are used in Hive. See
> the comments on the below SENTRY jira:
>
> SENTRY-1323: Bump the hive version to 1.2.0
>
> So, my question is what would happen with the Sentry 1.x compatibility if
> we do this switch from sentry-ha-redesign -> master?
>
> On Tue, Apr 18, 2017 at 3:45 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>> OK thanks, sounds good to me then. Let's try and do development work on
>> master from now on though...
>>
>> Colm.
>>
>> On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov <ak...@cloudera.com>
>> wrote:
>>
>>> FYI, I contacted Colin Ma who was working on the refactoring and he was
>> Ok
>>> with skipping this change for 1.8. That said, the refactoring was done
>> for
>>> a reason it we should get back to it post 1.8,
>>>
>>> - Alex
>>>
>>> On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
>>>
>>>> The proposal is good to me as well. Should we start a vote on this? Or
>> we
>>>> can just start to do it if no one is objecting?
>>>>
>>>> Best,
>>>> Hao
>>>>
>>>> On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <
>> vamsee@cloudera.com>
>>>> wrote:
>>>>
>>>>>>
>>>>>> Cherry-pick any commits that happened since sentry-ha-redesign was
>>>>> forked,
>>>>>> except a few described below
>>>>>> Exclude big refactoring commit (SENTRY-1205) and related commits
>>>>>> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
>>>>>> Rename master to a dev branch
>>>>>> Rename sentry-ha-redesign to master
>>>>>
>>>>>
>>>>> This sounds good to me. Generally having merge commits complicates
>> the
>>>> git
>>>>> history and might get tricky when we are debugging things. I would
>>> rather
>>>>> stick with the approach of cherry-picks to make the history clear.
>>>>>
>>>>> Thanks,
>>>>> Vamsee
>>>>>
>>>>> On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <
>> akolb@cloudera.com
>>>>
>>>>> wrote:
>>>>>
>>>>>> I would like to make a more concrete proposal and I am interested
>> in
>>>>>> opinion from Sentry PMC members on this.
>>>>>>
>>>>>> I would propose the following approach for merging Sentry HA into
>>>> Sentry
>>>>>> master:
>>>>>>
>>>>>> Cherry-pick any commits that happened since sentry-ha-redesign was
>>>>> forked,
>>>>>> except a few described below
>>>>>> Exclude big refactoring commit (SENTRY-1205) and related commits
>>>>>> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
>>>>>> Rename master to a dev branch
>>>>>> Rename sentry-ha-redesign to master
>>>>>>
>>>>>> What does community think about such approach?
>>>>>>
>>>>>> - Alex
>>>>>>
>>>>>>
>>>>>>> On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <
>>> akolb@cloudera.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would like to start the discussion on merging
>> sentry-ha-redesign
>>>>>> branch with master.
>>>>>>>
>>>>>>> As of now most of the changes from master are merged into
>>>>>> sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor
>>> the
>>>>>> code for sentry-provider-db and create sentry-service module) and
>>>>>> associated issues. This refactoring is very hard to port,
>> especially
>>>>> since
>>>>>> there is very little information in the JIRA on why it was done and
>>> how
>>>>> it
>>>>>> was done - was it merely moving files around or more then that. I
>>> would
>>>>>> seriously consider not including this change in 1.8.
>>>>>>>
>>>>>>> So in regards to the merge we have several options:
>>>>>>>
>>>>>>> Attempt to merge master into sentry-ha-redesign, resolve any
>>>> conflicts
>>>>>> and later commit the merge to master. This will cause merge commit
>> on
>>>>> master
>>>>>>> Finish work on sentry-ha-redesign, make sure that relevant
>> commits
>>>> are
>>>>>> ported from master, and then making this a master branch and making
>>>>> current
>>>>>> master a special branch left for reference purposes. This will
>> likely
>>>>> leave
>>>>>> SENTRY-1205 and related issues out.
>>>>>>> What does community think about this?
>>>>>>>
>>>>>>> - Alex
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Vamsee
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Kalyan Kumar Kalvagadda <kk...@cloudera.com>.
I agree with Sergio but I'm not sure if current plan is to release HA
functionality.
If we plan to make it a release, we need to make sure sentry HA works with
one of the versions of Hive where
1. Notification log implementation has the functionality that sentry
needs.
2. Supports authorization V1.
-Kalyan
On Wed, Apr 19, 2017 at 10:34 AM, Sergio Pena <se...@cloudera.com>
wrote:
> Pointing the branch to master sounds good.
>
> I just have one concern regarding the Hive dependency that Sentry HA needs.
> This new feature requires that the Hive version running with Sentry master
> has HMS notification logs enabled. Hive 1.1.0 (currently officially
> supported by Sentry 1.7) started this HMS notification feature but seems it
> is unstable. At least I found a bug on Hive 1.1.0 that it might make Sentry
> unusable with this version + others required fixes and improvements that
> exist only on Hive 2.x.
>
> This bug is fixed on Hive 1.2.0:
> HIVE-9501: DbNotificationListener doesn't include dbname in create
> database notification and does not include tablename in create table
> notification.
>
> To make things complicated, bumping Sentry to support Hive 1.2.0 is not an
> easy task due to the new authorization v2 hooks that are used in Hive. See
> the comments on the below SENTRY jira:
>
> SENTRY-1323: Bump the hive version to 1.2.0
>
> So, my question is what would happen with the Sentry 1.x compatibility if
> we do this switch from sentry-ha-redesign -> master?
>
> On Tue, Apr 18, 2017 at 3:45 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> > OK thanks, sounds good to me then. Let's try and do development work on
> > master from now on though...
> >
> > Colm.
> >
> > On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov <ak...@cloudera.com>
> > wrote:
> >
> > > FYI, I contacted Colin Ma who was working on the refactoring and he was
> > Ok
> > > with skipping this change for 1.8. That said, the refactoring was done
> > for
> > > a reason it we should get back to it post 1.8,
> > >
> > > - Alex
> > >
> > > On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
> > >
> > > > The proposal is good to me as well. Should we start a vote on this?
> Or
> > we
> > > > can just start to do it if no one is objecting?
> > > >
> > > > Best,
> > > > Hao
> > > >
> > > > On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <
> > vamsee@cloudera.com>
> > > > wrote:
> > > >
> > > > > >
> > > > > > Cherry-pick any commits that happened since sentry-ha-redesign
> was
> > > > > forked,
> > > > > > except a few described below
> > > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > > Rename master to a dev branch
> > > > > > Rename sentry-ha-redesign to master
> > > > >
> > > > >
> > > > > This sounds good to me. Generally having merge commits complicates
> > the
> > > > git
> > > > > history and might get tricky when we are debugging things. I would
> > > rather
> > > > > stick with the approach of cherry-picks to make the history clear.
> > > > >
> > > > > Thanks,
> > > > > Vamsee
> > > > >
> > > > > On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <
> > akolb@cloudera.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > I would like to make a more concrete proposal and I am interested
> > in
> > > > > > opinion from Sentry PMC members on this.
> > > > > >
> > > > > > I would propose the following approach for merging Sentry HA into
> > > > Sentry
> > > > > > master:
> > > > > >
> > > > > > Cherry-pick any commits that happened since sentry-ha-redesign
> was
> > > > > forked,
> > > > > > except a few described below
> > > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > > Rename master to a dev branch
> > > > > > Rename sentry-ha-redesign to master
> > > > > >
> > > > > > What does community think about such approach?
> > > > > >
> > > > > > - Alex
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <
> > > akolb@cloudera.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I would like to start the discussion on merging
> > sentry-ha-redesign
> > > > > > branch with master.
> > > > > > >
> > > > > > > As of now most of the changes from master are merged into
> > > > > > sentry-ha-redesign. The major missing part is SENTRY-1205
> (Refactor
> > > the
> > > > > > code for sentry-provider-db and create sentry-service module) and
> > > > > > associated issues. This refactoring is very hard to port,
> > especially
> > > > > since
> > > > > > there is very little information in the JIRA on why it was done
> and
> > > how
> > > > > it
> > > > > > was done - was it merely moving files around or more then that. I
> > > would
> > > > > > seriously consider not including this change in 1.8.
> > > > > > >
> > > > > > > So in regards to the merge we have several options:
> > > > > > >
> > > > > > > Attempt to merge master into sentry-ha-redesign, resolve any
> > > > conflicts
> > > > > > and later commit the merge to master. This will cause merge
> commit
> > on
> > > > > master
> > > > > > > Finish work on sentry-ha-redesign, make sure that relevant
> > commits
> > > > are
> > > > > > ported from master, and then making this a master branch and
> making
> > > > > current
> > > > > > master a special branch left for reference purposes. This will
> > likely
> > > > > leave
> > > > > > SENTRY-1205 and related issues out.
> > > > > > > What does community think about this?
> > > > > > >
> > > > > > > - Alex
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > Vamsee
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Kalyan Kumar Kalvagadda <kk...@cloudera.com>.
I agree with Sergio but I'm not sure if current plan is to release HA
functionality.
If we plan to make it a release, we need to make sure sentry HA works with
one of the versions of Hive where
1. Notification log implementation has the functionality that sentry
needs.
2. Supports authorization V1.
-Kalyan
-Kalyan
On Wed, Apr 19, 2017 at 10:34 AM, Sergio Pena <se...@cloudera.com>
wrote:
> Pointing the branch to master sounds good.
>
> I just have one concern regarding the Hive dependency that Sentry HA needs.
> This new feature requires that the Hive version running with Sentry master
> has HMS notification logs enabled. Hive 1.1.0 (currently officially
> supported by Sentry 1.7) started this HMS notification feature but seems it
> is unstable. At least I found a bug on Hive 1.1.0 that it might make Sentry
> unusable with this version + others required fixes and improvements that
> exist only on Hive 2.x.
>
> This bug is fixed on Hive 1.2.0:
> HIVE-9501: DbNotificationListener doesn't include dbname in create
> database notification and does not include tablename in create table
> notification.
>
> To make things complicated, bumping Sentry to support Hive 1.2.0 is not an
> easy task due to the new authorization v2 hooks that are used in Hive. See
> the comments on the below SENTRY jira:
>
> SENTRY-1323: Bump the hive version to 1.2.0
>
> So, my question is what would happen with the Sentry 1.x compatibility if
> we do this switch from sentry-ha-redesign -> master?
>
> On Tue, Apr 18, 2017 at 3:45 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> > OK thanks, sounds good to me then. Let's try and do development work on
> > master from now on though...
> >
> > Colm.
> >
> > On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov <ak...@cloudera.com>
> > wrote:
> >
> > > FYI, I contacted Colin Ma who was working on the refactoring and he was
> > Ok
> > > with skipping this change for 1.8. That said, the refactoring was done
> > for
> > > a reason it we should get back to it post 1.8,
> > >
> > > - Alex
> > >
> > > On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
> > >
> > > > The proposal is good to me as well. Should we start a vote on this?
> Or
> > we
> > > > can just start to do it if no one is objecting?
> > > >
> > > > Best,
> > > > Hao
> > > >
> > > > On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <
> > vamsee@cloudera.com>
> > > > wrote:
> > > >
> > > > > >
> > > > > > Cherry-pick any commits that happened since sentry-ha-redesign
> was
> > > > > forked,
> > > > > > except a few described below
> > > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > > Rename master to a dev branch
> > > > > > Rename sentry-ha-redesign to master
> > > > >
> > > > >
> > > > > This sounds good to me. Generally having merge commits complicates
> > the
> > > > git
> > > > > history and might get tricky when we are debugging things. I would
> > > rather
> > > > > stick with the approach of cherry-picks to make the history clear.
> > > > >
> > > > > Thanks,
> > > > > Vamsee
> > > > >
> > > > > On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <
> > akolb@cloudera.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > I would like to make a more concrete proposal and I am interested
> > in
> > > > > > opinion from Sentry PMC members on this.
> > > > > >
> > > > > > I would propose the following approach for merging Sentry HA into
> > > > Sentry
> > > > > > master:
> > > > > >
> > > > > > Cherry-pick any commits that happened since sentry-ha-redesign
> was
> > > > > forked,
> > > > > > except a few described below
> > > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > > Rename master to a dev branch
> > > > > > Rename sentry-ha-redesign to master
> > > > > >
> > > > > > What does community think about such approach?
> > > > > >
> > > > > > - Alex
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <
> > > akolb@cloudera.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I would like to start the discussion on merging
> > sentry-ha-redesign
> > > > > > branch with master.
> > > > > > >
> > > > > > > As of now most of the changes from master are merged into
> > > > > > sentry-ha-redesign. The major missing part is SENTRY-1205
> (Refactor
> > > the
> > > > > > code for sentry-provider-db and create sentry-service module) and
> > > > > > associated issues. This refactoring is very hard to port,
> > especially
> > > > > since
> > > > > > there is very little information in the JIRA on why it was done
> and
> > > how
> > > > > it
> > > > > > was done - was it merely moving files around or more then that. I
> > > would
> > > > > > seriously consider not including this change in 1.8.
> > > > > > >
> > > > > > > So in regards to the merge we have several options:
> > > > > > >
> > > > > > > Attempt to merge master into sentry-ha-redesign, resolve any
> > > > conflicts
> > > > > > and later commit the merge to master. This will cause merge
> commit
> > on
> > > > > master
> > > > > > > Finish work on sentry-ha-redesign, make sure that relevant
> > commits
> > > > are
> > > > > > ported from master, and then making this a master branch and
> making
> > > > > current
> > > > > > master a special branch left for reference purposes. This will
> > likely
> > > > > leave
> > > > > > SENTRY-1205 and related issues out.
> > > > > > > What does community think about this?
> > > > > > >
> > > > > > > - Alex
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > Vamsee
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Sergio Pena <se...@cloudera.com>.
Pointing the branch to master sounds good.
I just have one concern regarding the Hive dependency that Sentry HA needs.
This new feature requires that the Hive version running with Sentry master
has HMS notification logs enabled. Hive 1.1.0 (currently officially
supported by Sentry 1.7) started this HMS notification feature but seems it
is unstable. At least I found a bug on Hive 1.1.0 that it might make Sentry
unusable with this version + others required fixes and improvements that
exist only on Hive 2.x.
This bug is fixed on Hive 1.2.0:
HIVE-9501: DbNotificationListener doesn't include dbname in create
database notification and does not include tablename in create table
notification.
To make things complicated, bumping Sentry to support Hive 1.2.0 is not an
easy task due to the new authorization v2 hooks that are used in Hive. See
the comments on the below SENTRY jira:
SENTRY-1323: Bump the hive version to 1.2.0
So, my question is what would happen with the Sentry 1.x compatibility if
we do this switch from sentry-ha-redesign -> master?
On Tue, Apr 18, 2017 at 3:45 AM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> OK thanks, sounds good to me then. Let's try and do development work on
> master from now on though...
>
> Colm.
>
> On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
>
> > FYI, I contacted Colin Ma who was working on the refactoring and he was
> Ok
> > with skipping this change for 1.8. That said, the refactoring was done
> for
> > a reason it we should get back to it post 1.8,
> >
> > - Alex
> >
> > On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
> >
> > > The proposal is good to me as well. Should we start a vote on this? Or
> we
> > > can just start to do it if no one is objecting?
> > >
> > > Best,
> > > Hao
> > >
> > > On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <
> vamsee@cloudera.com>
> > > wrote:
> > >
> > > > >
> > > > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > > > forked,
> > > > > except a few described below
> > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > Rename master to a dev branch
> > > > > Rename sentry-ha-redesign to master
> > > >
> > > >
> > > > This sounds good to me. Generally having merge commits complicates
> the
> > > git
> > > > history and might get tricky when we are debugging things. I would
> > rather
> > > > stick with the approach of cherry-picks to make the history clear.
> > > >
> > > > Thanks,
> > > > Vamsee
> > > >
> > > > On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <
> akolb@cloudera.com
> > >
> > > > wrote:
> > > >
> > > > > I would like to make a more concrete proposal and I am interested
> in
> > > > > opinion from Sentry PMC members on this.
> > > > >
> > > > > I would propose the following approach for merging Sentry HA into
> > > Sentry
> > > > > master:
> > > > >
> > > > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > > > forked,
> > > > > except a few described below
> > > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > > Rename master to a dev branch
> > > > > Rename sentry-ha-redesign to master
> > > > >
> > > > > What does community think about such approach?
> > > > >
> > > > > - Alex
> > > > >
> > > > >
> > > > > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <
> > akolb@cloudera.com>
> > > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I would like to start the discussion on merging
> sentry-ha-redesign
> > > > > branch with master.
> > > > > >
> > > > > > As of now most of the changes from master are merged into
> > > > > sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor
> > the
> > > > > code for sentry-provider-db and create sentry-service module) and
> > > > > associated issues. This refactoring is very hard to port,
> especially
> > > > since
> > > > > there is very little information in the JIRA on why it was done and
> > how
> > > > it
> > > > > was done - was it merely moving files around or more then that. I
> > would
> > > > > seriously consider not including this change in 1.8.
> > > > > >
> > > > > > So in regards to the merge we have several options:
> > > > > >
> > > > > > Attempt to merge master into sentry-ha-redesign, resolve any
> > > conflicts
> > > > > and later commit the merge to master. This will cause merge commit
> on
> > > > master
> > > > > > Finish work on sentry-ha-redesign, make sure that relevant
> commits
> > > are
> > > > > ported from master, and then making this a master branch and making
> > > > current
> > > > > master a special branch left for reference purposes. This will
> likely
> > > > leave
> > > > > SENTRY-1205 and related issues out.
> > > > > > What does community think about this?
> > > > > >
> > > > > > - Alex
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Vamsee
> > > >
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Colm O hEigeartaigh <co...@apache.org>.
OK thanks, sounds good to me then. Let's try and do development work on
master from now on though...
Colm.
On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov <ak...@cloudera.com>
wrote:
> FYI, I contacted Colin Ma who was working on the refactoring and he was Ok
> with skipping this change for 1.8. That said, the refactoring was done for
> a reason it we should get back to it post 1.8,
>
> - Alex
>
> On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
>
> > The proposal is good to me as well. Should we start a vote on this? Or we
> > can just start to do it if no one is objecting?
> >
> > Best,
> > Hao
> >
> > On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <va...@cloudera.com>
> > wrote:
> >
> > > >
> > > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > > forked,
> > > > except a few described below
> > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > Rename master to a dev branch
> > > > Rename sentry-ha-redesign to master
> > >
> > >
> > > This sounds good to me. Generally having merge commits complicates the
> > git
> > > history and might get tricky when we are debugging things. I would
> rather
> > > stick with the approach of cherry-picks to make the history clear.
> > >
> > > Thanks,
> > > Vamsee
> > >
> > > On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <akolb@cloudera.com
> >
> > > wrote:
> > >
> > > > I would like to make a more concrete proposal and I am interested in
> > > > opinion from Sentry PMC members on this.
> > > >
> > > > I would propose the following approach for merging Sentry HA into
> > Sentry
> > > > master:
> > > >
> > > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > > forked,
> > > > except a few described below
> > > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > > Rename master to a dev branch
> > > > Rename sentry-ha-redesign to master
> > > >
> > > > What does community think about such approach?
> > > >
> > > > - Alex
> > > >
> > > >
> > > > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <
> akolb@cloudera.com>
> > > > wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > I would like to start the discussion on merging sentry-ha-redesign
> > > > branch with master.
> > > > >
> > > > > As of now most of the changes from master are merged into
> > > > sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor
> the
> > > > code for sentry-provider-db and create sentry-service module) and
> > > > associated issues. This refactoring is very hard to port, especially
> > > since
> > > > there is very little information in the JIRA on why it was done and
> how
> > > it
> > > > was done - was it merely moving files around or more then that. I
> would
> > > > seriously consider not including this change in 1.8.
> > > > >
> > > > > So in regards to the merge we have several options:
> > > > >
> > > > > Attempt to merge master into sentry-ha-redesign, resolve any
> > conflicts
> > > > and later commit the merge to master. This will cause merge commit on
> > > master
> > > > > Finish work on sentry-ha-redesign, make sure that relevant commits
> > are
> > > > ported from master, and then making this a master branch and making
> > > current
> > > > master a special branch left for reference purposes. This will likely
> > > leave
> > > > SENTRY-1205 and related issues out.
> > > > > What does community think about this?
> > > > >
> > > > > - Alex
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Vamsee
> > >
> >
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Alexander Kolbasov <ak...@cloudera.com>.
FYI, I contacted Colin Ma who was working on the refactoring and he was Ok
with skipping this change for 1.8. That said, the refactoring was done for
a reason it we should get back to it post 1.8,
- Alex
On Mon, Apr 17, 2017 at 5:51 PM Hao Hao <ha...@cloudera.com> wrote:
> The proposal is good to me as well. Should we start a vote on this? Or we
> can just start to do it if no one is objecting?
>
> Best,
> Hao
>
> On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <va...@cloudera.com>
> wrote:
>
> > >
> > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > forked,
> > > except a few described below
> > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > Rename master to a dev branch
> > > Rename sentry-ha-redesign to master
> >
> >
> > This sounds good to me. Generally having merge commits complicates the
> git
> > history and might get tricky when we are debugging things. I would rather
> > stick with the approach of cherry-picks to make the history clear.
> >
> > Thanks,
> > Vamsee
> >
> > On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <ak...@cloudera.com>
> > wrote:
> >
> > > I would like to make a more concrete proposal and I am interested in
> > > opinion from Sentry PMC members on this.
> > >
> > > I would propose the following approach for merging Sentry HA into
> Sentry
> > > master:
> > >
> > > Cherry-pick any commits that happened since sentry-ha-redesign was
> > forked,
> > > except a few described below
> > > Exclude big refactoring commit (SENTRY-1205) and related commits
> > > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > > Rename master to a dev branch
> > > Rename sentry-ha-redesign to master
> > >
> > > What does community think about such approach?
> > >
> > > - Alex
> > >
> > >
> > > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <ak...@cloudera.com>
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > I would like to start the discussion on merging sentry-ha-redesign
> > > branch with master.
> > > >
> > > > As of now most of the changes from master are merged into
> > > sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the
> > > code for sentry-provider-db and create sentry-service module) and
> > > associated issues. This refactoring is very hard to port, especially
> > since
> > > there is very little information in the JIRA on why it was done and how
> > it
> > > was done - was it merely moving files around or more then that. I would
> > > seriously consider not including this change in 1.8.
> > > >
> > > > So in regards to the merge we have several options:
> > > >
> > > > Attempt to merge master into sentry-ha-redesign, resolve any
> conflicts
> > > and later commit the merge to master. This will cause merge commit on
> > master
> > > > Finish work on sentry-ha-redesign, make sure that relevant commits
> are
> > > ported from master, and then making this a master branch and making
> > current
> > > master a special branch left for reference purposes. This will likely
> > leave
> > > SENTRY-1205 and related issues out.
> > > > What does community think about this?
> > > >
> > > > - Alex
> > >
> > >
> >
> >
> > --
> > Thanks,
> > Vamsee
> >
>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Hao Hao <ha...@cloudera.com>.
The proposal is good to me as well. Should we start a vote on this? Or we
can just start to do it if no one is objecting?
Best,
Hao
On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda <va...@cloudera.com>
wrote:
> >
> > Cherry-pick any commits that happened since sentry-ha-redesign was
> forked,
> > except a few described below
> > Exclude big refactoring commit (SENTRY-1205) and related commits
> > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > Rename master to a dev branch
> > Rename sentry-ha-redesign to master
>
>
> This sounds good to me. Generally having merge commits complicates the git
> history and might get tricky when we are debugging things. I would rather
> stick with the approach of cherry-picks to make the history clear.
>
> Thanks,
> Vamsee
>
> On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
>
> > I would like to make a more concrete proposal and I am interested in
> > opinion from Sentry PMC members on this.
> >
> > I would propose the following approach for merging Sentry HA into Sentry
> > master:
> >
> > Cherry-pick any commits that happened since sentry-ha-redesign was
> forked,
> > except a few described below
> > Exclude big refactoring commit (SENTRY-1205) and related commits
> > (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> > Rename master to a dev branch
> > Rename sentry-ha-redesign to master
> >
> > What does community think about such approach?
> >
> > - Alex
> >
> >
> > > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <ak...@cloudera.com>
> > wrote:
> > >
> > > Hello,
> > >
> > > I would like to start the discussion on merging sentry-ha-redesign
> > branch with master.
> > >
> > > As of now most of the changes from master are merged into
> > sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the
> > code for sentry-provider-db and create sentry-service module) and
> > associated issues. This refactoring is very hard to port, especially
> since
> > there is very little information in the JIRA on why it was done and how
> it
> > was done - was it merely moving files around or more then that. I would
> > seriously consider not including this change in 1.8.
> > >
> > > So in regards to the merge we have several options:
> > >
> > > Attempt to merge master into sentry-ha-redesign, resolve any conflicts
> > and later commit the merge to master. This will cause merge commit on
> master
> > > Finish work on sentry-ha-redesign, make sure that relevant commits are
> > ported from master, and then making this a master branch and making
> current
> > master a special branch left for reference purposes. This will likely
> leave
> > SENTRY-1205 and related issues out.
> > > What does community think about this?
> > >
> > > - Alex
> >
> >
>
>
> --
> Thanks,
> Vamsee
>
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Vamsee Yarlagadda <va...@cloudera.com>.
>
> Cherry-pick any commits that happened since sentry-ha-redesign was forked,
> except a few described below
> Exclude big refactoring commit (SENTRY-1205) and related commits
> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> Rename master to a dev branch
> Rename sentry-ha-redesign to master
This sounds good to me. Generally having merge commits complicates the git
history and might get tricky when we are debugging things. I would rather
stick with the approach of cherry-picks to make the history clear.
Thanks,
Vamsee
On Tue, Apr 4, 2017 at 7:17 PM, Alexander Kolbasov <ak...@cloudera.com>
wrote:
> I would like to make a more concrete proposal and I am interested in
> opinion from Sentry PMC members on this.
>
> I would propose the following approach for merging Sentry HA into Sentry
> master:
>
> Cherry-pick any commits that happened since sentry-ha-redesign was forked,
> except a few described below
> Exclude big refactoring commit (SENTRY-1205) and related commits
> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> Rename master to a dev branch
> Rename sentry-ha-redesign to master
>
> What does community think about such approach?
>
> - Alex
>
>
> > On Mar 22, 2017, at 1:43 PM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
> >
> > Hello,
> >
> > I would like to start the discussion on merging sentry-ha-redesign
> branch with master.
> >
> > As of now most of the changes from master are merged into
> sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the
> code for sentry-provider-db and create sentry-service module) and
> associated issues. This refactoring is very hard to port, especially since
> there is very little information in the JIRA on why it was done and how it
> was done - was it merely moving files around or more then that. I would
> seriously consider not including this change in 1.8.
> >
> > So in regards to the merge we have several options:
> >
> > Attempt to merge master into sentry-ha-redesign, resolve any conflicts
> and later commit the merge to master. This will cause merge commit on master
> > Finish work on sentry-ha-redesign, make sure that relevant commits are
> ported from master, and then making this a master branch and making current
> master a special branch left for reference purposes. This will likely leave
> SENTRY-1205 and related issues out.
> > What does community think about this?
> >
> > - Alex
>
>
--
Thanks,
Vamsee