Re: [Pulp-dev] Pulp Installers Team Meeting Minutes 2020-09-09

[Robin Chan]

On Wed, Sep 9, 2020 at 1:19 PM Mike DePaulo  wrote:

> September 9th Agenda
>
>- [mikedep333] I want to say that the rest of the subteam was right
>about something from ~3 months ago. It was best not to create a branch
>supporting CI for pulp_installer. The effort would not have paid off.
>
> [rchan] Really love seeing this type of reflection on decisions. It's so
hard to decide if something is worth doing, especially in a tool like this.


>- We cannot run CentOS 8 molecule containers on our Fedora 32 systems
>right now. service/systemd module fails:
>   - https://bugzilla.redhat.com/show_bug.cgi?id=1853407
>   - https://bugzilla.redhat.com/show_bug.cgi?id=1853736#c8
>   - switching to systemd module does not help
>   - Can we ask RHEL8 for a fix?
>   - agreed: Just run molecule on a VM
>- CI is red on source-upgrade: https://pulp.plan.io/issues/7479
>   - try pipdeptree
>   - try
>   
> https://github.com/pulp/pulp-oci-images/commit/755fa0f816bfac40fbf97f2dc2ca8fa5d6a6c873#diff-ef37552d3bc0dec828902c8331d481c7R10
>- What is needed from the installer to support smooth roll out of
>https://github.com/pulp/pulpcore/pull/799 ?
>   - Created installer subtask.
>- how docker changes can affect us? (Free plan – anonymous users: 100
>pulls per 6 hours ) -
>
> https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/
>   - agreed: This will probably break many projects, so they might
>   revert. Travis/GHA may also have a cache. So let’s address this later. 
> We
>   can consider Quay if it is more reliable then.
>- How Mike responded to the user email about RPMs install
>   - Team thinks it was good to spend time investigating, for the
>   user’s sake, for the sake of other users, and to look into the 
> underlying
>   issues (we want to find out about them early in CI, not when users 
> report.)
>
>
>
> --
>
> 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
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp Installers Team Meeting Minutes 2020-09-09

[Mike DePaulo]

September 9th Agenda

   - [mikedep333] I want to say that the rest of the subteam was right
   about something from ~3 months ago. It was best not to create a branch
   supporting CI for pulp_installer. The effort would not have paid off.
   - We cannot run CentOS 8 molecule containers on our Fedora 32 systems
   right now. service/systemd module fails:
  - https://bugzilla.redhat.com/show_bug.cgi?id=1853407
  - https://bugzilla.redhat.com/show_bug.cgi?id=1853736#c8
  - switching to systemd module does not help
  - Can we ask RHEL8 for a fix?
  - agreed: Just run molecule on a VM
   - CI is red on source-upgrade: https://pulp.plan.io/issues/7479
  - try pipdeptree
  - try
  
https://github.com/pulp/pulp-oci-images/commit/755fa0f816bfac40fbf97f2dc2ca8fa5d6a6c873#diff-ef37552d3bc0dec828902c8331d481c7R10
   - What is needed from the installer to support smooth roll out of
   https://github.com/pulp/pulpcore/pull/799 ?
  - Created installer subtask.
   - how docker changes can affect us? (Free plan – anonymous users: 100
   pulls per 6 hours ) -
   
https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/
  - agreed: This will probably break many projects, so they might
  revert. Travis/GHA may also have a cache. So let’s address this later. We
  can consider Quay if it is more reliable then.
   - How Mike responded to the user email about RPMs install
  - Team thinks it was good to spend time investigating, for the user’s
  sake, for the sake of other users, and to look into the underlying issues
  (we want to find out about them early in CI, not when users report.)



-- 

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

[Pulp-dev] Katello/pulp 3 integration scrum notes

[Brian Bouterse]

Note, next week's meeting is cancelled due to Pulpcon conflict. This was
discussed with Katello on today's call.


September 9, 2020

Pulp

   -

   Pulpcore
   -

  Dalley - Working on tasking bugs (stuck tasks, etc.) and slow orphan
  cleanup
  -

 Have been on the sprint for several sprints :(
 -

 Expected to come out with 3.7 on Sept 22nd
 -

  Pulpcore discussed shipping migrations in z-stream on Sept 4th open
  floor
  -

 General consensus is that pulpcore cannot
 -

 A mailing list discussion will probably happen also, not yet sent
 -

  SELinux EL7 and EL8 policies expected to be included in pulpcore 3.7
  -

  FIPS support to be included in pulpcore 3.7
  -

 https://pulp.plan.io/issues/5216
 -

https://github.com/pulp/pulpcore/pull/894
-

   Container
   -

  2.0.1 released yesterday. Includes a fix for the 403 responses when
  deployed behind an HTTPS proxy.
  -

   RPM
   -

  3.6.2 was GA on Sept 4th
  -

 https://pulp-rpm.readthedocs.io/en/3.6/changes.html#id1
 -

   Pulpcon Sept 14th - 18th
   -

  https://hackmd.io/@pulp/pulpcon2020_schedule


Katello

   -

   Pulpcore 3.6  with all fixes now running through pipeline, hopefully no
   more issues
   -

   Added support for sles auth token
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] [CentOS-devel] repo_gpgcheck for centos repos?

[Dennis Kliban]

At this time Pulp always regenerates the repo metadata. In Pulp 3, we plan
to add the ability to mirror the metadata. However, the development of that
feature has not started yet.

On Tue, Sep 8, 2020 at 3:02 PM James Cassell 
wrote:

>
> On Tue, Sep 8, 2020, at 11:12 AM, Neal Gompa wrote:
> > On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson  wrote:
> > >
> > > While we want signed repodata to be *available* to folks who want to
> enable it, We don’t want it necessarily to be the default for all users. We
> want it to be a decision that folks make for their own sites.
> > >
> >
> > This is a very bizarre stance to take. Enabling repo_gpgcheck for
> > the CentOS provided repos in their repo files should not harm anything
> > else, and only further ensures the integrity of the repository
> > content.
> >
> > Is there a compelling reason to *not* change the defaults? Because
> > from my perspective, I don't see any.
> >
>
> The only reason might be to prevent breaking folks who regenerate the
> repomd locally. Not sure whether pulp preserves the original md or
> regenerates its own. (I always use exactly the upstream repomd for
> precisely this reason of avoiding breaking repo_gpgcheck, which is often on
> "security hardening" checklists.)
>
> V/r,
> James Cassell
>
>
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > CentOS-devel mailing list
> > centos-de...@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
> >
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev