On 2 August 2017 at 12:13, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
The website jobs are not the only ones that need to be prioritized:
release jobs should also be prioritized.
When you do a release, it's really a pain to wait for all the other jobs to
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 <sanne(a)hibernate.org>
> 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
> 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.
> On 1 August 2017 at 22:16, Guillaume Smet <guillaume.smet(a)gmail.com>
> > 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:
> > 15:48 < jbott> Minutes (text):
> > 15:48 < jbott> Log:
> > Cheers,
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> hibernate-dev mailing list