[Pulp-dev] Pulp Installer(s) Team Meeting Minutes 2020-12-09

[Mike DePaulo]

## December 9 Agenda
* Older issues still at modified. No milestone set.
    * https://pulp.plan.io/issues/7804
    * https://pulp.plan.io/issues/7234
    * https://pulp.plan.io/issues/7780
    * https://pulp.plan.io/issues/7746
    * https://pulp.plan.io/issues/7107
    * https://pulp.plan.io/issues/7155
    * https://pulp.plan.io/issues/7798
    * https://pulp.plan.io/issues/6753
* Releasing doc doesn't mention updating redmine
    * https://github.com/pulp/pulp_installer/blob/master/RELEASING.md
    * agreed
* Release process is somewhat painful
    * e.g. having to manually close out issues and assign them to the
correct milestone
    * Maybe worth automating?
        * https://pulp.plan.io/issues/7961
        * 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](
https://github.com/pulp/pulp_installer/pull/503)
        * 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
* https://github.com/pulp/pulp_installer/pull/495
    * 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

-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat <https://www.redhat.com/>

IM: mikedep333

GPG: 51745404
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20201209/b0bf1674/attachment.htm>