[Pulp-dev] Katello/Pulp3 Integration mtg

[Grant Gainey]

January 13, 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.10 scheduled for January 26
  -

 Will include https://pulp.plan.io/issues/7549
 -

   RPM
   -

  No update
  -

  metadata-mirroring/relative-path is prob not going to happen in 3.10
  -

   Migration
   -

  Customer testing and katello 4.0?
  -

 QE should be ready to test migration with the most recent snap
 -

  Pulp_deb
  -

 Some of migration’s assumptions may be clashing with debian
 data-models
 -

  Removal of migration plugin?
  -

 Make sure there’s a bug filed?
 -

 Current issue in pulpcore is to remove plugin generally
 -

 There is foreman-cmd-work for removing pulp2 info that could be
 used for this
 -

   Pulp 2.21.5
   -

  Release in flight, GA planned for January 25
  -

  https://pulp.plan.io/projects/pulp/wiki/2215_Release_Schedule
  -

  List of issues : https://pulp.plan.io/issues?query_id=167


Katello

   -

   Smart Proxy container gateway work
   -

   User migration testing continuing
   -

   Pulling in 3.9 for katello 4.0
   -

   Dropping pulp2 for katello 4.0


QE

   -

   Progress, waiting on an image rebuild


-- 
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] Pulp Installers Team Meeting minutes 2021-01-13

[Mike DePaulo]

## January 13 Agenda
* What was the previously proposed layer for the operator to take RWO
storage and convert to RWM or S3?
* [dkliban] Rook
* Need someone to join pulp-operator / galaxy_ng meeting next week
(chouseknecht's)
* fao89 is already joining.
* fao89 will be mentored by Mike on containers / k8s / operator
concepts as he makes changes
* See ["Introduction to pulp-operator"](
http://people.redhat.com/mdepaulo/presentations/Introduction%20to%20pulp-operator.pdf)
slides from pulpcon 2019
* Particularly note the ground-up explanation of layers: containers
-> k8s -> operator
* pulp-operator on github actions
* works when running at master, but fails to deploy as images are built
with podman and CI tries to push with docker -
https://github.com/pulp/pulp-operator/pull/60
* approved
* insta demo fails on PRs (failing to get remote/branch from upstream)
https://github.com/pulp/pulp-operator/pull/59/commits/0b6e5210f055731e5f64ecfb69c8e5de9861c8b2
* finish review post-meeting
* Performance issue [#8055](https://pulp.plan.io/issues/8055)
* We could selectively rework the handlers into smaller ones, and
trigger the smaller handlers, and only when needed.
* For example The task "Create configuration directory for Pulp" need
not trigger the entire big handlers "Restore SELinux contexts on Pulp dirs
that must exist"
* We could do the Pulp 2 approach: Version pulp_installer with the
SELinux policies, and run selective relabel tasks depending on what we're
upgrading to and from
* This would involve submodules or putting it in the pulp_installer
repo, ties into [#7575](https://pulp.plan.io/issues/7575)

-- 

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] pulpcore 3.10.0 release timeline & go/no-go irc meeting

[Tanya Tereshchenko]

Here's the tracker for the pulpcore 3.10.0 release:
https://pulp.plan.io/issues/8087
The tentative GA date is January 26th.

The first go/no-go meeting will happen in #pulp-meeting at the time below:

January 19, 3:00 PM UTC/January 19, 10:00 AM ET
https://everytimezone.com/s/f7b5af77
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Backports and LTS

[Dennis Kliban]

+1 to fully automating the release pipeline. This would allow us to do as
many releases as needed to satisfy all stakeholders.

On Tue, Jan 12, 2021 at 4:11 PM David Davis  wrote:

> There are some great features that have been added to Github Actions--one
> of them being manual triggers for workflows (before we weren't sure how we
> could trigger the entire release process). So I think we're in a good
> position now that we're on Github Actions to automate the rest of the
> release process.
>
> The problem is finding the time. I think we're all spread thin and we're
> talking about a week or two...? I would love to see this happen though as I
> think it would pay for itself after a couple releases.
>
> David
>
>
> On Tue, Jan 12, 2021 at 3:48 PM Brian Bouterse 
> wrote:
>
>> Stakeholder's won't agree on a single "LTS" (agreed daniel that's not a
>> great name for it) so I think option 3 is a non-starter. Option 2 is what
>> we do today and I agree it has the issues already mentioned.
>>
>> So +1 to option 1, but as already mentioned, practically speaking, I
>> believe we can't release any more than we are without fully automating the
>> process. Can we fully automate the release process first, and then
>> re-discuss a policy change after?
>>
>>
>>
>> On Wed, Jan 6, 2021 at 12:12 PM Daniel Alley  wrote:
>>
>>> Matt, that is a good observation and meanwhile with pulp2 we had such a
 policy, we cannot adopt it with pulp3. Release fast and release often is
 something we are trying to stick to.

>>>
>>> I don't think Matt was suggesting in any way that we not release fast
>>> and often, it's just that we have to pick a combination of cadance and # of
>>> supported releases that works for everyone.  This is basically Option 1
>>> with a pre-determined number of supported releases (rather than "backport
>>> to whatever version the stakeholder is using + all the others in between"
>>> which is how I interpret Option 1).
>>>
>>> I totally agree with David that it would be a pain to manage without
>>> automation though, same as Option 1.
>>>
>>> I think what would most likely happen under that plan is that we would
>>> see each stakeholder will take a release, stick to it until it is about to
>>> be dropped and then upgrade to the newest one, which is roughly the same as
>>> the LTS plan except that each stakeholder can choose their own "LTS"
>>> version and they could do an mid-cycle upgrade if there was ever a good
>>> reason to.
>>>
>>> Whatever option we choose, I'm kind of negative about actually using the
>>> term "LTS" given that I don't think we'd be supporting any version for more
>>> than 5-7 months.  The timeframe is a bit short for how the LTS moniker is
>>> typically used.
>>>
>>> On Wed, Jan 6, 2021 at 8:58 AM Ina Panova  wrote:
>>>
 Matt, that is a good observation and meanwhile with pulp2 we had such a
 policy, we cannot adopt it with pulp3. Release fast and release often is
 something we are trying to stick to.

 It would be best to agree on the LTS version that would make all the
 stakeholders happy but as it was pointed out not sure how we'd make this
 possible, everyone has a different pace and release cycle.
 Having that said, we should probably stick to option1 which puts more
 burden on us but in return users and stakeholders are happy and the
 project's upgrade path is stable.
 One thing we could possibly do about the backport requests is to really
 be thorough about which ones to accept by assessing the impact of the
 stakeholder who has created the request and their possibility to upgrade if
 any.
 
 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."


 On Wed, Jan 6, 2021 at 2:18 PM Matt Pusateri 
 wrote:

> Another option is Current Version minus X (N-1, N-2, etc.) If for
> instance you say we support N-1, and current version is 3.9, then you'll
> back port to latest 3.8.x.  N-2 at current version 3.9, would backport to
> 3.8.x, 3.7.x, etc.  The advantages here are that you already set the
> expectation for everyone, you limit the versions you support, you force
> people to stay current to get fixes.  The downside is that people have to
> upgrade and or it could impact downstream schedules.  The impact with 
> going
> this route is affected by the release velocity.  So if you're rapidly
> releasing major versions, then it's more likely people won't keep up, or
> that they'll have to upgrade and are not able to for some reason.
>
> Matt P.
>
>
> On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg 
> wrote:
>
>> Thanks for putting all the options together.
>> I would say that option 2 is a recipe for very bad user experience,
>> and i'd vote strongly against it.
>> I am 

[Pulp-dev] Pulp2: 2.21.5 Release incoming

[Grant Gainey]

Hello folks,

We have a number of Pulp2 bugs that have been fixed, that we would like to
get into a formal release. To that end, I'm proposing the following dates:

dev-freeze: *Thu 14-JAN*
beta (rpms available): *Mon 18-JAN*
GA: *Mon 25-JAN*

Release page is here:

https://pulp.plan.io/projects/pulp/wiki/2215_Release_Schedule

You can see the list of proposed issues here:

https://pulp.plan.io/issues?query_id=167

I will be the release-nanny for 2.21.5.  If you have questions or
counter-proposals, you can reach me at *ggai...@redhat.com
* or via IRC, *ggainey *in* #pulp *or* #pulp-dev *on
* Freenode*. I am in Raleigh's timezone (GMT-4)

Thanks!

Grant
-- 
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