Quick question from a bystander: it seems like Sentry committed an API-incompatible change. Instead of fixing on the Impala side, should the Sentry project be notified that they may want to roll back such a change? It seems like an error on their part to do such a thing within a minor version.
On Mon, Jun 19, 2017 at 1:56 PM, Thomas Tauber-Marshall < [email protected]> wrote: > I'm working on getting the s3 jars updated, which presumably will fix that. > > The problem (to my understanding) is that the nightlies haven't passed > since the change went into Sentry and so the Jenkins job that normally > produces the new jars is still pulling in old bits. > > I've been talking with releng and they expect the new jars to be available > later today. > > On Mon, Jun 19, 2017 at 3:48 PM Tim Armstrong <[email protected]> > wrote: > > > Looks like the build still breaks when starting up sentry after my fix: > > > > http://jenkins.impala.io:8080/job/ubuntu-14.04-from-scratch/1547/console > > > > *20:08:54* --> Starting the Sentry Policy Server*20:08:59* Error in > > /home/ubuntu/Impala/testdata/bin/run-all.sh at line 58: > > $IMPALA_HOME/testdata/bin/run-sentry-service.sh > \*20:08:59* + > > onexit*20:08:59* + df -m*20:08:59* Filesystem 1M-blocks Used > > Available Use% Mounted on*20:08:59* udev 15070 1 > > 15070 1% /dev*20:08:59* tmpfs 3015 1 3015 > > 1% /run*20:08:59* /dev/xvda1 161129 22275 132204 15% > > /*20:08:59* none 1 0 1 0% > > /sys/fs/cgroup*20:08:59* none 5 0 5 0% > > /run/lock*20:08:59* none 15075 1 15075 1% > > /run/shm*20:08:59* none 100 0 100 0% > > /run/user*20:08:59* + free -m*20:08:59* total used > > free shared buffers cached*20:08:59* Mem: > > 30148 19597 10550 11 91 14323*20:08:59* > > -/+ buffers/cache: 5182 24965*20:08:59* Swap: 0 > > 0 0*20:08:59* + uptime -p*20:08:59* up 45 > > minutes*20:08:59* + rm -rf /home/ubuntu/Impala/logs_static*20:08:59* + > > mkdir -p /home/ubuntu/Impala/logs_static*20:08:59* + cp -r -L > > /home/ubuntu/Impala/logs /home/ubuntu/Impala/logs_static*20:08:59* > > Build step 'Execute shell' marked build as failure*20:08:59* Set build > > name.*20:08:59* New build name is '#1547 > > refs/changes/22/7222/3'*20:08:59* Variable with name > > 'BUILD_DISPLAY_NAME' already exists, current value: '#1547 > > refs/changes/22/7222/3', new value: '#1547 > > refs/changes/22/7222/3'*20:09:12* Archiving artifacts*20:09:21* > > Finished: FAILURE > > > > > > On Mon, Jun 19, 2017 at 12:23 PM, Tim Armstrong <[email protected] > > > > wrote: > > > > > It's unclear if there will be incompatibility between the updated > client > > > and the version of sentry we use for the minicluster. I kicked off a > test > > > run to see if it works. > > > > > > On Mon, Jun 19, 2017 at 12:06 PM, Henry Robinson <[email protected]> > > wrote: > > > > > >> Presumably this will break GVO jobs as well - should we commit Tim's > > patch > > >> to get us moving again while Alex works on the root cause? > > >> > > >> On 19 June 2017 at 09:23, Alexander Behm <[email protected]> > > wrote: > > >> > > >> > Meanwhile, I'll work on fixing the root cause: > > >> > https://issues.apache.org/jira/browse/IMPALA-5530 > > >> > > > >> > On Mon, Jun 19, 2017 at 9:20 AM, Tim Armstrong < > > [email protected] > > >> > > > >> > wrote: > > >> > > > >> > > You may have noticed that Impala doesn't build this morning > because > > >> of a > > >> > > sentry exception class no longer existing. I was able to unblock > > >> myself > > >> > > with this change, if you want to cherry-pick it: > > >> > > https://gerrit.cloudera.org/#/c/7222/ > > >> > > > > >> > > > >> > > > > > > > > > -- Todd Lipcon Software Engineer, Cloudera
