builds.apache.org suitability for Brooklyn integration tests

[Richard Downer <ri...@apache.org>]

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)

Re: builds.apache.org suitability for Brooklyn integration tests

[Gavin McDonald <ga...@16degrees.com.au>]

On 26/11/2014, at 10:12 AM, Richard Downer <ri...@apache.org> wrote:

> Hello builds@apache.org - and I assume that Andrew Bayer is somewhere
> behind this alias?

This is a proper mailing list, not an alias.

Yes Andrew is subscribed to this mailing list -- as are other Jenkins Admins 
who may also be able to assist, please do not direct your questions to one
person, that does not scale well in the end.

Gav…


> 
> 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)

Re: builds.apache.org suitability for Brooklyn integration tests

[Richard Downer <ri...@apache.org>]

Thanks! I've set up the job now. Thanks for your assistance.

Richard.

On 18 December 2014 at 15:41, Andrew Bayer <an...@gmail.com> wrote:
> 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 <ri...@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 <an...@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 <ri...@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)
>> >>
>>

Re: builds.apache.org suitability for Brooklyn integration tests

[Andrew Bayer <an...@gmail.com>]

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 <ri...@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 <an...@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 <ri...@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)
> >>
>

Re: builds.apache.org suitability for Brooklyn integration tests

[Richard Downer <ri...@apache.org>]

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 <an...@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 <ri...@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)
>>

Re: builds.apache.org suitability for Brooklyn integration tests

[Andrew Bayer <an...@gmail.com>]

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 <ri...@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)
>