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 <sa...@hibernate.org> 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 <guillaume.s...@gmail.com> > 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