[Pulp-dev] Katello/Pulp3 Integration mtg

[Grant Gainey]

January 6, 2021

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 slated for end of January
  -

  Discussion of backports and LTS releases
  -

   RPM
   -

  Make sqlite metadata generation optional (default: off) merged
  -

  relative-path/metadata mirroring work happening ‘soon’
  -

 Needed for 4.0/4.1
 -

   Migration
   -

  Work on tests wraps up to unblock distribution migration fix
  -

  2.21.5/pulpcore restart-on-failure ordering issue
  -

   2.21.5
   -

  Need a list of issues - some slated for next-katello-release but not
  ‘done’ yet?
  -

  Working w/build to figure out if we can still make .0
  -

   Katello needs BZs to track pulp-work slated for a specific release
   -

  BZ per issue? Or BZ per-pulp-release?
  -

  QE would prob prefer per-issue
  -

  Prob continue the existing pulp2 process, for pulp3


Katello

   -

   Smart Proxy container gateway work
   -

  Auth discussions happening on theforeman mailing-list
  -

  Might coincide w/ansible needs
  -

   Started setting up to migration test more user databases


QE

   -

   Any info on the build? Pulp 3 installation with services disabled?
   -

  Waiting on issues hit by build-team
  -

  Nightly-test issues encountered, under investigation
  -

  Jsherrill will ping ltran when there’s more info available


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

Re: [Pulp-dev] Backports and LTS

[Daniel Alley]

>
> 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 ok with option 1, but I would add that the backport to the
>>> intermediate minor releases _must_ be performed (as in released) counting
>>> down, to always meet that upgrade expectation. Remember releasing can be
>>> delayed unexpectedly due to reasons.
>>> If we go for option 3, I think it's advisable to try to sync up
>>> stakeholders, because we don't want to maintain consecutive minor versions
>>> as LTS, and again, backporting a fix must traverse all maintained LTS in
>>> backward order. We should add expectations to how long we can keep an LTS
>>> version alive, and how often we bless one.
>>>
>>> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
>>> wrote:
>>>
 With more and further away backport requests coming in, there is more
 need for a clear policy/docs to set expectations for users and to define
 requirements for those performing a backport.

 The question which hasn't been answered yet (in documented way) is:

 *Should backports be backported to every (minor) version between the
 fix and the requested version?*

 E.g. A backport is requested for 3.7, the original fixed will be
 released in 3.10.
 Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
 Reminder: a backport can only be a bug fix and without a db migration.

 Option 1. Backport to all releases in between.
  + it's an expected upgrade path for users, no surprises, the fix is
 present all the way.
  - it's a lot of maintenance and release burden, and the further
 backport is the worse it is.

Re: [Pulp-dev] CLI tasks for pulpcore/pulp_file features

[Fabricio Aguiar]

I think we could change PR template [1] and add a checkbox for remembering

[1]
https://github.com/pulp/pulpcore/blob/master/.github/pull_request_template.md

Best regards,
Fabricio Aguiar
Software Engineer, Pulp Project
Red Hat Brazil - Latam 
+55 22 999000595


On Wed, Jan 6, 2021 at 1:57 PM David Davis  wrote:

> We're approaching feature parity in the CLI with the REST API for pulpcore
> and pulp_file. As a result, any new features in pulpcore and pulp_file will
> introduce functionality gaps in the CLI.
>
> Optimally, it would be great if developers implemented the CLI
> functionality concurrently with the features that they're implementing in
> pulpcore and pulp_file. We on the CLI team would be happy to help anyone
> out who wants to do so. However, if you don't have time, please at least
> file a CLI issue.
>
> https://pulp.plan.io/projects/pulp-cli
>
> Thank you.
>
> David
> ___
> 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-CLI team meeting

[Matthias Dellweg]

## Jan 6, 2021

* We need a release process +1
* Release on regular basis
* Add changelog/towncrier
* Do a manual release (0.1), note each step. Then automate.
* Create changelog
* tag commit
* build and push to pypi
* Which pulpcore releases should we support?
* Starting with 3.9, support 5 y releases back
* Follow LTS discussion and adjust based on decision
* Some resources can only be fetched by name but they are sometimes
returned as hrefs (eg created_resources)
* Add an --href (or id?) option to commands that take name
* Command needs to validate that the href matches the resource
* [daviddavis] file a task
* Add a pulp show command that takes an href
* Next goals? Anything to discuss before 3 month planning?
* user-management? needs user-REST first
* [david] email that developers need to file CLI tasks as they add
features
* pulp_ansible support - offer to gerrod
* Satellite wants
* https://pulp.plan.io/issues/7531
* Valid request
* https://pulp.plan.io/issues/7683
* This is probably not possible with the REST api atm
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] CLI tasks for pulpcore/pulp_file features

[David Davis]

We're approaching feature parity in the CLI with the REST API for pulpcore
and pulp_file. As a result, any new features in pulpcore and pulp_file will
introduce functionality gaps in the CLI.

Optimally, it would be great if developers implemented the CLI
functionality concurrently with the features that they're implementing in
pulpcore and pulp_file. We on the CLI team would be happy to help anyone
out who wants to do so. However, if you don't have time, please at least
file a CLI issue.

https://pulp.plan.io/projects/pulp-cli

Thank you.

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

Re: [Pulp-dev] RBAC: Secure by default?

[Daniel Alley]

+1

What happens if a new account is created on an existing Pulp installation
(if that is possible)?  Would it then start following the deny-by-default
pattern?

On Wed, Jan 6, 2021 at 8:57 AM David Davis  wrote:

> +1 from me.
>
> David
>
>
> On Wed, Jan 6, 2021 at 8:28 AM Ina Panova  wrote:
>
>> +1 to the change.
>>
>>
>> 
>> 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, Dec 16, 2020 at 8:14 PM Tanya Tereshchenko 
>> wrote:
>>
>>> It sounds like a good idea,  and additional +1 that it doesn't break
>>> things.
>>>
>>> On Tue, Dec 15, 2020 at 5:57 PM Matthias Dellweg 
>>> wrote:
>>>
 In today's pulpcore meeting, we discussed that any endpoint that is not
 aware of RBAC yet will be open to every authenticated user.

 The suggestion that was given, is that we change that default. So all
 endpoints will raise permission errors unless RBAC opens them up.
 This would not affect any existing installation, where we only allowed
 the use of a single admin user. And by circumventing the permission
 framework this special user will remain to be able to talk to all available
 endpoints without restrictions.
 On the other hand it should smooth out the transition period until we
 have RBAC in all places. Since you could start giving permissions to users
 for viewsets that have an access_policy, while not risking to give them
 access to other sensitive parts that don't have it yet.

 What do you all think?
 ___
 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 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 mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Backports and LTS

[David Davis]

I agree and I don't have a strong preference between option 1 and 3. If we
go with option 1 though, I'd recommend we prioritize automating the rest of
our release process. Otherwise, we're going to spend a lot of time
releasing.

David


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 ok with option 1, but I would add that the backport to the
>>> intermediate minor releases _must_ be performed (as in released) counting
>>> down, to always meet that upgrade expectation. Remember releasing can be
>>> delayed unexpectedly due to reasons.
>>> If we go for option 3, I think it's advisable to try to sync up
>>> stakeholders, because we don't want to maintain consecutive minor versions
>>> as LTS, and again, backporting a fix must traverse all maintained LTS in
>>> backward order. We should add expectations to how long we can keep an LTS
>>> version alive, and how often we bless one.
>>>
>>> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
>>> wrote:
>>>
 With more and further away backport requests coming in, there is more
 need for a clear policy/docs to set expectations for users and to define
 requirements for those performing a backport.

 The question which hasn't been answered yet (in documented way) is:

 *Should backports be backported to every (minor) version between the
 fix and the requested version?*

 E.g. A backport is requested for 3.7, the original fixed will be
 released in 3.10.
 Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
 Reminder: a backport can only be a bug fix and without a db migration.

 Option 1. Backport to all releases in between.
  + it's an expected upgrade path for users, no surprises, the fix is
 present all the way.
  - it's a lot of maintenance and release burden, and the further
 backport is the worse it is.

 Option 2. Backport to the requested release only.
  + just one backport and release to do
  - inconsistent user experience if a user doesn't upgrade to the latest
 version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades
 to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the
 very least, imo.

 Option 3. Have LTS releases and allow backports to the latest LTS only
  + just one backport and release to do
  + users are aware that backports go only into this release and do not
 expect fixes in non-LTS releases in between
  - less flexibility with multiple stakeholders (e.g. Katello will
 benefit from 3.7 being an LTS release, Galaxy - from 3.8)

 Please share your thoughts or suggest other options,
 Tanya
 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>> ___
>>> Pulp-dev mailing list
>>> 

Re: [Pulp-dev] Backports and LTS

[Ina Panova]

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 ok with option 1, but I would add that the backport to the
>> intermediate minor releases _must_ be performed (as in released) counting
>> down, to always meet that upgrade expectation. Remember releasing can be
>> delayed unexpectedly due to reasons.
>> If we go for option 3, I think it's advisable to try to sync up
>> stakeholders, because we don't want to maintain consecutive minor versions
>> as LTS, and again, backporting a fix must traverse all maintained LTS in
>> backward order. We should add expectations to how long we can keep an LTS
>> version alive, and how often we bless one.
>>
>> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
>> wrote:
>>
>>> With more and further away backport requests coming in, there is more
>>> need for a clear policy/docs to set expectations for users and to define
>>> requirements for those performing a backport.
>>>
>>> The question which hasn't been answered yet (in documented way) is:
>>>
>>> *Should backports be backported to every (minor) version between the fix
>>> and the requested version?*
>>>
>>> E.g. A backport is requested for 3.7, the original fixed will be
>>> released in 3.10.
>>> Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
>>> Reminder: a backport can only be a bug fix and without a db migration.
>>>
>>> Option 1. Backport to all releases in between.
>>>  + it's an expected upgrade path for users, no surprises, the fix is
>>> present all the way.
>>>  - it's a lot of maintenance and release burden, and the further
>>> backport is the worse it is.
>>>
>>> Option 2. Backport to the requested release only.
>>>  + just one backport and release to do
>>>  - inconsistent user experience if a user doesn't upgrade to the latest
>>> version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades
>>> to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the
>>> very least, imo.
>>>
>>> Option 3. Have LTS releases and allow backports to the latest LTS only
>>>  + just one backport and release to do
>>>  + users are aware that backports go only into this release and do not
>>> expect fixes in non-LTS releases in between
>>>  - less flexibility with multiple stakeholders (e.g. Katello will
>>> benefit from 3.7 being an LTS release, Galaxy - from 3.8)
>>>
>>> Please share your thoughts or suggest other options,
>>> Tanya
>>> ___
>>> 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 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

Re: [Pulp-dev] RBAC: Secure by default?

[David Davis]

+1 from me.

David


On Wed, Jan 6, 2021 at 8:28 AM Ina Panova  wrote:

> +1 to the change.
>
>
> 
> 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, Dec 16, 2020 at 8:14 PM Tanya Tereshchenko 
> wrote:
>
>> It sounds like a good idea,  and additional +1 that it doesn't break
>> things.
>>
>> On Tue, Dec 15, 2020 at 5:57 PM Matthias Dellweg 
>> wrote:
>>
>>> In today's pulpcore meeting, we discussed that any endpoint that is not
>>> aware of RBAC yet will be open to every authenticated user.
>>>
>>> The suggestion that was given, is that we change that default. So all
>>> endpoints will raise permission errors unless RBAC opens them up.
>>> This would not affect any existing installation, where we only allowed
>>> the use of a single admin user. And by circumventing the permission
>>> framework this special user will remain to be able to talk to all available
>>> endpoints without restrictions.
>>> On the other hand it should smooth out the transition period until we
>>> have RBAC in all places. Since you could start giving permissions to users
>>> for viewsets that have an access_policy, while not risking to give them
>>> access to other sensitive parts that don't have it yet.
>>>
>>> What do you all think?
>>> ___
>>> 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 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

Re: [Pulp-dev] Re-enable required status checks

[David Davis]

No problem! Thanks for fixing it.

David


On Wed, Jan 6, 2021 at 8:22 AM Tanya Tereshchenko 
wrote:

> I went through the list of repos from this thread and pulp 3 related
> branches and unset the up-to-date check where it was set.
> Thanks for noticing and pointing out the problem.
>
> Tanya
>
> On Wed, Jan 6, 2021 at 12:58 PM Tanya Tereshchenko 
> wrote:
>
>> Interesting, I didn't notice that.
>> In any case, I didn't enable it on purpose. Moreover, some repos were
>> updated already, so maybe David is right that it's a default.
>> Let's turn it off.
>>
>> On Wed, Jan 6, 2021 at 12:12 PM Matthias Dellweg 
>> wrote:
>>
>>> I noticed this too. Somehow i used the wrong channel to ask about it.
>>> Anyway, i think this is breaking any considerable collaboration approach,
>>> because every single PR must be refreshed immediately before merging. This
>>> will put off external contributors.
>>>
>>> On Tue, Jan 5, 2021 at 10:42 PM David Davis 
>>> wrote:
>>>
 I noticed for the repos that got updated, PRs must now be up to date
 before merging. I think we previously had this disabled but I am guessing
 it got enabled since it's the default when required status checks are
 enabled?

 David


 On Fri, Dec 11, 2020 at 7:26 AM Tanya Tereshchenko 
 wrote:

> FYI, I went through the following repos and enabled required checks
> (lint, test(pulp), test(docs), and test(s3)) where they were missing, for
> the master and for the release branches if such rules existed:
>  - pulpcore
>  - pulp_file
>  - pulp_rpm
>  - pulp_container
>  - pulp_ansible
>  - pulp_python
>  - pulp_deb
>  - pulp-2to3-migration
>  - pulp-certguard
>
>
> On Wed, Dec 9, 2020 at 5:35 PM David Davis 
> wrote:
>
>> 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 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

Re: [Pulp-dev] plugin release checklist templates

[Ina Panova]

+1 to a generic  release checklist template.



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 Tue, Jan 5, 2021 at 4:11 PM Matthias Dellweg  wrote:

> +1 for deduplication
>
> We can add "pulpcore only" steps and tick them right away.
>

Or for every pulpcore step have something like in parenthesis (pulpcore
only)


> On Tue, Jan 5, 2021 at 4:08 PM David Davis  wrote:
>
>> +1 to a global plugin release checklist template.
>>
>> I imagine that pulpcore will have its own set of templates though? I
>> think there are some steps (eg release the plugin_template and installer)
>> that plugins don't do.
>>
>> David
>>
>>
>> On Tue, Dec 15, 2020 at 11:19 AM Tanya Tereshchenko 
>> wrote:
>>
>>> We started using redmine checklists in pulpcore and in some plugins.
>>> Here [0] is an example of a plugin checklist in use.
>>>
>>> Currently any plugin which has a checklist template has their own
>>> checklist template.
>>> It's quite inconvenient to update those if there any changes introduced
>>> to the release process and with time they divert.
>>>
>>> Any objections to have one plugin release template (one for each release
>>> type) shared with all the redmine projects?
>>>
>>> One downside is that links and paths specified in the template won't be
>>> plugin specific but will be mentioned in a more generic way, like:
>>>
>>>- Create a release https://github.com/pulp//releases/new
>>>
>>>- Regenerate the .github files on the stable branch with
>>>plugin_template (./plugin-template --github )
>>>
>>> Any other suggestion to keep plugin release steps up to date across all
>>> plugins are welcome.
>>>
>>> Thank you,
>>> Tanya
>>>
>>> [0] https://pulp.plan.io/issues/7920
>>> ___
>>> 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 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

Re: [Pulp-dev] RBAC: Secure by default?

[Ina Panova]

+1 to the change.



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, Dec 16, 2020 at 8:14 PM Tanya Tereshchenko 
wrote:

> It sounds like a good idea,  and additional +1 that it doesn't break
> things.
>
> On Tue, Dec 15, 2020 at 5:57 PM Matthias Dellweg 
> wrote:
>
>> In today's pulpcore meeting, we discussed that any endpoint that is not
>> aware of RBAC yet will be open to every authenticated user.
>>
>> The suggestion that was given, is that we change that default. So all
>> endpoints will raise permission errors unless RBAC opens them up.
>> This would not affect any existing installation, where we only allowed
>> the use of a single admin user. And by circumventing the permission
>> framework this special user will remain to be able to talk to all available
>> endpoints without restrictions.
>> On the other hand it should smooth out the transition period until we
>> have RBAC in all places. Since you could start giving permissions to users
>> for viewsets that have an access_policy, while not risking to give them
>> access to other sensitive parts that don't have it yet.
>>
>> What do you all think?
>> ___
>> 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 mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Re-enable required status checks

[Tanya Tereshchenko]

I went through the list of repos from this thread and pulp 3 related
branches and unset the up-to-date check where it was set.
Thanks for noticing and pointing out the problem.

Tanya

On Wed, Jan 6, 2021 at 12:58 PM Tanya Tereshchenko 
wrote:

> Interesting, I didn't notice that.
> In any case, I didn't enable it on purpose. Moreover, some repos were
> updated already, so maybe David is right that it's a default.
> Let's turn it off.
>
> On Wed, Jan 6, 2021 at 12:12 PM Matthias Dellweg 
> wrote:
>
>> I noticed this too. Somehow i used the wrong channel to ask about it.
>> Anyway, i think this is breaking any considerable collaboration approach,
>> because every single PR must be refreshed immediately before merging. This
>> will put off external contributors.
>>
>> On Tue, Jan 5, 2021 at 10:42 PM David Davis 
>> wrote:
>>
>>> I noticed for the repos that got updated, PRs must now be up to date
>>> before merging. I think we previously had this disabled but I am guessing
>>> it got enabled since it's the default when required status checks are
>>> enabled?
>>>
>>> David
>>>
>>>
>>> On Fri, Dec 11, 2020 at 7:26 AM Tanya Tereshchenko 
>>> wrote:
>>>
 FYI, I went through the following repos and enabled required checks
 (lint, test(pulp), test(docs), and test(s3)) where they were missing, for
 the master and for the release branches if such rules existed:
  - pulpcore
  - pulp_file
  - pulp_rpm
  - pulp_container
  - pulp_ansible
  - pulp_python
  - pulp_deb
  - pulp-2to3-migration
  - pulp-certguard


 On Wed, Dec 9, 2020 at 5:35 PM David Davis 
 wrote:

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

Re: [Pulp-dev] Backports and LTS

[Matt Pusateri]

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 ok with option 1, but I would add that the backport to the
> intermediate minor releases _must_ be performed (as in released) counting
> down, to always meet that upgrade expectation. Remember releasing can be
> delayed unexpectedly due to reasons.
> If we go for option 3, I think it's advisable to try to sync up
> stakeholders, because we don't want to maintain consecutive minor versions
> as LTS, and again, backporting a fix must traverse all maintained LTS in
> backward order. We should add expectations to how long we can keep an LTS
> version alive, and how often we bless one.
>
> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
> wrote:
>
>> With more and further away backport requests coming in, there is more
>> need for a clear policy/docs to set expectations for users and to define
>> requirements for those performing a backport.
>>
>> The question which hasn't been answered yet (in documented way) is:
>>
>> *Should backports be backported to every (minor) version between the fix
>> and the requested version?*
>>
>> E.g. A backport is requested for 3.7, the original fixed will be released
>> in 3.10.
>> Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
>> Reminder: a backport can only be a bug fix and without a db migration.
>>
>> Option 1. Backport to all releases in between.
>>  + it's an expected upgrade path for users, no surprises, the fix is
>> present all the way.
>>  - it's a lot of maintenance and release burden, and the further backport
>> is the worse it is.
>>
>> Option 2. Backport to the requested release only.
>>  + just one backport and release to do
>>  - inconsistent user experience if a user doesn't upgrade to the latest
>> version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades
>> to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the
>> very least, imo.
>>
>> Option 3. Have LTS releases and allow backports to the latest LTS only
>>  + just one backport and release to do
>>  + users are aware that backports go only into this release and do not
>> expect fixes in non-LTS releases in between
>>  - less flexibility with multiple stakeholders (e.g. Katello will benefit
>> from 3.7 being an LTS release, Galaxy - from 3.8)
>>
>> Please share your thoughts or suggest other options,
>> Tanya
>> ___
>> 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 mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Re-enable required status checks

[Tanya Tereshchenko]

Interesting, I didn't notice that.
In any case, I didn't enable it on purpose. Moreover, some repos were
updated already, so maybe David is right that it's a default.
Let's turn it off.

On Wed, Jan 6, 2021 at 12:12 PM Matthias Dellweg 
wrote:

> I noticed this too. Somehow i used the wrong channel to ask about it.
> Anyway, i think this is breaking any considerable collaboration approach,
> because every single PR must be refreshed immediately before merging. This
> will put off external contributors.
>
> On Tue, Jan 5, 2021 at 10:42 PM David Davis  wrote:
>
>> I noticed for the repos that got updated, PRs must now be up to date
>> before merging. I think we previously had this disabled but I am guessing
>> it got enabled since it's the default when required status checks are
>> enabled?
>>
>> David
>>
>>
>> On Fri, Dec 11, 2020 at 7:26 AM Tanya Tereshchenko 
>> wrote:
>>
>>> FYI, I went through the following repos and enabled required checks
>>> (lint, test(pulp), test(docs), and test(s3)) where they were missing, for
>>> the master and for the release branches if such rules existed:
>>>  - pulpcore
>>>  - pulp_file
>>>  - pulp_rpm
>>>  - pulp_container
>>>  - pulp_ansible
>>>  - pulp_python
>>>  - pulp_deb
>>>  - pulp-2to3-migration
>>>  - pulp-certguard
>>>
>>>
>>> On Wed, Dec 9, 2020 at 5:35 PM David Davis 
>>> wrote:
>>>
 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 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

Re: [Pulp-dev] Re-enable required status checks

[Matthias Dellweg]

I noticed this too. Somehow i used the wrong channel to ask about it.
Anyway, i think this is breaking any considerable collaboration approach,
because every single PR must be refreshed immediately before merging. This
will put off external contributors.

On Tue, Jan 5, 2021 at 10:42 PM David Davis  wrote:

> I noticed for the repos that got updated, PRs must now be up to date
> before merging. I think we previously had this disabled but I am guessing
> it got enabled since it's the default when required status checks are
> enabled?
>
> David
>
>
> On Fri, Dec 11, 2020 at 7:26 AM Tanya Tereshchenko 
> wrote:
>
>> FYI, I went through the following repos and enabled required checks
>> (lint, test(pulp), test(docs), and test(s3)) where they were missing, for
>> the master and for the release branches if such rules existed:
>>  - pulpcore
>>  - pulp_file
>>  - pulp_rpm
>>  - pulp_container
>>  - pulp_ansible
>>  - pulp_python
>>  - pulp_deb
>>  - pulp-2to3-migration
>>  - pulp-certguard
>>
>>
>> On Wed, Dec 9, 2020 at 5:35 PM David Davis  wrote:
>>
>>> 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 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

Re: [Pulp-dev] Backports and LTS

[Matthias Dellweg]

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 ok with option 1, but I would add that the backport to the
intermediate minor releases _must_ be performed (as in released) counting
down, to always meet that upgrade expectation. Remember releasing can be
delayed unexpectedly due to reasons.
If we go for option 3, I think it's advisable to try to sync up
stakeholders, because we don't want to maintain consecutive minor versions
as LTS, and again, backporting a fix must traverse all maintained LTS in
backward order. We should add expectations to how long we can keep an LTS
version alive, and how often we bless one.

On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko 
wrote:

> With more and further away backport requests coming in, there is more need
> for a clear policy/docs to set expectations for users and to define
> requirements for those performing a backport.
>
> The question which hasn't been answered yet (in documented way) is:
>
> *Should backports be backported to every (minor) version between the fix
> and the requested version?*
>
> E.g. A backport is requested for 3.7, the original fixed will be released
> in 3.10.
> Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
> Reminder: a backport can only be a bug fix and without a db migration.
>
> Option 1. Backport to all releases in between.
>  + it's an expected upgrade path for users, no surprises, the fix is
> present all the way.
>  - it's a lot of maintenance and release burden, and the further backport
> is the worse it is.
>
> Option 2. Backport to the requested release only.
>  + just one backport and release to do
>  - inconsistent user experience if a user doesn't upgrade to the latest
> version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades
> to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the
> very least, imo.
>
> Option 3. Have LTS releases and allow backports to the latest LTS only
>  + just one backport and release to do
>  + users are aware that backports go only into this release and do not
> expect fixes in non-LTS releases in between
>  - less flexibility with multiple stakeholders (e.g. Katello will benefit
> from 3.7 being an LTS release, Galaxy - from 3.8)
>
> Please share your thoughts or suggest other options,
> Tanya
> ___
> 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