You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/12/23 21:34:34 UTC
CI improvements [Was: The state of new CI]
Guys,
I've been trying to replicate our CI elsewhere and here's a couple of
observations and proposed fixes that might do such things easier in the
future.
1. Running build as root inside of the docker container.
This seems like a real issue, especially considering that we have always
advocated to stay away from such practice. Unfortunately, adding
-u jenkins:jenkins
to docker run snags on a couple of points
2. Shared Gradle directory shouldn't belong to root, or at least should be
writable for everyone.
This is covered in BIGTOP-2171 (appreciate the review) and has caused user
confusions like BIGTOP-2184
3. One perhaps last issue here is the discrepancy between the user ids, where
jenkins on centos and ubuntu have different UID (BIGTOP-2187)
I think with these three in place, we should be able to start using
un-privileged user for the builds and also for the cluster testing.
Thoughts?
Cos
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
In other words, you want to move the control over the build containers
completely into the Bigtop build system. That would make sense, of course. The
damn effective user might be still an issue somewhat. If you're interested, I
did this dumb-ass workaround
https://github.com/c0s/dumb-ass-scripts/blob/master/run-with-eff-user.sh
for the effective user problem. It is ugly, but at least let go around the
permissions impedance.
In gradle, you can use build properties (set with -P) which are way better
than sysprops. In particular, they can be changed in the user environment via
build.properties file. Another option is to use configurations: something
along the lines of Maven profiles, only way better of course ;)
Cheers,
Cos
On Thu, Dec 24, 2015 at 05:06PM, Roman Shaposhnik wrote:
> On Wed, Dec 23, 2015 at 10:38 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Actually, there's more into this. Mounting volumes from a host will always be
> > a subject to disrepancies between host's user uid/gio and ones inside of the
> > container. We still should go ahead at least with 2) and 3) in the short run.
>
> Let me look into this today. I think we may as well solve it once and for all.
> In fact, looking at how our Jenkins job is setup I'm thinking that
> perhaps having
> a direct Docker-enabled entry point into our build process will be better than
> keep remembering an exact incantation of Docker.
>
> So how about we implement a sysprop bigtop.build.env so that the following
> will happen:
> 1. with bigtop.build.env not set we get the current build process remains
> the same
> 2. with bigtop.build.env set to one of the build environment values that we
> recognize the Docker magic is transparently invoked
> 3. with bigtop.build.env set to anything else Gradle prints the
> list of build
> environments and exists
>
> Thoughts?
>
> Thanks,
> Roman.
>
> P.S. If it were Maven, I'd hook it up as a profile, but I guess with
> Gradle sysprops
> is all we get to switch things around, right?
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
In other words, you want to move the control over the build containers
completely into the Bigtop build system. That would make sense, of course. The
damn effective user might be still an issue somewhat. If you're interested, I
did this dumb-ass workaround
https://github.com/c0s/dumb-ass-scripts/blob/master/run-with-eff-user.sh
for the effective user problem. It is ugly, but at least let go around the
permissions impedance.
In gradle, you can use build properties (set with -P) which are way better
than sysprops. In particular, they can be changed in the user environment via
build.properties file. Another option is to use configurations: something
along the lines of Maven profiles, only way better of course ;)
Cheers,
Cos
On Thu, Dec 24, 2015 at 05:06PM, Roman Shaposhnik wrote:
> On Wed, Dec 23, 2015 at 10:38 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Actually, there's more into this. Mounting volumes from a host will always be
> > a subject to disrepancies between host's user uid/gio and ones inside of the
> > container. We still should go ahead at least with 2) and 3) in the short run.
>
> Let me look into this today. I think we may as well solve it once and for all.
> In fact, looking at how our Jenkins job is setup I'm thinking that
> perhaps having
> a direct Docker-enabled entry point into our build process will be better than
> keep remembering an exact incantation of Docker.
>
> So how about we implement a sysprop bigtop.build.env so that the following
> will happen:
> 1. with bigtop.build.env not set we get the current build process remains
> the same
> 2. with bigtop.build.env set to one of the build environment values that we
> recognize the Docker magic is transparently invoked
> 3. with bigtop.build.env set to anything else Gradle prints the
> list of build
> environments and exists
>
> Thoughts?
>
> Thanks,
> Roman.
>
> P.S. If it were Maven, I'd hook it up as a profile, but I guess with
> Gradle sysprops
> is all we get to switch things around, right?
Re: CI improvements [Was: The state of new CI]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Dec 23, 2015 at 10:38 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Actually, there's more into this. Mounting volumes from a host will always be
> a subject to disrepancies between host's user uid/gio and ones inside of the
> container. We still should go ahead at least with 2) and 3) in the short run.
Let me look into this today. I think we may as well solve it once and for all.
In fact, looking at how our Jenkins job is setup I'm thinking that
perhaps having
a direct Docker-enabled entry point into our build process will be better than
keep remembering an exact incantation of Docker.
So how about we implement a sysprop bigtop.build.env so that the following
will happen:
1. with bigtop.build.env not set we get the current build process remains
the same
2. with bigtop.build.env set to one of the build environment values that we
recognize the Docker magic is transparently invoked
3. with bigtop.build.env set to anything else Gradle prints the
list of build
environments and exists
Thoughts?
Thanks,
Roman.
P.S. If it were Maven, I'd hook it up as a profile, but I guess with
Gradle sysprops
is all we get to switch things around, right?
Re: CI improvements [Was: The state of new CI]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Dec 23, 2015 at 10:38 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Actually, there's more into this. Mounting volumes from a host will always be
> a subject to disrepancies between host's user uid/gio and ones inside of the
> container. We still should go ahead at least with 2) and 3) in the short run.
Let me look into this today. I think we may as well solve it once and for all.
In fact, looking at how our Jenkins job is setup I'm thinking that
perhaps having
a direct Docker-enabled entry point into our build process will be better than
keep remembering an exact incantation of Docker.
So how about we implement a sysprop bigtop.build.env so that the following
will happen:
1. with bigtop.build.env not set we get the current build process remains
the same
2. with bigtop.build.env set to one of the build environment values that we
recognize the Docker magic is transparently invoked
3. with bigtop.build.env set to anything else Gradle prints the
list of build
environments and exists
Thoughts?
Thanks,
Roman.
P.S. If it were Maven, I'd hook it up as a profile, but I guess with
Gradle sysprops
is all we get to switch things around, right?
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
Actually, there's more into this. Mounting volumes from a host will always be
a subject to disrepancies between host's user uid/gio and ones inside of the
container. We still should go ahead at least with 2) and 3) in the short run.
Cos
On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> Guys,
>
> I've been trying to replicate our CI elsewhere and here's a couple of
> observations and proposed fixes that might do such things easier in the
> future.
>
> 1. Running build as root inside of the docker container.
>
> This seems like a real issue, especially considering that we have always
> advocated to stay away from such practice. Unfortunately, adding
> -u jenkins:jenkins
> to docker run snags on a couple of points
>
> 2. Shared Gradle directory shouldn't belong to root, or at least should be
> writable for everyone.
>
> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> confusions like BIGTOP-2184
>
> 3. One perhaps last issue here is the discrepancy between the user ids, where
> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>
> I think with these three in place, we should be able to start using
> un-privileged user for the builds and also for the cluster testing.
>
> Thoughts?
> Cos
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Dec 23, 2015 at 01:13PM, Roman Shaposhnik wrote:
> On Wed, Dec 23, 2015 at 12:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Guys,
> >
> > I've been trying to replicate our CI elsewhere and here's a couple of
> > observations and proposed fixes that might do such things easier in the
> > future.
> >
> > 1. Running build as root inside of the docker container.
> >
> > This seems like a real issue, especially considering that we have always
> > advocated to stay away from such practice. Unfortunately, adding
> > -u jenkins:jenkins
> > to docker run snags on a couple of points
>
> Can you elaborate on this?
Did you look at the tickets I referred?
Cos
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Dec 23, 2015 at 01:13PM, Roman Shaposhnik wrote:
> On Wed, Dec 23, 2015 at 12:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Guys,
> >
> > I've been trying to replicate our CI elsewhere and here's a couple of
> > observations and proposed fixes that might do such things easier in the
> > future.
> >
> > 1. Running build as root inside of the docker container.
> >
> > This seems like a real issue, especially considering that we have always
> > advocated to stay away from such practice. Unfortunately, adding
> > -u jenkins:jenkins
> > to docker run snags on a couple of points
>
> Can you elaborate on this?
After 2 days I suddenly understood what you were asking me about ;) There's
not a single JIRA in my original email that is clearly connected to the snags.
The main issue is that running a build inside of a container (as non-root
user) is in jeopardy of folder permissions, used as a volume in the the
container. One way around it, as we have discussed off-line last night, is to
create effective user insides of the container dynamically. This is hack, of
course, but in reality the whole docker is a chroot hack, so how much worst
it could be, right?
These's some potential security implications in the approach like this, but
considering that we are running a pretty tight ship, controlling the
CI environment, we should be fine.
Cos
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Dec 23, 2015 at 01:13PM, Roman Shaposhnik wrote:
> On Wed, Dec 23, 2015 at 12:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Guys,
> >
> > I've been trying to replicate our CI elsewhere and here's a couple of
> > observations and proposed fixes that might do such things easier in the
> > future.
> >
> > 1. Running build as root inside of the docker container.
> >
> > This seems like a real issue, especially considering that we have always
> > advocated to stay away from such practice. Unfortunately, adding
> > -u jenkins:jenkins
> > to docker run snags on a couple of points
>
> Can you elaborate on this?
After 2 days I suddenly understood what you were asking me about ;) There's
not a single JIRA in my original email that is clearly connected to the snags.
The main issue is that running a build inside of a container (as non-root
user) is in jeopardy of folder permissions, used as a volume in the the
container. One way around it, as we have discussed off-line last night, is to
create effective user insides of the container dynamically. This is hack, of
course, but in reality the whole docker is a chroot hack, so how much worst
it could be, right?
These's some potential security implications in the approach like this, but
considering that we are running a pretty tight ship, controlling the
CI environment, we should be fine.
Cos
Re: CI improvements [Was: The state of new CI]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Dec 23, 2015 at 12:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Guys,
>
> I've been trying to replicate our CI elsewhere and here's a couple of
> observations and proposed fixes that might do such things easier in the
> future.
>
> 1. Running build as root inside of the docker container.
>
> This seems like a real issue, especially considering that we have always
> advocated to stay away from such practice. Unfortunately, adding
> -u jenkins:jenkins
> to docker run snags on a couple of points
Can you elaborate on this?
Thanks,
Roman.
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
I have built an image for ubuntu-14.04 and do have a config for vagrant
provisioner for that OS as well. If there's no objections - I will open a
ticket and contribute it back?
Cos
On Sat, Dec 26, 2015 at 04:21PM, Konstantin Boudnik wrote:
> On a slightly separate note (may be Jay knows the answer): I noticed that we
> only have centos-6 and debian-8 deploy images. Is there any technical reason
> for not making them (and limiting our ability to do automatic testing) or it
> just never been implemented?
>
> Thanks
> Cos
>
> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> > Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
> > up the idea of automatically producing the package repos of the nightly
> > builds. With a few lines of shell we can do it as demonstrated in
> >
> > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> > and
> > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> >
> > Considering that we are dealing here with a matrix of OSes in this case, it
> > won't be perhaps ideal to roll this functionality into the main build. Keeping
> > it as an aux helper seems like a better idea.
> > There's of course disk-consumption issue, but we might be able to solve it.
> >
> > Thoughts?
> > Cos
> >
> > On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> > > Guys,
> > >
> > > I've been trying to replicate our CI elsewhere and here's a couple of
> > > observations and proposed fixes that might do such things easier in the
> > > future.
> > >
> > > 1. Running build as root inside of the docker container.
> > >
> > > This seems like a real issue, especially considering that we have always
> > > advocated to stay away from such practice. Unfortunately, adding
> > > -u jenkins:jenkins
> > > to docker run snags on a couple of points
> > >
> > > 2. Shared Gradle directory shouldn't belong to root, or at least should be
> > > writable for everyone.
> > >
> > > This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> > > confusions like BIGTOP-2184
> > >
> > > 3. One perhaps last issue here is the discrepancy between the user ids, where
> > > jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> > >
> > > I think with these three in place, we should be able to start using
> > > un-privileged user for the builds and also for the cluster testing.
> > >
> > > Thoughts?
> > > Cos
> > >
> > >
> >
> >
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Jay Vyas <ja...@gmail.com>.
1) Agree we can move to docker native solutions. Of course, this makes it impossible to test the bare metal deployments that some folks still care about. Otto also seems promising, it's ec2 native....
Now, If we think docker is better for testing, then relying on OS specific VMs, maybe that's telling us something about the future of production big data clusters as well....
2) (rehash microservices rant) So..if we agree docker is sufficient for all our testing, why not just move (ok I admit this is a little extreme.. But)... entirely to microservices? That way we can focus on the interesting parts (like keeping up with the spark release cycle, Kafka integration , spark hbase Integration, and so on)...
IMO Ultimately the similarity between deb and rpm containers is a lot higher than the similarity between deb and rpm packages. So containers are exactly what bigtop needs, at all levels of the stack, not just testing .
> On Dec 27, 2015, at 2:09 PM, Olaf Flebbe <of...@oflebbe.de> wrote:
>
> Hi Evans,
>
>> My personal reason for not keep implementing this is because I plan to drop
>> vagrant and embrace docker's native solutions(machine, compose, swarm) for
>> our docker provisioner.
>
> YES! PLEASE! That would be great!
>
> Olaf
Re: CI improvements [Was: The state of new CI]
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Evans,
> My personal reason for not keep implementing this is because I plan to drop
> vagrant and embrace docker's native solutions(machine, compose, swarm) for
> our docker provisioner.
YES! PLEASE! That would be great!
Olaf
Re: CI improvements [Was: The state of new CI]
Posted by Evans Ye <ev...@apache.org>.
Make sense, cos.
For Bigtop Provisioner, It's important to keep supporting upper level needs.
And we should make the switch as transparent as possible so that current
implemented interface won't be changed(a lot).
I remember I've put up some JIRAs for the docker provisioner overhaul. Will
drop more messages there.
2015-12-27 16:20 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> On Sun, Dec 27, 2015 at 03:20PM, Evans Ye wrote:
> > Hey, sorry for disappearing for a while, I was exhausted by a project in
> > trend micro...
>
> Yeah, we all have $dayjobs, I know the feeling ;(
>
> > The reason we don't have ubuntu is just because it hasn't been
> implemented
> > yet.
> > So you're doing the right thing. thanks!
>
> Ah, cool. I have committed a couple of fixes to the source code and added
> a CI
> job to push the deploy images into our docker repo. We can get rid of this
> later, when anything better be ready.
>
> > As one of the developer of the provisioner feature.
> > My personal reason for not keep implementing this is because I plan to
> drop
> > vagrant and embrace docker's native solutions(machine, compose, swarm)
> for
> > our docker provisioner.
> > In that way, we gain better native support, cleaner code, ability to impl
> > multi-host cluster deployment feature, etc.
> > And the most important thing is that we don't need to prepare a docker
> > image for deployment anymore.
> > This drastically increase the UX of docker provisioner. User can drop any
> > docker image as base and deploy Bigtop Hadoop stack on top of it.
> > As of now I only have some initial work for this in private branch. ;)
>
> I agree with the sentiment. In fact, my first urge was to try to implement
> the automatic cluster deployment and testing for CI with docker-compose.
> However, after spending a couple of hours ago today just trying to
> unsuccessfully install the environment, led me to believe that this is a
> very
> immature stuff, with heavy and pretty hairy python-to-C implementation. And
> basically isn't ready for prime-time.
>
> They might be able to finish it over the course of the next few months,
> but in
> the meanwhile we can just stick to the vagrant and move on, if and when
> compose and swarm are in a better shape. Does it make sense?
>
> Whenever you feel like to share your implementation - I would be happy to
> help
> moving it forward.
>
> Cheers,
> Cos
>
>
> > 2015-12-27 11:14 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > On Sat, Dec 26, 2015 at 09:59PM, Jay Vyas wrote:
> > > > Deploy images? I thought we killed all the deploy images entirely
> since
> > > (1)
> > > > boxgrinder died off, and nobody had the packer expertise to redo
> > > everything
> > > > and (2) the vagrant deployer worked effectively for anyone wanting
> to do
> > > a
> > > > quick test.
> > >
> > > I am talking about bigtop/deploy:debian-8 and bigtop/deploy:centos-6
> docker
> > > images.
> > >
> > > Cos
> > > >
> > > > > On Dec 26, 2015, at 7:21 PM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > > >
> > > > > On a slightly separate note (may be Jay knows the answer): I
> noticed
> > > that we
> > > > > only have centos-6 and debian-8 deploy images. Is there any
> technical
> > > reason
> > > > > for not making them (and limiting our ability to do automatic
> testing)
> > > or it
> > > > > just never been implemented?
> > > > >
> > > > > Thanks
> > > > > Cos
> > > > >
> > > > >> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> > > > >> Moving a bit of the topics of pure polishing of rough edges, I
> wanted
> > > to bring
> > > > >> up the idea of automatically producing the package repos of the
> > > nightly
> > > > >> builds. With a few lines of shell we can do it as demonstrated in
> > > > >>
> > > > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> > > > >> and
> > > > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> > > > >>
> > > > >> Considering that we are dealing here with a matrix of OSes in this
> > > case, it
> > > > >> won't be perhaps ideal to roll this functionality into the main
> > > build. Keeping
> > > > >> it as an aux helper seems like a better idea.
> > > > >> There's of course disk-consumption issue, but we might be able to
> > > solve it.
> > > > >>
> > > > >> Thoughts?
> > > > >> Cos
> > > > >>
> > > > >>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> > > > >>> Guys,
> > > > >>>
> > > > >>> I've been trying to replicate our CI elsewhere and here's a
> couple of
> > > > >>> observations and proposed fixes that might do such things easier
> in
> > > the
> > > > >>> future.
> > > > >>>
> > > > >>> 1. Running build as root inside of the docker container.
> > > > >>>
> > > > >>> This seems like a real issue, especially considering that we
> have
> > > always
> > > > >>> advocated to stay away from such practice. Unfortunately,
> adding
> > > > >>> -u jenkins:jenkins
> > > > >>> to docker run snags on a couple of points
> > > > >>>
> > > > >>> 2. Shared Gradle directory shouldn't belong to root, or at least
> > > should be
> > > > >>> writable for everyone.
> > > > >>>
> > > > >>> This is covered in BIGTOP-2171 (appreciate the review) and has
> > > caused user
> > > > >>> confusions like BIGTOP-2184
> > > > >>>
> > > > >>> 3. One perhaps last issue here is the discrepancy between the
> user
> > > ids, where
> > > > >>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> > > > >>>
> > > > >>> I think with these three in place, we should be able to start
> using
> > > > >>> un-privileged user for the builds and also for the cluster
> testing.
> > > > >>>
> > > > >>> Thoughts?
> > > > >>> Cos
> > > > >
> > > > >
> > >
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Sun, Dec 27, 2015 at 03:20PM, Evans Ye wrote:
> Hey, sorry for disappearing for a while, I was exhausted by a project in
> trend micro...
Yeah, we all have $dayjobs, I know the feeling ;(
> The reason we don't have ubuntu is just because it hasn't been implemented
> yet.
> So you're doing the right thing. thanks!
Ah, cool. I have committed a couple of fixes to the source code and added a CI
job to push the deploy images into our docker repo. We can get rid of this
later, when anything better be ready.
> As one of the developer of the provisioner feature.
> My personal reason for not keep implementing this is because I plan to drop
> vagrant and embrace docker's native solutions(machine, compose, swarm) for
> our docker provisioner.
> In that way, we gain better native support, cleaner code, ability to impl
> multi-host cluster deployment feature, etc.
> And the most important thing is that we don't need to prepare a docker
> image for deployment anymore.
> This drastically increase the UX of docker provisioner. User can drop any
> docker image as base and deploy Bigtop Hadoop stack on top of it.
> As of now I only have some initial work for this in private branch. ;)
I agree with the sentiment. In fact, my first urge was to try to implement
the automatic cluster deployment and testing for CI with docker-compose.
However, after spending a couple of hours ago today just trying to
unsuccessfully install the environment, led me to believe that this is a very
immature stuff, with heavy and pretty hairy python-to-C implementation. And
basically isn't ready for prime-time.
They might be able to finish it over the course of the next few months, but in
the meanwhile we can just stick to the vagrant and move on, if and when
compose and swarm are in a better shape. Does it make sense?
Whenever you feel like to share your implementation - I would be happy to help
moving it forward.
Cheers,
Cos
> 2015-12-27 11:14 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
> > On Sat, Dec 26, 2015 at 09:59PM, Jay Vyas wrote:
> > > Deploy images? I thought we killed all the deploy images entirely since
> > (1)
> > > boxgrinder died off, and nobody had the packer expertise to redo
> > everything
> > > and (2) the vagrant deployer worked effectively for anyone wanting to do
> > a
> > > quick test.
> >
> > I am talking about bigtop/deploy:debian-8 and bigtop/deploy:centos-6 docker
> > images.
> >
> > Cos
> > >
> > > > On Dec 26, 2015, at 7:21 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > >
> > > > On a slightly separate note (may be Jay knows the answer): I noticed
> > that we
> > > > only have centos-6 and debian-8 deploy images. Is there any technical
> > reason
> > > > for not making them (and limiting our ability to do automatic testing)
> > or it
> > > > just never been implemented?
> > > >
> > > > Thanks
> > > > Cos
> > > >
> > > >> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> > > >> Moving a bit of the topics of pure polishing of rough edges, I wanted
> > to bring
> > > >> up the idea of automatically producing the package repos of the
> > nightly
> > > >> builds. With a few lines of shell we can do it as demonstrated in
> > > >>
> > > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> > > >> and
> > > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> > > >>
> > > >> Considering that we are dealing here with a matrix of OSes in this
> > case, it
> > > >> won't be perhaps ideal to roll this functionality into the main
> > build. Keeping
> > > >> it as an aux helper seems like a better idea.
> > > >> There's of course disk-consumption issue, but we might be able to
> > solve it.
> > > >>
> > > >> Thoughts?
> > > >> Cos
> > > >>
> > > >>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> > > >>> Guys,
> > > >>>
> > > >>> I've been trying to replicate our CI elsewhere and here's a couple of
> > > >>> observations and proposed fixes that might do such things easier in
> > the
> > > >>> future.
> > > >>>
> > > >>> 1. Running build as root inside of the docker container.
> > > >>>
> > > >>> This seems like a real issue, especially considering that we have
> > always
> > > >>> advocated to stay away from such practice. Unfortunately, adding
> > > >>> -u jenkins:jenkins
> > > >>> to docker run snags on a couple of points
> > > >>>
> > > >>> 2. Shared Gradle directory shouldn't belong to root, or at least
> > should be
> > > >>> writable for everyone.
> > > >>>
> > > >>> This is covered in BIGTOP-2171 (appreciate the review) and has
> > caused user
> > > >>> confusions like BIGTOP-2184
> > > >>>
> > > >>> 3. One perhaps last issue here is the discrepancy between the user
> > ids, where
> > > >>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> > > >>>
> > > >>> I think with these three in place, we should be able to start using
> > > >>> un-privileged user for the builds and also for the cluster testing.
> > > >>>
> > > >>> Thoughts?
> > > >>> Cos
> > > >
> > > >
> >
Re: CI improvements [Was: The state of new CI]
Posted by Evans Ye <ev...@apache.org>.
Hey, sorry for disappearing for a while, I was exhausted by a project in
trend micro...
The reason we don't have ubuntu is just because it hasn't been implemented
yet.
So you're doing the right thing. thanks!
As one of the developer of the provisioner feature.
My personal reason for not keep implementing this is because I plan to drop
vagrant and embrace docker's native solutions(machine, compose, swarm) for
our docker provisioner.
In that way, we gain better native support, cleaner code, ability to impl
multi-host cluster deployment feature, etc.
And the most important thing is that we don't need to prepare a docker
image for deployment anymore.
This drastically increase the UX of docker provisioner. User can drop any
docker image as base and deploy Bigtop Hadoop stack on top of it.
As of now I only have some initial work for this in private branch. ;)
2015-12-27 11:14 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> On Sat, Dec 26, 2015 at 09:59PM, Jay Vyas wrote:
> > Deploy images? I thought we killed all the deploy images entirely since
> (1)
> > boxgrinder died off, and nobody had the packer expertise to redo
> everything
> > and (2) the vagrant deployer worked effectively for anyone wanting to do
> a
> > quick test.
>
> I am talking about bigtop/deploy:debian-8 and bigtop/deploy:centos-6 docker
> images.
>
> Cos
> >
> > > On Dec 26, 2015, at 7:21 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > >
> > > On a slightly separate note (may be Jay knows the answer): I noticed
> that we
> > > only have centos-6 and debian-8 deploy images. Is there any technical
> reason
> > > for not making them (and limiting our ability to do automatic testing)
> or it
> > > just never been implemented?
> > >
> > > Thanks
> > > Cos
> > >
> > >> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> > >> Moving a bit of the topics of pure polishing of rough edges, I wanted
> to bring
> > >> up the idea of automatically producing the package repos of the
> nightly
> > >> builds. With a few lines of shell we can do it as demonstrated in
> > >>
> > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> > >> and
> > >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> > >>
> > >> Considering that we are dealing here with a matrix of OSes in this
> case, it
> > >> won't be perhaps ideal to roll this functionality into the main
> build. Keeping
> > >> it as an aux helper seems like a better idea.
> > >> There's of course disk-consumption issue, but we might be able to
> solve it.
> > >>
> > >> Thoughts?
> > >> Cos
> > >>
> > >>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> > >>> Guys,
> > >>>
> > >>> I've been trying to replicate our CI elsewhere and here's a couple of
> > >>> observations and proposed fixes that might do such things easier in
> the
> > >>> future.
> > >>>
> > >>> 1. Running build as root inside of the docker container.
> > >>>
> > >>> This seems like a real issue, especially considering that we have
> always
> > >>> advocated to stay away from such practice. Unfortunately, adding
> > >>> -u jenkins:jenkins
> > >>> to docker run snags on a couple of points
> > >>>
> > >>> 2. Shared Gradle directory shouldn't belong to root, or at least
> should be
> > >>> writable for everyone.
> > >>>
> > >>> This is covered in BIGTOP-2171 (appreciate the review) and has
> caused user
> > >>> confusions like BIGTOP-2184
> > >>>
> > >>> 3. One perhaps last issue here is the discrepancy between the user
> ids, where
> > >>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> > >>>
> > >>> I think with these three in place, we should be able to start using
> > >>> un-privileged user for the builds and also for the cluster testing.
> > >>>
> > >>> Thoughts?
> > >>> Cos
> > >
> > >
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Sat, Dec 26, 2015 at 09:59PM, Jay Vyas wrote:
> Deploy images? I thought we killed all the deploy images entirely since (1)
> boxgrinder died off, and nobody had the packer expertise to redo everything
> and (2) the vagrant deployer worked effectively for anyone wanting to do a
> quick test.
I am talking about bigtop/deploy:debian-8 and bigtop/deploy:centos-6 docker
images.
Cos
>
> > On Dec 26, 2015, at 7:21 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > On a slightly separate note (may be Jay knows the answer): I noticed that we
> > only have centos-6 and debian-8 deploy images. Is there any technical reason
> > for not making them (and limiting our ability to do automatic testing) or it
> > just never been implemented?
> >
> > Thanks
> > Cos
> >
> >> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> >> Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
> >> up the idea of automatically producing the package repos of the nightly
> >> builds. With a few lines of shell we can do it as demonstrated in
> >>
> >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> >> and
> >> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> >>
> >> Considering that we are dealing here with a matrix of OSes in this case, it
> >> won't be perhaps ideal to roll this functionality into the main build. Keeping
> >> it as an aux helper seems like a better idea.
> >> There's of course disk-consumption issue, but we might be able to solve it.
> >>
> >> Thoughts?
> >> Cos
> >>
> >>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> >>> Guys,
> >>>
> >>> I've been trying to replicate our CI elsewhere and here's a couple of
> >>> observations and proposed fixes that might do such things easier in the
> >>> future.
> >>>
> >>> 1. Running build as root inside of the docker container.
> >>>
> >>> This seems like a real issue, especially considering that we have always
> >>> advocated to stay away from such practice. Unfortunately, adding
> >>> -u jenkins:jenkins
> >>> to docker run snags on a couple of points
> >>>
> >>> 2. Shared Gradle directory shouldn't belong to root, or at least should be
> >>> writable for everyone.
> >>>
> >>> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> >>> confusions like BIGTOP-2184
> >>>
> >>> 3. One perhaps last issue here is the discrepancy between the user ids, where
> >>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> >>>
> >>> I think with these three in place, we should be able to start using
> >>> un-privileged user for the builds and also for the cluster testing.
> >>>
> >>> Thoughts?
> >>> Cos
> >
> >
Re: CI improvements [Was: The state of new CI]
Posted by Jay Vyas <ja...@gmail.com>.
Deploy images? I thought we killed all the deploy images entirely since (1) boxgrinder died off, and nobody had the packer expertise to redo everything and (2) the vagrant deployer worked effectively for anyone wanting to do a quick test.
> On Dec 26, 2015, at 7:21 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> On a slightly separate note (may be Jay knows the answer): I noticed that we
> only have centos-6 and debian-8 deploy images. Is there any technical reason
> for not making them (and limiting our ability to do automatic testing) or it
> just never been implemented?
>
> Thanks
> Cos
>
>> On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
>> Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
>> up the idea of automatically producing the package repos of the nightly
>> builds. With a few lines of shell we can do it as demonstrated in
>>
>> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
>> and
>> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
>>
>> Considering that we are dealing here with a matrix of OSes in this case, it
>> won't be perhaps ideal to roll this functionality into the main build. Keeping
>> it as an aux helper seems like a better idea.
>> There's of course disk-consumption issue, but we might be able to solve it.
>>
>> Thoughts?
>> Cos
>>
>>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
>>> Guys,
>>>
>>> I've been trying to replicate our CI elsewhere and here's a couple of
>>> observations and proposed fixes that might do such things easier in the
>>> future.
>>>
>>> 1. Running build as root inside of the docker container.
>>>
>>> This seems like a real issue, especially considering that we have always
>>> advocated to stay away from such practice. Unfortunately, adding
>>> -u jenkins:jenkins
>>> to docker run snags on a couple of points
>>>
>>> 2. Shared Gradle directory shouldn't belong to root, or at least should be
>>> writable for everyone.
>>>
>>> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
>>> confusions like BIGTOP-2184
>>>
>>> 3. One perhaps last issue here is the discrepancy between the user ids, where
>>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>>>
>>> I think with these three in place, we should be able to start using
>>> un-privileged user for the builds and also for the cluster testing.
>>>
>>> Thoughts?
>>> Cos
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On a slightly separate note (may be Jay knows the answer): I noticed that we
only have centos-6 and debian-8 deploy images. Is there any technical reason
for not making them (and limiting our ability to do automatic testing) or it
just never been implemented?
Thanks
Cos
On Fri, Dec 25, 2015 at 09:09PM, Konstantin Boudnik wrote:
> Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
> up the idea of automatically producing the package repos of the nightly
> builds. With a few lines of shell we can do it as demonstrated in
>
> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> and
> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
>
> Considering that we are dealing here with a matrix of OSes in this case, it
> won't be perhaps ideal to roll this functionality into the main build. Keeping
> it as an aux helper seems like a better idea.
> There's of course disk-consumption issue, but we might be able to solve it.
>
> Thoughts?
> Cos
>
> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> > Guys,
> >
> > I've been trying to replicate our CI elsewhere and here's a couple of
> > observations and proposed fixes that might do such things easier in the
> > future.
> >
> > 1. Running build as root inside of the docker container.
> >
> > This seems like a real issue, especially considering that we have always
> > advocated to stay away from such practice. Unfortunately, adding
> > -u jenkins:jenkins
> > to docker run snags on a couple of points
> >
> > 2. Shared Gradle directory shouldn't belong to root, or at least should be
> > writable for everyone.
> >
> > This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> > confusions like BIGTOP-2184
> >
> > 3. One perhaps last issue here is the discrepancy between the user ids, where
> > jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> >
> > I think with these three in place, we should be able to start using
> > un-privileged user for the builds and also for the cluster testing.
> >
> > Thoughts?
> > Cos
> >
> >
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Jay Vyas <ja...@gmail.com>.
Ah yes, that's perfect
> On Dec 26, 2015, at 4:32 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
>> On Sat, Dec 26, 2015 at 08:51AM, Jay Vyas wrote:
>> Makes sense. I think it's common to have to use these one off scripts when
>> dealing with Jenkins and daily build products and so on.
>>
>> Another project I'm working on has a hack/ directory for stuff like this
>> that can be easily commited into, for sharing these sorts of one off tasks.
>>
>> Maybe we should have one in bigtop and then you can dump these Jenkins
>> related workarounds in hack/?
>
> Actually, we have bigtop-ci which might work for this type of stuff. I will
> give the scripts a spin and if they're working for our satisfaction, I do a
> JIRA and commit them there.
>
> Thanks,
> Cos
>
>>> On Dec 26, 2015, at 12:09 AM, Konstantin Boudnik <co...@apache.org> wrote:
>>>
>>> Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
>>> up the idea of automatically producing the package repos of the nightly
>>> builds. With a few lines of shell we can do it as demonstrated in
>>>
>>> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
>>> and
>>> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
>>>
>>> Considering that we are dealing here with a matrix of OSes in this case, it
>>> won't be perhaps ideal to roll this functionality into the main build. Keeping
>>> it as an aux helper seems like a better idea.
>>> There's of course disk-consumption issue, but we might be able to solve it.
>>>
>>> Thoughts?
>>> Cos
>>>
>>>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
>>>> Guys,
>>>>
>>>> I've been trying to replicate our CI elsewhere and here's a couple of
>>>> observations and proposed fixes that might do such things easier in the
>>>> future.
>>>>
>>>> 1. Running build as root inside of the docker container.
>>>>
>>>> This seems like a real issue, especially considering that we have always
>>>> advocated to stay away from such practice. Unfortunately, adding
>>>> -u jenkins:jenkins
>>>> to docker run snags on a couple of points
>>>>
>>>> 2. Shared Gradle directory shouldn't belong to root, or at least should be
>>>> writable for everyone.
>>>>
>>>> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
>>>> confusions like BIGTOP-2184
>>>>
>>>> 3. One perhaps last issue here is the discrepancy between the user ids, where
>>>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>>>>
>>>> I think with these three in place, we should be able to start using
>>>> un-privileged user for the builds and also for the cluster testing.
>>>>
>>>> Thoughts?
>>>> Cos
>>>
>>>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
On Sat, Dec 26, 2015 at 08:51AM, Jay Vyas wrote:
> Makes sense. I think it's common to have to use these one off scripts when
> dealing with Jenkins and daily build products and so on.
>
> Another project I'm working on has a hack/ directory for stuff like this
> that can be easily commited into, for sharing these sorts of one off tasks.
>
> Maybe we should have one in bigtop and then you can dump these Jenkins
> related workarounds in hack/?
Actually, we have bigtop-ci which might work for this type of stuff. I will
give the scripts a spin and if they're working for our satisfaction, I do a
JIRA and commit them there.
Thanks,
Cos
> > On Dec 26, 2015, at 12:09 AM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
> > up the idea of automatically producing the package repos of the nightly
> > builds. With a few lines of shell we can do it as demonstrated in
> >
> > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> > and
> > https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
> >
> > Considering that we are dealing here with a matrix of OSes in this case, it
> > won't be perhaps ideal to roll this functionality into the main build. Keeping
> > it as an aux helper seems like a better idea.
> > There's of course disk-consumption issue, but we might be able to solve it.
> >
> > Thoughts?
> > Cos
> >
> >> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> >> Guys,
> >>
> >> I've been trying to replicate our CI elsewhere and here's a couple of
> >> observations and proposed fixes that might do such things easier in the
> >> future.
> >>
> >> 1. Running build as root inside of the docker container.
> >>
> >> This seems like a real issue, especially considering that we have always
> >> advocated to stay away from such practice. Unfortunately, adding
> >> -u jenkins:jenkins
> >> to docker run snags on a couple of points
> >>
> >> 2. Shared Gradle directory shouldn't belong to root, or at least should be
> >> writable for everyone.
> >>
> >> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> >> confusions like BIGTOP-2184
> >>
> >> 3. One perhaps last issue here is the discrepancy between the user ids, where
> >> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
> >>
> >> I think with these three in place, we should be able to start using
> >> un-privileged user for the builds and also for the cluster testing.
> >>
> >> Thoughts?
> >> Cos
> >
> >
Re: CI improvements [Was: The state of new CI]
Posted by Jay Vyas <ja...@gmail.com>.
Makes sense. I think it's common to have to use these one off scripts when dealing with Jenkins and daily build products and so on.
Another project I'm working on has a hack/ directory for stuff like this that can be easily commited into, for sharing these sorts of one off tasks.
Maybe we should have one in bigtop and then you can dump these Jenkins related workarounds in hack/?
> On Dec 26, 2015, at 12:09 AM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
> up the idea of automatically producing the package repos of the nightly
> builds. With a few lines of shell we can do it as demonstrated in
>
> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
> and
> https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
>
> Considering that we are dealing here with a matrix of OSes in this case, it
> won't be perhaps ideal to roll this functionality into the main build. Keeping
> it as an aux helper seems like a better idea.
> There's of course disk-consumption issue, but we might be able to solve it.
>
> Thoughts?
> Cos
>
>> On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
>> Guys,
>>
>> I've been trying to replicate our CI elsewhere and here's a couple of
>> observations and proposed fixes that might do such things easier in the
>> future.
>>
>> 1. Running build as root inside of the docker container.
>>
>> This seems like a real issue, especially considering that we have always
>> advocated to stay away from such practice. Unfortunately, adding
>> -u jenkins:jenkins
>> to docker run snags on a couple of points
>>
>> 2. Shared Gradle directory shouldn't belong to root, or at least should be
>> writable for everyone.
>>
>> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
>> confusions like BIGTOP-2184
>>
>> 3. One perhaps last issue here is the discrepancy between the user ids, where
>> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>>
>> I think with these three in place, we should be able to start using
>> un-privileged user for the builds and also for the cluster testing.
>>
>> Thoughts?
>> Cos
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
Moving a bit of the topics of pure polishing of rough edges, I wanted to bring
up the idea of automatically producing the package repos of the nightly
builds. With a few lines of shell we can do it as demonstrated in
https://github.com/c0s/dumb-ass-scripts/blob/master/gen-apt.sh
and
https://github.com/c0s/dumb-ass-scripts/blob/master/gen-yum.sh
Considering that we are dealing here with a matrix of OSes in this case, it
won't be perhaps ideal to roll this functionality into the main build. Keeping
it as an aux helper seems like a better idea.
There's of course disk-consumption issue, but we might be able to solve it.
Thoughts?
Cos
On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> Guys,
>
> I've been trying to replicate our CI elsewhere and here's a couple of
> observations and proposed fixes that might do such things easier in the
> future.
>
> 1. Running build as root inside of the docker container.
>
> This seems like a real issue, especially considering that we have always
> advocated to stay away from such practice. Unfortunately, adding
> -u jenkins:jenkins
> to docker run snags on a couple of points
>
> 2. Shared Gradle directory shouldn't belong to root, or at least should be
> writable for everyone.
>
> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> confusions like BIGTOP-2184
>
> 3. One perhaps last issue here is the discrepancy between the user ids, where
> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>
> I think with these three in place, we should be able to start using
> un-privileged user for the builds and also for the cluster testing.
>
> Thoughts?
> Cos
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Konstantin Boudnik <co...@apache.org>.
Actually, there's more into this. Mounting volumes from a host will always be
a subject to disrepancies between host's user uid/gio and ones inside of the
container. We still should go ahead at least with 2) and 3) in the short run.
Cos
On Wed, Dec 23, 2015 at 12:34PM, Konstantin Boudnik wrote:
> Guys,
>
> I've been trying to replicate our CI elsewhere and here's a couple of
> observations and proposed fixes that might do such things easier in the
> future.
>
> 1. Running build as root inside of the docker container.
>
> This seems like a real issue, especially considering that we have always
> advocated to stay away from such practice. Unfortunately, adding
> -u jenkins:jenkins
> to docker run snags on a couple of points
>
> 2. Shared Gradle directory shouldn't belong to root, or at least should be
> writable for everyone.
>
> This is covered in BIGTOP-2171 (appreciate the review) and has caused user
> confusions like BIGTOP-2184
>
> 3. One perhaps last issue here is the discrepancy between the user ids, where
> jenkins on centos and ubuntu have different UID (BIGTOP-2187)
>
> I think with these three in place, we should be able to start using
> un-privileged user for the builds and also for the cluster testing.
>
> Thoughts?
> Cos
>
>
Re: CI improvements [Was: The state of new CI]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Dec 23, 2015 at 12:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Guys,
>
> I've been trying to replicate our CI elsewhere and here's a couple of
> observations and proposed fixes that might do such things easier in the
> future.
>
> 1. Running build as root inside of the docker container.
>
> This seems like a real issue, especially considering that we have always
> advocated to stay away from such practice. Unfortunately, adding
> -u jenkins:jenkins
> to docker run snags on a couple of points
Can you elaborate on this?
Thanks,
Roman.