Re: [hibernate-dev] NoORM IRC meeting minutes

[Sanne Grinovero]

On 2 August 2017 at 13:28, Guillaume Smet  wrote:
> On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero  wrote:
>>
>> This might work for HV but please don't do this generally?
>> Concurrently running builds will fail because of conflicting resource
>> usage,
>> and we had plenty of cases in which some ports are needd which you
>> didn't even know about.
>
>
> At least for all the projects using our unified release scripts it shouldn't
> be an issue: we don't run the tests in the release process (you're supposed
> to check that all the CI jobs are green before releasing).
>
> It might still be an issue though if you start resources even if the tests
> are not running. Might be the case with OGM and Search.

Right, Search for example starts ES even if you skip tests (there's a
JIRA to improve on that).

But my point though is more about the unknowns: it's painful to figure
out such things after the fact so we need to be careful with such
jobs.

>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero  wrote:

> This might work for HV but please don't do this generally?
> Concurrently running builds will fail because of conflicting resource
> usage,
> and we had plenty of cases in which some ports are needd which you
> didn't even know about.
>

At least for all the projects using our unified release scripts it
shouldn't be an issue: we don't run the tests in the release process
(you're supposed to check that all the CI jobs are green before releasing).

It might still be an issue though if you start resources even if the tests
are not running. Might be the case with OGM and Search.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoORM IRC meeting minutes

[Sanne Grinovero]

On 2 August 2017 at 12:13, Guillaume Smet  wrote:
> The website jobs are not the only ones that need to be prioritized: the
> release jobs should also be prioritized.

Good point.

>
> When you do a release, it's really a pain to wait for all the other jobs to
> finish.
>
> Currently, I set a weight of 2 for the BV/HV release jobs so that they can
> also be prioritized.

This might work for HV but please don't do this generally?
Concurrently running builds will fail because of conflicting resource usage,
and we had plenty of cases in which some ports are needd which you
didn't even know about.

>
> No preference about the solution we choose, just wanted to mention it.
>
> On Wed, Aug 2, 2017 at 12:37 PM, Sanne Grinovero 
> wrote:
>>
>> Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":
>>
>> if it's too limiting +1 to remove this but please always allow a
>> website release to allow "right now", sometimes it's really urgent and
>> even waiting a couple of fast jobs is very stressful.
>>
>> A simple solution - and actually how it used to be in the very
>> beginning - is to configure all website jobs to run on the master
>> node, and no other jobs to allow running on the master node.
>> Incidentally this simplifies security as this implies the website
>> build doesn't have to be rsynced from the slaves, as it's being hosted
>> from this same machine.
>>
>> The reason we changed this was that some more jobs were requiring to
>> run on AWS, like some ORM tests needing to access the RDS hosted
>> Oracle databases. With more slaves running on AWS now, that reason is
>> no longer valid so we could return to the situation in which the
>> master node is dedicated for website and super-light jobs exclusively.
>>
>> In most cases the reason to avoid one slave to run two (or more) full
>> integration tests in parallel was isolation problems, from TCP port
>> usage to using each other's local database; we could try Docker again
>> if someone is willing to spend some time on such research, but bear in
>> mind it's not suited for all our jobs - for example some need to run
>> performance sensitive tasks, some others just don't have enough
>> physical memory to run two jobs concurrently so we still need some
>> form of coordination to avoid running multiple jobs on the same
>> machine.
>>
>> Incidentally our "master node" was also scaled to a slightly higher
>> machine class to be able to run those ORM tests (more RAM in
>> particular); if we pick the simple road of having it build the
>> websites at most, we could re-scale it down again.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 1 August 2017 at 22:16, Guillaume Smet 
>> wrote:
>> > Hi!
>> >
>> > Here are the minutes of today's NoORM meeting:
>> >
>> > 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
>> > about MeetBot at
>> >http://wiki.debian.org/MeetBot . (v 0.1.4)
>> > 15:48 < jbott> Minutes:
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
>> > 15:48 < jbott> Minutes (text):
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
>> > 15:48 < jbott> Log:
>> >
>> > http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
>> >
>> > Cheers,
>> >
>> > --
>> > Guillaume
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

The website jobs are not the only ones that need to be prioritized: the
release jobs should also be prioritized.

When you do a release, it's really a pain to wait for all the other jobs to
finish.

Currently, I set a weight of 2 for the BV/HV release jobs so that they can
also be prioritized.

No preference about the solution we choose, just wanted to mention it.

On Wed, Aug 2, 2017 at 12:37 PM, Sanne Grinovero 
wrote:

> Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":
>
> if it's too limiting +1 to remove this but please always allow a
> website release to allow "right now", sometimes it's really urgent and
> even waiting a couple of fast jobs is very stressful.
>
> A simple solution - and actually how it used to be in the very
> beginning - is to configure all website jobs to run on the master
> node, and no other jobs to allow running on the master node.
> Incidentally this simplifies security as this implies the website
> build doesn't have to be rsynced from the slaves, as it's being hosted
> from this same machine.
>
> The reason we changed this was that some more jobs were requiring to
> run on AWS, like some ORM tests needing to access the RDS hosted
> Oracle databases. With more slaves running on AWS now, that reason is
> no longer valid so we could return to the situation in which the
> master node is dedicated for website and super-light jobs exclusively.
>
> In most cases the reason to avoid one slave to run two (or more) full
> integration tests in parallel was isolation problems, from TCP port
> usage to using each other's local database; we could try Docker again
> if someone is willing to spend some time on such research, but bear in
> mind it's not suited for all our jobs - for example some need to run
> performance sensitive tasks, some others just don't have enough
> physical memory to run two jobs concurrently so we still need some
> form of coordination to avoid running multiple jobs on the same
> machine.
>
> Incidentally our "master node" was also scaled to a slightly higher
> machine class to be able to run those ORM tests (more RAM in
> particular); if we pick the simple road of having it build the
> websites at most, we could re-scale it down again.
>
> Thanks,
> Sanne
>
>
>
> On 1 August 2017 at 22:16, Guillaume Smet 
> wrote:
> > Hi!
> >
> > Here are the minutes of today's NoORM meeting:
> >
> > 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
> > about MeetBot at
> >http://wiki.debian.org/MeetBot . (v 0.1.4)
> > 15:48 < jbott> Minutes:
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
> > 15:48 < jbott> Minutes (text):
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
> > 15:48 < jbott> Log:
> > http://transcripts.jboss.org/meeting/irc.freenode.org/
> hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
> >
> > Cheers,
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoORM IRC meeting minutes

[Sanne Grinovero]

Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":

if it's too limiting +1 to remove this but please always allow a
website release to allow "right now", sometimes it's really urgent and
even waiting a couple of fast jobs is very stressful.

A simple solution - and actually how it used to be in the very
beginning - is to configure all website jobs to run on the master
node, and no other jobs to allow running on the master node.
Incidentally this simplifies security as this implies the website
build doesn't have to be rsynced from the slaves, as it's being hosted
from this same machine.

The reason we changed this was that some more jobs were requiring to
run on AWS, like some ORM tests needing to access the RDS hosted
Oracle databases. With more slaves running on AWS now, that reason is
no longer valid so we could return to the situation in which the
master node is dedicated for website and super-light jobs exclusively.

In most cases the reason to avoid one slave to run two (or more) full
integration tests in parallel was isolation problems, from TCP port
usage to using each other's local database; we could try Docker again
if someone is willing to spend some time on such research, but bear in
mind it's not suited for all our jobs - for example some need to run
performance sensitive tasks, some others just don't have enough
physical memory to run two jobs concurrently so we still need some
form of coordination to avoid running multiple jobs on the same
machine.

Incidentally our "master node" was also scaled to a slightly higher
machine class to be able to run those ORM tests (more RAM in
particular); if we pick the simple road of having it build the
websites at most, we could re-scale it down again.

Thanks,
Sanne



On 1 August 2017 at 22:16, Guillaume Smet  wrote:
> Hi!
>
> Here are the minutes of today's NoORM meeting:
>
> 15:48 < jbott> Meeting ended Tue Aug  1 13:48:33 2017 UTC.  Information
> about MeetBot at
>http://wiki.debian.org/MeetBot . (v 0.1.4)
> 15:48 < jbott> Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.html
> 15:48 < jbott> Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.txt
> 15:48 < jbott> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-08-01-13.00.log.html
>
> Cheers,
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev