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 <sergio.p...@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 <cohei...@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 <hao....@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 < >> vam...@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 >>>>> >>>> >>> >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >>
