www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <andrew.ba...@gmail.com>
Subject Re: builds.apache.org suitability for Brooklyn integration tests
Date Thu, 18 Dec 2014 15:41:11 GMT
It's a label - "cloud-slave" will get you, well, a cloud slave. =)

A.

On Thu, Dec 18, 2014 at 7:06 AM, Richard Downer <richard@apache.org> wrote:
>
> Hi Andrew, all,
>
> I've taken a look at setting this up - I've found most of the options
> I need, but I'm not sure how to restrict the project to cloud slaves.
> Is this done by means of a special label, or some other option? Is it
> the "JClouds Instance Creation" option?
>
> The project is "incubator-brooklyn-master-integration" if anybody
> wants to poke it around.
>
> Thanks
> Richard.
>
> On 1 December 2014 at 17:15, Andrew Bayer <andrew.bayer@gmail.com> wrote:
> > So long as you don't need root, yeah, go merrily along on the cloud
> slaves
> > - they're restricted to a single executor, so you can't bust anything
> else
> > running on the slave at the same time, and if you're worried that you'll
> > make disruptive changes to future builds, you can check the "Single-Use
> > Slaves" option in your job config - when run on a cloud-provisioned
> slave,
> > that'll result in the slave being taken offline and destroyed after your
> > build completes.
> >
> > A.
> >
> > On Wed, Nov 26, 2014 at 2:12 AM, Richard Downer <richard@apache.org>
> wrote:
> >
> >> Hello builds@apache.org - and I assume that Andrew Bayer is somewhere
> >> behind this alias?
> >>
> >> I was at your talk at ApacheCon Europe last week and asked a question
> >> about if the Jenkins infrastructure would be able to manage the
> >> Brooklyn project's integration tests. I'd like to explore this in some
> >> more detail.
> >>
> >> Brooklyn's normal mode of operation is - amongst other things -
> >> installing and managing software. So its integration tests will be
> >> doing things like downloading Tomcat, installing it on the local
> >> machine by shelling out to bash, and starting it, where it would do
> >> things like open TCP network ports for listening. So it is doing a lot
> >> of work outside of the JVM sandbox. Repeat this for a couple of dozen
> >> types of software.
> >>
> >> Furthermore, if there's any issue with the code under test, it may not
> >> be able to clean up - in the worst case there would be processes left
> >> running, consuming memory, disk space and network ports.
> >>
> >> When Brooklyn entered the Incubator, we moved our unit tests and PR
> >> builder onto builds.apache.org, but we left the integration tests on
> >> other infrastructure as we assumed that the shared build slaves were
> >> not an appropriate place for "messy" tests like these. Instead, the
> >> infrastructure we use relies on cloud build slaves which are shutdown
> >> after the test run, therefore avoiding any cleanup issues.
> >>
> >> In the discussion at ApacheCon, you suggested that we could
> >> potentially restrict our integration test job to running on the cloud
> >> build slaves.
> >>
> >> What's the best way for us to move forward and run our integration
> >> tests on builds.apache.org?
> >>
> >> Thanks,
> >>
> >> Richard
> >> Committer/PPMC @ Apache Brooklyn (incubating)
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message