<div dir="ltr">## December 9 Agenda * Older issues still at modified. No milestone set. * <a href="https://pulp.plan.io/issues/7804">https://pulp.plan.io/issues/7804</a> * <a href="https://pulp.plan.io/issues/7234">https://pulp.plan.io/issues/7234</a> * <a href="https://pulp.plan.io/issues/7780">https://pulp.plan.io/issues/7780</a> * <a href="https://pulp.plan.io/issues/7746">https://pulp.plan.io/issues/7746</a> * <a href="https://pulp.plan.io/issues/7107">https://pulp.plan.io/issues/7107</a> * <a href="https://pulp.plan.io/issues/7155">https://pulp.plan.io/issues/7155</a> * <a href="https://pulp.plan.io/issues/7798">https://pulp.plan.io/issues/7798</a> * <a href="https://pulp.plan.io/issues/6753">https://pulp.plan.io/issues/6753</a> * Releasing doc doesn't mention updating redmine * <a href="https://github.com/pulp/pulp_installer/blob/master/RELEASING.md">https://github.com/pulp/pulp_installer/blob/master/RELEASING.md</a> * agreed * Release process is somewhat painful * e.g. having to manually close out issues and assign them to the correct milestone * Maybe worth automating? * <a href="https://pulp.plan.io/issues/7961">https://pulp.plan.io/issues/7961</a> * pulpcore version x pulp_installer version: use template docs/index.md.j2? * Continuous Release "with every commit"? * Versions like 3.8.1-1-dev-20201209123456 * pretty similar to nightly.yml from pulp plugins * [spredzy] to make a writeup for pulp-dev ML * FIPS/SELinux CI Approaches * [Qemu Emulation on GHA](<a href="https://github.com/pulp/pulp_installer/pull/503">https://github.com/pulp/pulp_installer/pull/503</a>) * 100 min runtime per job * Given a matrix of centos7 vs centos8, master branch of pulpcore/plugins vs releases, and fips vs selinux * we could do 2 of those tests, with the opposite set of options * we could also do FIPS & SELinux in the same test, most users with FIPS also have SELinux enabled * No security implications * No management overhead * Agreed: This approach. Which tests to run at PR time is TBD, but definitely for cron. * persistent server from QE * Possibly only 1 job at a time * High security implications * Moderate management overhead * Agreed: Tell them we'll follow up in a week as we pursue Qemu emulation * using a cloud provider w/ ephemeral instances (from GHA runner w/ a cloud provider vagrant plugin) * Moderate security implications * Little management overhead * <a href="https://github.com/pulp/pulp_installer/pull/495">https://github.com/pulp/pulp_installer/pull/495</a> * can we safely rename variables we never advertised to exist? * 1 or 2 users (from the ML, told to use them with a warning) will probably be broke -- <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mike DePauloHe / Him / HisService Reliability Engineer, Pulp<a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat</a><div style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:medium;margin-bottom:4px"></div>IM: mikedep333GPG: 51745404<div style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:medium;margin-top:12px"><table border="0"><tbody><tr><td width="100px"><a href="https://www.redhat.com/" target="_blank"><img src="https://marketing-outfit-prod-images.s3-us-west-2.amazonaws.com/f5445ae0c9ddafd5b2f1836854d7416a/Logo-RedHat-Email.png" width="90" height="auto"></a></td></tr></tbody></table></div></div></div></div>