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/03/22 20:43:49 UTC
[DISCUSS] Merging Sentry HA branch with master
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
Re: [DISCUSS] Merging Sentry HA branch with master
Posted by Alexander Kolbasov <ak...@cloudera.com>.
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 Alexander Kolbasov <ak...@cloudera.com>.
> On Mar 22, 2017, at 2:39 PM, Sergio Pena <se...@cloudera.com> wrote:
>
> The usual way we do this in other projects is the 1st option. We can create a new JIRA for the merge, then submit the patch with the conflicts resolved, wait for tests, then commit it.
The real question here is whether we allow merge commits or not for Sentry. It would be rather difficult do do without a merge commit.
>
> Although the 2nd option looks easier if we only missing one commit, but I think we should avoid it just in case we missed to port some commits from master to the branch.
>
> If you don't want to include SENTRY-1205, then just revert it from master, and then do the merge from sentry-ha-design to master. That would work.
At this point even everting SENTRY-1205 from master is quite non-trivial because many of the moved files also changed. That’s why I am bringing this up, otherwise it would be a clear deal.
- Sasha
>
> On Wed, Mar 22, 2017 at 3:43 PM, Alexander Kolbasov <akolb@cloudera.com <ma...@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 Sergio Pena <se...@cloudera.com>.
The usual way we do this in other projects is the 1st option. We can create
a new JIRA for the merge, then submit the patch with the conflicts
resolved, wait for tests, then commit it.
Although the 2nd option looks easier if we only missing one commit, but I
think we should avoid it just in case we missed to port some commits from
master to the branch.
If you don't want to include SENTRY-1205, then just revert it from master,
and then do the merge from sentry-ha-design to master. That would work.
On Wed, Mar 22, 2017 at 3: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
>