[Pulp-dev] Artifact upload recovery workflows

2020-12-09 Thread Ina Panova 
Hey folks,
we had a meeting today about how to manage missing or corrupted files
during  the upload process and have captured some ideas on this issue
https://pulp.plan.io/issues/7791

Please review and provide feedback directly on the ticket.
Thank you!

Regards,

Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Katello/Pulp3 Integration mtg

2020-12-09 Thread Grant Gainey 
December 09, 2020

Overview

   -

   Katello Schedule
   -

  3.18 branching:  Nov 2nd, Targeting Pulp 3.7
  -

  4.0 branching ~February 2021 (dry-run needed by end-of-Dec)
  -

  4.1 branching ~May 2021
  -

  4.2 branching ~August 2021
  -

  4.3 branching ~Nov 2021


Pulp

   -

   Pulpcore
   -

  3.9 released 7-DEC
  -

 https://docs.pulpproject.org/pulpcore/changes.html#id1
 -

 Correlation id https://pulp.plan.io/issues/7792
 -

 Progress reporting for importing https://pulp.plan.io/issues/6559
 -

 Handle-artifact-checksums command https://pulp.plan.io/issues/7561
 -

 Pulp_container needs a compatibility release due to a bug fix
 -

  Object-labelling design
   under review
  -

  FIPS requirements https://hackmd.io/KzcCx9ZZR26kvQqJYp46GQ?view
  -

 Katello ok with requirements
 -

   RPM
   -

  “No sqlite” and “relative path” (metadata mirroring) will be worked
  in Q1
  -

   Migration
   -

  0.6.0 is out
  -

  Tests
  -

  Correctness of re-runs and pulp 2.21.5
  -

   Ansible
   -

  Import/export is outstanding https://pulp.plan.io/issues/6738
  -

  Anything else? (e.g. https://pulp.plan.io/issues/5238 ?)
  -

  Aimed at katello-4.1


Katello

   -

   Migration Progress reporting was merged
   -

   Container registry work continuing
   -

   Will look to move to pulpcore-3.9 this sprint
   -

   https://pulp.plan.io/issues/7923  no longing


QE

   -

   3.18 ques: can we run pre-migration cmds yet?
   -

  Pulp3 not in latest snap, being worked on
  -

  Jsherrill will work w/ltran if/as needed


G
-- 
Grant Gainey
Principal Software Engineer, Red Hat System Management Engineering
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Re-enable required status checks

2020-12-09 Thread David Davis 
When we stopped using Travis, I disabled the required status checks in
Github for pull requests. To re-enable these required status checks, visit
the branch protection settings page for your plugin's repo. Configure a
branch protection rule and there should be a setting to require status
checks.

David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

2020-12-09 Thread 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 

IM: mikedep333

GPG: 51745404

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev