The Document Foundation Redmine: Issueshttps://redmine.documentfoundation.org/https://redmine.documentfoundation.org/favicon.ico?16960560022021-09-29T11:35:06ZThe Document Foundation Redmine
Redmine Infrastructure - Task #3544 (New): please deploy the unreleased Sorting Hat (branch 'muggle') wit...https://redmine.documentfoundation.org/issues/35442021-09-29T11:35:06ZMarina Latini
<p>As per subject and discussion via e-mail, I would like to ask to the infra team to deploy the unreleased Sorting Hat (branch 'muggle') with TDF data.</p>
<p>This staging deployment will be used by the MC for evaluating if "Sorting Hat" provides the information needed by the MC while evaluating new membership applications or renewals.</p>
<p>@Florian: assigning it to you for defining when the infra team will be tasked to work on this topic.</p> Infrastructure - Task #3442 (Feedback): rename "master" branch in core.git to new git defaulthttps://redmine.documentfoundation.org/issues/34422021-01-14T16:22:20ZMichael Stahl
<p>as discussed in ESC today:</p>
<ul>
<li>rename master to main in git? (Stephan)<br /> + LLVM already did this<br /> + how far should we go there? (Cloph)<br /> + do we look bad if we don’t do anything? (Stephan)<br /> + when creating a new branch: (Cloph)<br /> + IRC notify, tinderbox, .gitreview, documentation (wiki e.g.) (Sophie)<br /> + dashboard data may be tricky (Cloph)<br /> + in favor of doing it (Michael S)<br />AI: + file a TDF infra ticket on redmine (Michael S)<br /> + to get input from infra<br /> + prefer to get 7.1 out of the door first (Cloph)</li>
</ul>
<p>so this mainly requires adapting infra things like CI etc. to the new branch name, but hopefully the effort required should be rather small (and of course it's not the most urgent task in the world).</p>
<p>for motivation see:<br /><a class="external" href="https://tools.ietf.org/html/draft-knodel-terminology-02">https://tools.ietf.org/html/draft-knodel-terminology-02</a><br /><a class="external" href="https://github.com/github/renaming">https://github.com/github/renaming</a></p> Infrastructure - Task #3262 (New): make gimli (crashreports) more backup-friendlyhttps://redmine.documentfoundation.org/issues/32622020-07-13T14:57:53ZChristian Lohmaiercloph@documentfoundation.org
<p>gimli's backup is over 15 Million files, biggest chunk of that are static/non-changing logfiles from crashreport runs.<br />There is no point in hardlinking those 15 million files over and over, more efficient would be to backup archives (tarball/zip) of those runs with all logs in a single file and ignore the webdirectory with the extracted files.</p>
<p>Biggest problem with current setup is that a backup run doesn't complete within a single day, and of course it causes unnecessary I/O load on the VM as well.</p> Infrastructure - Task #3053 (New): add monitoring for daily builders that are AWOLhttps://redmine.documentfoundation.org/issues/30532019-12-06T10:27:20ZChristian Lohmaiercloph@documentfoundation.org
<p>From time to time the tinderbox build can get stuck for one reason or the other, and the first time we notice if when a user complains about not finding up-to-date builds…</p> Infrastructure - Task #3038 (New): smart queueing plugin for jenkins that takes buildtime/slow bu...https://redmine.documentfoundation.org/issues/30382019-11-26T13:38:44ZChristian Lohmaiercloph@documentfoundation.org
<p><strong>Overall picture:</strong><br />LibreOffice uses multijobs to verify gerrit changesets, consisting of Windows, Mac and 2 linux builds<br />Of those the Windows are the ones taking the longest and don't differ between build machines. They take around 1h to complete. The macs mostly are uniformly fast, with around 20-30min for a build, but there are outliers with slow bots where a build can take 90 to 120 minutes (those bots typically do tinderbox builds where that doesn't matter). For linux, the always-on-hosts are also uniformly fast, with around 20-30 minutes per build. In recent weeks the number of workers couldn't keep up with peak loads though, so Amazon EC2 and Hetzner cloud workers were examined as a way to cope with many builds submitted at once.</p>
<p><strong>The Problem:</strong><br />Jenkins scheduling is "dumb" - when it runs out of fast workers, it will assign jobs to the slow workers in a FIFO fashion, that results in unnecessary delays for a multijob's completion.<br />For example: A job has Windows and Mac and gcc builds already done (so it has been in active queue for at least 60min already, the minimum achievable with the Windows jobs) but all clang workers are busy, Jenkins will then happily use a slow worker that can take way over an hour instead of assigning the worker to a job from the queue where windows build wasn't started/didn't complete yet. If it waited for one of the current busy workers to complete their current job, the job would only have to wait 40min for completion in worst case (if builds on busy workers did just start, they take 20min to complete that, and then are free to accept the job that would take another 20min to complete)</p>
<strong>The Solution:</strong><br />A queue-extension needs to be written that is aware of the connection between the builds and the speed of the individual builders (determined by e.g. a label on the node). For sake of simplicitly assume slow builders are more than twice as slow as the regular builders:
<ul>
<li>it would be faster to wait for one the fast workers to complete their current job and build the waiting job than to start the build on the slow node.<br /> thus never use the slow worker for the first <number of fast workers> jobs in the queue</li>
<li>also for the next jobs waiting in queue: prefer one where the minimum-time-worker has not been started yet/is building for the shortest amount of time<br /> in the time it takes for the slow worker, the fast workers can clear a queue of 2x<number-of-fast-workers> and the situation where it would have been faster overall to not use the slow worker at all is avoided/the penalty of additional build time due to the slow worker is minimized.</li>
</ul> Design - Task #2907 (In Progress): Websites redesignhttps://redmine.documentfoundation.org/issues/29072019-06-20T11:04:37ZHeiko Tietzeheiko.tietze@documentfoundation.org
<p>Start site is outdated, boring, and not transporting the community idea<br />Ideally we have a recognizable look and feel but a clear distinction between LibreOffice and TDF<br />Sub sites should be clearly related by same look and feel</p> Design - Task #2903 (In Progress): Rebranding of LibreOffice/TDF and new websitehttps://redmine.documentfoundation.org/issues/29032019-06-20T10:53:48ZHeiko Tietzeheiko.tietze@documentfoundation.orgInfrastructure - Task #2841 (In Progress): Translate the new extensions sitehttps://redmine.documentfoundation.org/issues/28412019-03-22T11:11:00ZHeiko Tietzeheiko.tietze@documentfoundation.org
<p>Depends on the status of po integration (unclear at this time)</p> Infrastructure - Task #2609 (New): Review and improve admins' operational security “best practices”https://redmine.documentfoundation.org/issues/26092018-05-02T10:07:41ZGuilhem Moulinguilhem@libreoffice.org
<p>From Message-ID: <<a class="email" href="mailto:20180501214904.kgsqsijdgqygb2vh@thinkpad.thebehrens.net">20180501214904.kgsqsijdgqygb2vh@thinkpad.thebehrens.net</a>> and follow-ups, sent to the tdf-admin list:</p>
<blockquote><blockquote><blockquote>
<p>However, we admin have <strong>zero excuse</strong> to use weak (aka brute-forceable) passwords.</p>
</blockquote>
<p>Right. And with the overall cleanup / consolidation we're doing, some amount of enforcement / express self-commitment from the admins should be in order?</p>
</blockquote>
<p>Perhaps we could discuss, share knowledge, learn from each other, and later draft a couple of “best practices” to be signed by all current and future admins?</p>
</blockquote>
<p>We can use this ticket for the discussion.</p>