[Pulp-dev] pulp_file 1.10.0 and pulp-cli 0.12.0 are generally available

[David Davis]

For more information, please see the discourse links below.

pulp_file: https://discourse.pulpproject.org/t/pulp-file-1-10-0-is-ga/181

pulp-cli:
https://discourse.pulpproject.org/t/pulp-cli-0-12-0-is-generally-available/185

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

[Pulp-dev] PulpCon 2021 CFP

[David Davis]

Please visit discourse to propose/vote on/view potential sessions for
PulpCon 2021.

https://discourse.pulpproject.org/t/pulpcon-2021-call-for-proposals/134

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

[Pulp-dev] Docs day today!

[David Davis]

Please join us today for Docs Day. More info:

https://discourse.pulpproject.org/t/join-us-for-docs-day-tomorrow/107

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

[Pulp-dev] pulp_file 1.9.1 is generally available

[David Davis]

More info:

https://discourse.pulpproject.org/t/pulp-file-1-9-1-is-generally-available/110

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

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

I've taken down Github Discussions. It looks like Github stores the
Discussions though so I can still re-enable them temporarily if anyone
needs info, etc.

David


On Tue, Aug 24, 2021 at 2:44 PM David Davis  wrote:

> AFAICT, there's no way to make discussions readonly so any discussions not
> migrated over won't be accessible although I think we can still get to them
> by temporarily enabling Discussions.
>
> Looks like mcorr already migrated over your thread. :)
>
> David
>
>
> On Tue, Aug 24, 2021 at 2:01 AM Quirin Pamp  wrote:
>
>> Will it still be possible to read old discussion threads?
>>
>> If no, I would like it if this one could be migrated (for the conclusions
>> reached in the thread):
>>
>> https://github.com/pulp/community/discussions/73
>>
>> Quirin (quba42)
>>
>> ________
>> From: pulp-dev-boun...@redhat.com  on
>> behalf of David Davis 
>> Sent: 23 August 2021 15:30
>> To: Melanie Corr
>> Cc: pulp-list; Pulp Development List
>> Subject: Re: [Pulp-dev] [Pulp-list]  Github Discussions
>>
>> If no one objects, I will be retiring Pulp's Github Discussions by
>> September 1st. It seems like the options we are considering going forward
>> are either staying on the mailing lists or moving to Discourse.
>>
>> If you need something migrated over to Discourse from Github Discussions,
>> please let me know.
>>
>> David
>>
>>
>> On Wed, Aug 11, 2021 at 9:55 AM Melanie Corr > mc...@redhat.com>> wrote:
>> Hi all,
>>
>> Based on your feedback, we now have a Pulp Community Discourse:
>> https://discourse.pulpproject.org/
>>
>> This is still a continuation of our evaluation of whether to move away
>> from the mailing list as a primary communication method. We need you to
>> tell us if this is helpful.
>>
>> We will wrap up any discussions that remain open on our GitHub
>> Discussions page and migrate any open discussions.
>>
>> I'm getting everything ready. Please feel free to make suggestions.
>>
>> Please join us over on Discourse!
>>
>> Melanie
>>
>> Ar Aoine 18 Meith 2021 ag 17:01, scríobh Melanie Corr > <mailto:mc...@redhat.com>>:
>> Having been an admin on the Foreman Community Discourse for over a year,
>> I am +1 to a using Discourse for community conversations.
>> Greg Sutcliffe has data to prove the increase in community engagement
>> after the move.
>>
>> Ar Aoine 18 Meith 2021 ag 16:33, scríobh Daniel Alley > <mailto:dal...@redhat.com>>:
>> And Matrix integration.
>> https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522
>>
>>
>> On Thu, Jun 17, 2021 at 1:11 PM David Davis > <mailto:davidda...@redhat.com>> wrote:
>> I was rather surprised but Discourse did approve us for a free plan. The
>> instance has been set up at https://pulp.discourse.group/. Feel free to
>> try it out and experiment with it.
>>
>> However, the main limitation I see is the 50k pageviews per month limit.
>> For reference, community.theforeman.org<http://community.theforeman.org>
>> gets about 160-220k pageviews per month. So I think this would end up being
>> a problem. I also checked with OSCI though and they apparently have
>> experience with setting up Discourse instances for other open source
>> communities. So I think they might be willing to set up a Discourse
>> instance for us. I'm going to follow up and confirm.
>>
>> If we go this route, then we can also add the calendar plugin which would
>> give us a public calendar like foreman has:
>>
>> https://community.theforeman.org/c/events/13/l/calendar
>>
>> I'm imagining we can use this to list events that are open to the public
>> like triage/open floor and perhaps plugin team meetings.
>>
>> The more I use Discourse, the more I feel like it ticks all the boxes
>> from granular notifications (weekly digests, ability to follow/unfollow
>> categories, etc) to a mailing list mode users can enable to SSO integration
>> with services like Github.
>>
>> David
>>
>>
>> On Wed, Jun 16, 2021 at 7:59 PM Neal Gompa > ngomp...@gmail.com>> wrote:
>> On Wed, Jun 16, 2021 at 7:21 PM David Davis > <mailto:davidda...@redhat.com>> wrote:
>> >
>> > One of the main reasons we wanted to move off mailing lists is that
>> signing up is inconvenient for users that may just want to ask a single
>> question. But I agree that Github Discussions is not so great if users wan

[Pulp-dev] pulpcore 3.15.0 generally available

[David Davis]

For more information, check out the post on Discourse:

https://discourse.pulpproject.org/t/pulpcore-3-15-0-is-generally-available/101

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

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

AFAICT, there's no way to make discussions readonly so any discussions not
migrated over won't be accessible although I think we can still get to them
by temporarily enabling Discussions.

Looks like mcorr already migrated over your thread. :)

David


On Tue, Aug 24, 2021 at 2:01 AM Quirin Pamp  wrote:

> Will it still be possible to read old discussion threads?
>
> If no, I would like it if this one could be migrated (for the conclusions
> reached in the thread):
>
> https://github.com/pulp/community/discussions/73
>
> Quirin (quba42)
>
> 
> From: pulp-dev-boun...@redhat.com  on behalf
> of David Davis 
> Sent: 23 August 2021 15:30
> To: Melanie Corr
> Cc: pulp-list; Pulp Development List
> Subject: Re: [Pulp-dev] [Pulp-list]  Github Discussions
>
> If no one objects, I will be retiring Pulp's Github Discussions by
> September 1st. It seems like the options we are considering going forward
> are either staying on the mailing lists or moving to Discourse.
>
> If you need something migrated over to Discourse from Github Discussions,
> please let me know.
>
> David
>
>
> On Wed, Aug 11, 2021 at 9:55 AM Melanie Corr  mc...@redhat.com>> wrote:
> Hi all,
>
> Based on your feedback, we now have a Pulp Community Discourse:
> https://discourse.pulpproject.org/
>
> This is still a continuation of our evaluation of whether to move away
> from the mailing list as a primary communication method. We need you to
> tell us if this is helpful.
>
> We will wrap up any discussions that remain open on our GitHub Discussions
> page and migrate any open discussions.
>
> I'm getting everything ready. Please feel free to make suggestions.
>
> Please join us over on Discourse!
>
> Melanie
>
> Ar Aoine 18 Meith 2021 ag 17:01, scríobh Melanie Corr  <mailto:mc...@redhat.com>>:
> Having been an admin on the Foreman Community Discourse for over a year, I
> am +1 to a using Discourse for community conversations.
> Greg Sutcliffe has data to prove the increase in community engagement
> after the move.
>
> Ar Aoine 18 Meith 2021 ag 16:33, scríobh Daniel Alley  <mailto:dal...@redhat.com>>:
> And Matrix integration.
> https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522
>
>
> On Thu, Jun 17, 2021 at 1:11 PM David Davis  davidda...@redhat.com>> wrote:
> I was rather surprised but Discourse did approve us for a free plan. The
> instance has been set up at https://pulp.discourse.group/. Feel free to
> try it out and experiment with it.
>
> However, the main limitation I see is the 50k pageviews per month limit.
> For reference, community.theforeman.org<http://community.theforeman.org>
> gets about 160-220k pageviews per month. So I think this would end up being
> a problem. I also checked with OSCI though and they apparently have
> experience with setting up Discourse instances for other open source
> communities. So I think they might be willing to set up a Discourse
> instance for us. I'm going to follow up and confirm.
>
> If we go this route, then we can also add the calendar plugin which would
> give us a public calendar like foreman has:
>
> https://community.theforeman.org/c/events/13/l/calendar
>
> I'm imagining we can use this to list events that are open to the public
> like triage/open floor and perhaps plugin team meetings.
>
> The more I use Discourse, the more I feel like it ticks all the boxes from
> granular notifications (weekly digests, ability to follow/unfollow
> categories, etc) to a mailing list mode users can enable to SSO integration
> with services like Github.
>
> David
>
>
> On Wed, Jun 16, 2021 at 7:59 PM Neal Gompa  ngomp...@gmail.com>> wrote:
> On Wed, Jun 16, 2021 at 7:21 PM David Davis  davidda...@redhat.com>> wrote:
> >
> > One of the main reasons we wanted to move off mailing lists is that
> signing up is inconvenient for users that may just want to ask a single
> question. But I agree that Github Discussions is not so great if users want
> to periodically monitor news and discussions for a project like Pulp. I
> wonder perhaps if Discourse[0] would be a better fit (see Foreman's use of
> discourse as an example[1]). It provides a mailing list mode that users can
> enable if they want to interact solely via email. And also, it also offers
> more granular control of notifications and auth with services like Github.
> >
>
> The Fedora mailing list system (HyperKitty) actually manages to strike
> a good balance here. You can sign in with OIDC/Social Login with
> Fedora, Google, etc. and post to a list and only be subscribed to that
> thread. Or you can subscribe to the whole 

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

If no one objects, I will be retiring Pulp's Github Discussions by
September 1st. It seems like the options we are considering going forward
are either staying on the mailing lists or moving to Discourse.

If you need something migrated over to Discourse from Github Discussions,
please let me know.

David


On Wed, Aug 11, 2021 at 9:55 AM Melanie Corr  wrote:

> Hi all,
>
> Based on your feedback, we now have a Pulp Community Discourse:
> https://discourse.pulpproject.org/
>
> This is still a continuation of our evaluation of whether to move away
> from the mailing list as a primary communication method. We need you to
> tell us if this is helpful.
>
> We will wrap up any discussions that remain open on our GitHub Discussions
> page and migrate any open discussions.
>
> I'm getting everything ready. Please feel free to make suggestions.
>
> Please join us over on Discourse!
>
> Melanie
>
> Ar Aoine 18 Meith 2021 ag 17:01, scríobh Melanie Corr :
>
>> Having been an admin on the Foreman Community Discourse for over a year,
>> I am +1 to a using Discourse for community conversations.
>> Greg Sutcliffe has data to prove the increase in community engagement
>> after the move.
>>
>> Ar Aoine 18 Meith 2021 ag 16:33, scríobh Daniel Alley > >:
>>
>>> And Matrix integration.
>>> https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522
>>>
>>>
>>> On Thu, Jun 17, 2021 at 1:11 PM David Davis 
>>> wrote:
>>>
>>>> I was rather surprised but Discourse did approve us for a free plan.
>>>> The instance has been set up at https://pulp.discourse.group/. Feel
>>>> free to try it out and experiment with it.
>>>>
>>>> However, the main limitation I see is the 50k pageviews per month
>>>> limit. For reference, community.theforeman.org gets about 160-220k
>>>> pageviews per month. So I think this would end up being a problem. I also
>>>> checked with OSCI though and they apparently have experience with setting
>>>> up Discourse instances for other open source communities. So I think they
>>>> might be willing to set up a Discourse instance for us. I'm going to follow
>>>> up and confirm.
>>>>
>>>> If we go this route, then we can also add the calendar plugin which
>>>> would give us a public calendar like foreman has:
>>>>
>>>> https://community.theforeman.org/c/events/13/l/calendar
>>>>
>>>> I'm imagining we can use this to list events that are open to the
>>>> public like triage/open floor and perhaps plugin team meetings.
>>>>
>>>> The more I use Discourse, the more I feel like it ticks all the boxes
>>>> from granular notifications (weekly digests, ability to follow/unfollow
>>>> categories, etc) to a mailing list mode users can enable to SSO integration
>>>> with services like Github.
>>>>
>>>> David
>>>>
>>>>
>>>> On Wed, Jun 16, 2021 at 7:59 PM Neal Gompa  wrote:
>>>>
>>>>> On Wed, Jun 16, 2021 at 7:21 PM David Davis 
>>>>> wrote:
>>>>> >
>>>>> > One of the main reasons we wanted to move off mailing lists is that
>>>>> signing up is inconvenient for users that may just want to ask a single
>>>>> question. But I agree that Github Discussions is not so great if users 
>>>>> want
>>>>> to periodically monitor news and discussions for a project like Pulp. I
>>>>> wonder perhaps if Discourse[0] would be a better fit (see Foreman's use of
>>>>> discourse as an example[1]). It provides a mailing list mode that users 
>>>>> can
>>>>> enable if they want to interact solely via email. And also, it also offers
>>>>> more granular control of notifications and auth with services like Github.
>>>>> >
>>>>>
>>>>> The Fedora mailing list system (HyperKitty) actually manages to strike
>>>>> a good balance here. You can sign in with OIDC/Social Login with
>>>>> Fedora, Google, etc. and post to a list and only be subscribed to that
>>>>> thread. Or you can subscribe to the whole list and do things like we
>>>>> do now.
>>>>>
>>>>> > One of the main concerns we've had around using Discourse is hosting
>>>>> it ourselves but it does look like Discourse provides a free plan for open
>>>>> source projects[2]. It has some li

[Pulp-dev] Updating Artifacts and Content in pulpcore 3.15

[David Davis]

I posted a discussion about a 3.14 release note that plugin writers should
be aware of when upgrading to pulpcore 3.15. Please check it out:

https://github.com/pulp/community/discussions/59

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

Re: [Pulp-dev] Pulp CI broken

[David Davis]

The container image is fixed now (thanks x9c4 and fao89).

There are a bunch of PRs to merge though to upgrade repos' CI files to
Python 3.8.

David


On Wed, Jul 14, 2021 at 7:02 PM David Davis  wrote:

> Hi all,
>
> Today, I upgraded the pulp containers to Python 3.8 and it broke the CI.
> The pulp/pulp container seems to work fine but for some reason, the new
> pulp-workers in the CI environment are not starting. I have a working
> plugin_template PR to update the CI files to use Python 3.8[0] but it's
> manually starting the new workers, which it should not have to do. Tomorrow
> I plan to debug what is causing this problem.
>
> Apologies for any inconvenience.
>
> [0] https://github.com/pulp/plugin_template/pull/436
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp CI broken

[David Davis]

Hi all,

Today, I upgraded the pulp containers to Python 3.8 and it broke the CI.
The pulp/pulp container seems to work fine but for some reason, the new
pulp-workers in the CI environment are not starting. I have a working
plugin_template PR to update the CI files to use Python 3.8[0] but it's
manually starting the new workers, which it should not have to do. Tomorrow
I plan to debug what is causing this problem.

Apologies for any inconvenience.

[0] https://github.com/pulp/plugin_template/pull/436

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

Re: [Pulp-dev] Dropping support for Python 3.7 and 3.8

[David Davis]

I haven't heard any objections so I plan to move forward with upgrading our
CI and container images to Python 3.8 on Wednesday July 14 if there are no
objections.

David


On Wed, Jul 7, 2021 at 12:43 PM David Davis  wrote:

> Just wanted to call attention to this thread for anyone not checking
> Github Discussions.
>
> https://github.com/pulp/community/discussions/3
>
> Please submit feedback/questions on the thread.
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Dropping support for Python 3.7 and 3.8

[David Davis]

Just wanted to call attention to this thread for anyone not checking Github
Discussions.

https://github.com/pulp/community/discussions/3

Please submit feedback/questions on the thread.

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

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

I was rather surprised but Discourse did approve us for a free plan. The
instance has been set up at https://pulp.discourse.group/. Feel free to try
it out and experiment with it.

However, the main limitation I see is the 50k pageviews per month limit.
For reference, community.theforeman.org gets about 160-220k pageviews per
month. So I think this would end up being a problem. I also checked with
OSCI though and they apparently have experience with setting up Discourse
instances for other open source communities. So I think they might be
willing to set up a Discourse instance for us. I'm going to follow up and
confirm.

If we go this route, then we can also add the calendar plugin which would
give us a public calendar like foreman has:

https://community.theforeman.org/c/events/13/l/calendar

I'm imagining we can use this to list events that are open to the public
like triage/open floor and perhaps plugin team meetings.

The more I use Discourse, the more I feel like it ticks all the boxes from
granular notifications (weekly digests, ability to follow/unfollow
categories, etc) to a mailing list mode users can enable to SSO integration
with services like Github.

David


On Wed, Jun 16, 2021 at 7:59 PM Neal Gompa  wrote:

> On Wed, Jun 16, 2021 at 7:21 PM David Davis  wrote:
> >
> > One of the main reasons we wanted to move off mailing lists is that
> signing up is inconvenient for users that may just want to ask a single
> question. But I agree that Github Discussions is not so great if users want
> to periodically monitor news and discussions for a project like Pulp. I
> wonder perhaps if Discourse[0] would be a better fit (see Foreman's use of
> discourse as an example[1]). It provides a mailing list mode that users can
> enable if they want to interact solely via email. And also, it also offers
> more granular control of notifications and auth with services like Github.
> >
>
> The Fedora mailing list system (HyperKitty) actually manages to strike
> a good balance here. You can sign in with OIDC/Social Login with
> Fedora, Google, etc. and post to a list and only be subscribed to that
> thread. Or you can subscribe to the whole list and do things like we
> do now.
>
> > One of the main concerns we've had around using Discourse is hosting it
> ourselves but it does look like Discourse provides a free plan for open
> source projects[2]. It has some limitations (not sure if they'd be an issue
> for us?) but I've submitted an application to see if we qualify. I should
> hear back in a couple days.
> >
>
> I suspect not, but it'd be an interesting surprise if we qualified.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

One of the main reasons we wanted to move off mailing lists is that signing
up is inconvenient for users that may just want to ask a single question.
But I agree that Github Discussions is not so great if users want to
periodically monitor news and discussions for a project like Pulp. I wonder
perhaps if Discourse[0] would be a better fit (see Foreman's use of
discourse as an example[1]). It provides a mailing list mode that users can
enable if they want to interact solely via email. And also, it also offers
more granular control of notifications and auth with services like Github.

One of the main concerns we've had around using Discourse is hosting it
ourselves but it does look like Discourse provides a free plan for open
source projects[2]. It has some limitations (not sure if they'd be an issue
for us?) but I've submitted an application to see if we qualify. I should
hear back in a couple days.

[0] https://www.discourse.org/
[1] https://community.theforeman.org/
[2] https://free.discourse.group/

David


On Wed, Jun 16, 2021 at 5:31 PM James Cassell 
wrote:

> On Wed, Jun 16, 2021, at 3:12 PM, Neal Gompa wrote:
> > On Wed, Jun 16, 2021 at 11:59 AM David Davis 
> wrote:
> > >
> > > Yesterday at open floor, we discussed decommissioning pulp-dev list in
> favor of of using Github Discussions[0] for developer discussions.
> > >
> > > If there are no objections, I plan to decommission the pulp-dev list
> next week.
> > >
> > > [0] https://github.com/pulp/community/discussions
> > >
> >
> > I don't know how I'd be able to keep track of what's going on with
> > GitHub Discussions. With mailing list discussions, it's relatively
> > easy for me to see the topics as they're coming in and participate off
> > the cuff. With GitHub Discussions, it doesn't seem possible for me to
> > do that.
> >
> >
> >
>
> Same here.  I prefer the e-mail list.  I almost never see the github spam
> messages because I get literally thousands...
>
> V/r,
> James Cassell
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Discussions

[David Davis]

One thing that might help is filtering by the repo name (ie pulp/community)
since it looks like you can’t filter out notifications for discussions from
other GitHub notifications currently unfortunately[0].

[0] https://github.com/github/feedback/discussions/59

On Wednesday, June 16, 2021, Daniel Alley  wrote:

> It's pretty hard to do filtering of GitHub mail...
>
>
> I can't disagree with that.
>
> On Wed, Jun 16, 2021 at 4:35 PM Neal Gompa  wrote:
>
>> Well, let's see if that works. Another concern I have is about
>> filtering stuff from discussions in Gmail. It's pretty hard to do
>> filtering of GitHub mail...
>>
>> On Wed, Jun 16, 2021 at 4:29 PM David Davis 
>> wrote:
>> >
>> > If you watch the repo, you should be able to get notifications when
>> there's new activity?
>> >
>> > David
>> >
>> >
>> > On Wed, Jun 16, 2021 at 3:13 PM Neal Gompa  wrote:
>> >>
>> >> On Wed, Jun 16, 2021 at 11:59 AM David Davis 
>> wrote:
>> >> >
>> >> > Yesterday at open floor, we discussed decommissioning pulp-dev list
>> in favor of of using Github Discussions[0] for developer discussions.
>> >> >
>> >> > If there are no objections, I plan to decommission the pulp-dev list
>> next week.
>> >> >
>> >> > [0] https://github.com/pulp/community/discussions
>> >> >
>> >>
>> >> I don't know how I'd be able to keep track of what's going on with
>> >> GitHub Discussions. With mailing list discussions, it's relatively
>> >> easy for me to see the topics as they're coming in and participate off
>> >> the cuff. With GitHub Discussions, it doesn't seem possible for me to
>> >> do that.
>> >>
>> >>
>> >>
>> >> --
>> >> 真実はいつも一つ！/ Always, there's only one truth!
>> >>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>

-- 

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

Re: [Pulp-dev] [Pulp-list] Github Discussions

[David Davis]

If you watch the repo, you should be able to get notifications when there's
new activity?

David


On Wed, Jun 16, 2021 at 3:13 PM Neal Gompa  wrote:

> On Wed, Jun 16, 2021 at 11:59 AM David Davis 
> wrote:
> >
> > Yesterday at open floor, we discussed decommissioning pulp-dev list in
> favor of of using Github Discussions[0] for developer discussions.
> >
> > If there are no objections, I plan to decommission the pulp-dev list
> next week.
> >
> > [0] https://github.com/pulp/community/discussions
> >
>
> I don't know how I'd be able to keep track of what's going on with
> GitHub Discussions. With mailing list discussions, it's relatively
> easy for me to see the topics as they're coming in and participate off
> the cuff. With GitHub Discussions, it doesn't seem possible for me to
> do that.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Github Discussions

[David Davis]

Based on feedback, I've moved discussions to its own repo:
https://github.com/pulp/community/discussions.

David


On Tue, May 25, 2021 at 1:49 PM David Davis  wrote:

> We've heard from the community about the amount of friction involved in
> getting help with Pulp and one of the areas I think we could improve is
> user communications. We currently run two mailing lists: pulp-list and
> pulp-dev.
>
> At today's open floor meeting, we talked about using Github's new
> Discussions feature[0] to host these conversations instead. I've set up a
> Discussion against pulpcore[1] for us to try but here's also an example of
> a project that has a lot of threads[2].
>
> I think the consensus was that we'd just keep pulpcore as our one and only
> Github Discussions instance, which would serve as a replacement for
> pulp-list and pulp-dev. I'd propose that we try this out for a bit and
> eventually decommission our mailing lists.
>
> [0] https://docs.github.com/en/discussions
> [1] https://github.com/pulp/pulpcore/discussions
> [2] https://github.com/vercel/next.js/discussions
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Python and django versions

[David Davis]

I started a discussion on Github about dropping support for Python 3.6 and
Django 2. Please respond with any comments/concerns/feedback.

https://github.com/pulp/pulpcore/discussions/1359

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

[Pulp-dev] Github Discussions

[David Davis]

We've heard from the community about the amount of friction involved in
getting help with Pulp and one of the areas I think we could improve is
user communications. We currently run two mailing lists: pulp-list and
pulp-dev.

At today's open floor meeting, we talked about using Github's new
Discussions feature[0] to host these conversations instead. I've set up a
Discussion against pulpcore[1] for us to try but here's also an example of
a project that has a lot of threads[2].

I think the consensus was that we'd just keep pulpcore as our one and only
Github Discussions instance, which would serve as a replacement for
pulp-list and pulp-dev. I'd propose that we try this out for a bit and
eventually decommission our mailing lists.

[0] https://docs.github.com/en/discussions
[1] https://github.com/pulp/pulpcore/discussions
[2] https://github.com/vercel/next.js/discussions

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

[Pulp-dev] Github Issues

[David Davis]

Over the past year, we've talked several times about moving off plan.io and
onto Github Issues. We've established that we need a plan for how to do so
though. I'd like to organize a meeting next week to come up with such a
plan. If you are interested in participating, please let me know today or
tomorrow.

Here is the feedback we collected from last year's PulpCon:

https://hackmd.io/bDIvv7wESa6BF99stLCI2Q

If you have any questions/concerns, please reach out to me. We'll be
sharing the plan and a timeline before we make any changes.

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

Re: [Pulp-dev] Docs day revamp

[David Davis]

Amazing job team!

Thank you Ina for organizing this.

David


On Thu, May 20, 2021 at 5:29 AM Ina Panova  wrote:

> Team,
> I would like to recapitulate yesterday's Docs day. In a day we managed to
> knock down 12 issues [0].
>
> Great job! Thanks to everyone who participated whether by submitting or
> reviewing PRs.
>
> [0] https://tinyurl.com/rsv7m4c2
>
> 
> 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, May 19, 2021 at 3:11 PM Robin Chan  wrote:
>
>> I went ahead and saved it:
>> https://pulp.plan.io/issues?query_id=174
>> And should show up in the named queries on the right hand side
>> And I'm seeing 16 items now.
>>
>> Robin Chan
>>
>> She/Her/Hers
>>
>> Satellite Software Engineering Manager - Pulp
>>
>> Asian Network Co-Chair
>>
>> Red Hat <https://www.redhat.com>
>>
>> IRC: rchan
>>
>> Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> <https://www.redhat.com> [image:
>> https://source.redhat.com/communitiesatredhat/diversity_and_inclusion/asian_network]
>> <https://source.redhat.com/communitiesatredhat/diversity_and_inclusion/asian_network>
>> May is Asian Pacific American Heritage Month.
>> <https://source.redhat.com/communitiesatredhat/diversity_and_inclusion/asian_network/asian_pacific_american_heritage_month_2021>
>>  We
>> recognize and celebrate the contributions of Asians and Pacific Islanders
>> to American society and culture.
>>
>>
>> On Wed, May 19, 2021 at 8:18 AM David Davis 
>> wrote:
>>
>>> Awesome, thanks for organizing this and putting together a query.
>>>
>>> David
>>>
>>>
>>> On Tue, May 18, 2021 at 11:54 AM Ina Panova  wrote:
>>>
>>>> The Pulpcore team met today and went a bit through the docs backlog.
>>>>
>>>> Here is the query with the list of  docs issues we are going to focus
>>>> tomorrow May 19 https://tinyurl.com/ymctcr32
>>>>
>>>> 
>>>> 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, May 5, 2021 at 2:05 PM Ina Panova  wrote:
>>>>
>>>>> I have marked May 19th in the outage calendar as Pulp Docs Day.
>>>>>
>>>>> 
>>>>> 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 Thu, Apr 29, 2021 at 12:54 PM David Davis 
>>>>> wrote:
>>>>>
>>>>>> Sounds good to me. Thank you for organizing this.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 29, 2021 at 5:47 AM Ina Panova 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Historically we have had Docs Day before a release so we can get
>>>>>>> some more docs PRs in. But this did not work out well for us because of 
>>>>>>> all
>>>>>>> the amount of work and commitments we had to fulfill just before the
>>>>>>> release date. Our focus was somewhere else which is understandable.
>>>>>>>
>>>>>>> There is a new suggestion to organize Docs Day that would not be
>>>>>>> aligned to any release date. Folks would feel less stressed and have 
>>>>>>> more
>>>>>>> time to actually prioritize docs issues.
>>>>>>>
>>>>>>> Currently there are 73 doc issues spread across Pulp in the plan.io
>>>>>>> [0]
>>>>>>> And only 2 doc issues marked for the Q2 2021.
>>>>>>>
>>>>>>> I am suggesting each mini team, in preparation for the Docs Day to
>>>>>>> take an action item 

Re: [Pulp-dev] Docs day revamp

[David Davis]

Awesome, thanks for organizing this and putting together a query.

David


On Tue, May 18, 2021 at 11:54 AM Ina Panova  wrote:

> The Pulpcore team met today and went a bit through the docs backlog.
>
> Here is the query with the list of  docs issues we are going to focus
> tomorrow May 19 https://tinyurl.com/ymctcr32
>
> 
> 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, May 5, 2021 at 2:05 PM Ina Panova  wrote:
>
>> I have marked May 19th in the outage calendar as Pulp Docs Day.
>>
>> 
>> 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 Thu, Apr 29, 2021 at 12:54 PM David Davis 
>> wrote:
>>
>>> Sounds good to me. Thank you for organizing this.
>>>
>>> David
>>>
>>>
>>> On Thu, Apr 29, 2021 at 5:47 AM Ina Panova  wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Historically we have had Docs Day before a release so we can get some
>>>> more docs PRs in. But this did not work out well for us because of all the
>>>> amount of work and commitments we had to fulfill just before the release
>>>> date. Our focus was somewhere else which is understandable.
>>>>
>>>> There is a new suggestion to organize Docs Day that would not be
>>>> aligned to any release date. Folks would feel less stressed and have more
>>>> time to actually prioritize docs issues.
>>>>
>>>> Currently there are 73 doc issues spread across Pulp in the plan.io [0]
>>>> And only 2 doc issues marked for the Q2 2021.
>>>>
>>>> I am suggesting each mini team, in preparation for the Docs Day to take
>>>> an action item and go through the backlog and mark issues for the Q2 2021.
>>>> Projects that are moved to github issues can apply an appropriate label.
>>>>
>>>> The proposed date for the next iteration of Docs Day would be May 19.
>>>> By that time we should be over a pulpcore 3.13 release and the temperature
>>>> should be relatively low.
>>>>
>>>> Suggestions are welcome.
>>>>
>>>> [0] https://tinyurl.com/r492c8s
>>>> [1] https://tinyurl.com/ymctcr32
>>>>
>>>> 
>>>> 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://listman.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] pulp-cli 0.9.0 is generally available

[David Davis]

pulp-cli 0.9.0 has been released to PyPI[0]. It is considered beta software
until it reaches its 1.0 release. Future releases will likely break
compatibility.

The 0.9.0 release includes a bugfix caused by the recent release of click 8
as well as a setting for dry_run, better handling of redirects/responses,
and validation of settings when creating/editing the settings config.

See the changelog for all changes[1]. For help installing and configuring
the CLI, see the docs[2].

If you find any bugs or want to suggest features, please file an issue on
Github[3].

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli/blob/develop/CHANGES.rst
[2] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[3] https://github.com/pulp/pulp-cli/issues

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

Re: [Pulp-dev] pulp_rpm and current backwards-compatibility problems

[David Davis]

Ah I see that you will be reordering migrations. Nevermind my idea. I think
you have the right plan.

David


On Tue, May 11, 2021 at 1:02 PM David Davis  wrote:

> What if you create a 3.11 release branch and then revert the commits on
> the 3.11 branch? That would save you from having to reapply the two
> commits.
>
> You could also pin to pulpcore < 3.12 on the 3.11 branch to get the branch
> passing while you work on fixing the enqueue problem on master.
>
> David
>
>
> On Tue, May 11, 2021 at 11:49 AM Grant Gainey  wrote:
>
>> Hey folks,
>>
>> We've been talking about how we need a pulpcore/3.7-to-3.11-compatible
>> release of pulp_rpm. The static_context change requires a schema-change,
>> and it has to be available to katello-3.18 (and hence pulpcore-3.7)
>>
>> The static_context change is PR#1984
>> <https://github.com/pulp/pulp_rpm/pull/1984>
>>
>> Right now, pulp-rpm/master has changes that require pulpcore/3.12 or
>> later. Those changes are:
>>
>> d0c9badd Refactor distribution migration 0032
>> fbaadaca Add support for automatic publishing and distributing
>>
>> In addition, pulp_rpm/master is *currently broken* because it still
>> references the deprecated enqueue_with_reservation(), that just got removed
>> from pulpcore/master.
>>
>> As I understand it, what needs to happen #SOON, is the following:
>>
>>1. revert the two commits above and merge,
>>2. get the static_context change updated (since a migration will have
>>Left the Building) and get it merged,
>>3. merge any other fixes that won't break 3.7-compat [OPTIONAL], and
>>THEN
>>4. cut 3.11 as compatible with 3.7-thru-3.10 pulpcore
>>
>> Once pulp_rpm/3.11 is released, we can then:
>>
>>1. re-apply the auto-pub/dist-schema changes,
>>2. fix enqueue-problem,
>>3. mark pulp_rpm/master as 3.12+ compat, and finally
>>4. release pulp_rpm/3.12 to be ready for pulpcore-3.13
>>
>> And this all needs to happen by next week?
>>
>> Is there anything I'm missing here?
>>
>> G
>> --
>> Grant Gainey
>> Principal Software Engineer, Red Hat System Management Engineering
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulp_rpm and current backwards-compatibility problems

[David Davis]

What if you create a 3.11 release branch and then revert the commits on the
3.11 branch? That would save you from having to reapply the two commits.

You could also pin to pulpcore < 3.12 on the 3.11 branch to get the branch
passing while you work on fixing the enqueue problem on master.

David


On Tue, May 11, 2021 at 11:49 AM Grant Gainey  wrote:

> Hey folks,
>
> We've been talking about how we need a pulpcore/3.7-to-3.11-compatible
> release of pulp_rpm. The static_context change requires a schema-change,
> and it has to be available to katello-3.18 (and hence pulpcore-3.7)
>
> The static_context change is PR#1984
> 
>
> Right now, pulp-rpm/master has changes that require pulpcore/3.12 or
> later. Those changes are:
>
> d0c9badd Refactor distribution migration 0032
> fbaadaca Add support for automatic publishing and distributing
>
> In addition, pulp_rpm/master is *currently broken* because it still
> references the deprecated enqueue_with_reservation(), that just got removed
> from pulpcore/master.
>
> As I understand it, what needs to happen #SOON, is the following:
>
>1. revert the two commits above and merge,
>2. get the static_context change updated (since a migration will have
>Left the Building) and get it merged,
>3. merge any other fixes that won't break 3.7-compat [OPTIONAL], and
>THEN
>4. cut 3.11 as compatible with 3.7-thru-3.10 pulpcore
>
> Once pulp_rpm/3.11 is released, we can then:
>
>1. re-apply the auto-pub/dist-schema changes,
>2. fix enqueue-problem,
>3. mark pulp_rpm/master as 3.12+ compat, and finally
>4. release pulp_rpm/3.12 to be ready for pulpcore-3.13
>
> And this all needs to happen by next week?
>
> Is there anything I'm missing here?
>
> G
> --
> Grant Gainey
> Principal Software Engineer, Red Hat System Management Engineering
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] How to enable HTTPS for our tests in pulpcore and all plugins?

[David Davis]

I feel like ideally, https would be the default (ie latest). However, then
we are going to break all the release branches for pulpcore and plugins
that are pointing to latest but not expecting https.

Hopefully people will weigh in here.

David


On Fri, May 7, 2021 at 11:55 AM Fabricio Aguiar  wrote:

>
>
> On Fri, May 7, 2021 at 11:52 AM David Davis  wrote:
>
>> To confirm, the "latest" tag will continue to ship with http? I imagine
>> most users will end up with http then.
>>
> I can modify the PR and make https the default
>
>>
>> Also, what (if anything) do we do about y release tags (e.g. the upcoming
>> 3.13 tag)? Do they continue to ship with http?
>>
> I think release tags can be https
>
>>
>> David
>>
>>
>> On Fri, May 7, 2021 at 10:51 AM Brian Bouterse 
>> wrote:
>>
>>> a yis
>>>
>>> On Fri, May 7, 2021 at 10:46 AM Fabricio Aguiar 
>>> wrote:
>>>
>>>> I changed https://github.com/pulp/pulp-oci-images/pull/73 to ship both,
>>>> latest as is, and the new tag: https
>>>>
>>>> Best regards,
>>>> Fabricio Aguiar
>>>> Software Engineer, Pulp Project
>>>> Red Hat Brazil - Latam <https://www.redhat.com/>
>>>> +55 22 999000595
>>>>
>>>>
>>>>
>>>> On Fri, May 7, 2021 at 11:41 AM Brian Bouterse 
>>>> wrote:
>>>>
>>>>> +1 to this observation, we probably need to either ship both or make
>>>>> it configurable somehow. Shipping both is probably easier on users.
>>>>>
>>>>> On Fri, May 7, 2021 at 5:11 AM Matthias Dellweg 
>>>>> wrote:
>>>>>
>>>>>> This is a great piece of work!
>>>>>> The problem I see is that the SSL free container image may be used in
>>>>>> places we do not control. And having this http based container equipped
>>>>>> with an external https reverse proxy is imho a valid use case.
>>>>>> Therefore i would prefer, if we could provide both versions of the
>>>>>> image (with and without SSL) as different tags.
>>>>>> This would also give us the opportunity to switch the plugins one by
>>>>>> one to use the new container.
>>>>>> Ideally, the SSL container would be a thin OCI-layer on top of the
>>>>>> http version.
>>>>>>
>>>>>> On Thu, May 6, 2021 at 10:10 PM Fabricio Aguiar 
>>>>>> wrote:
>>>>>>
>>>>>>> I finally made pulp_container CI work with https,
>>>>>>> I also did some changes on pulp_installer, I believe these changes
>>>>>>> will make it possible to run functional tests on dev environment.
>>>>>>>
>>>>>>> I think now it is a matter of deciding when is the best time to
>>>>>>> merge the PR on the single container and if latest tag should be https 
>>>>>>> or
>>>>>>> not
>>>>>>>
>>>>>>> PRs:
>>>>>>> https://github.com/pulp/pulp-oci-images/pull/73
>>>>>>> https://github.com/pulp/pulp_installer/pull/614
>>>>>>> https://github.com/pulp/plugin_template/pull/379
>>>>>>> https://github.com/pulp/pulpcore/pull/1283
>>>>>>> https://github.com/pulp/pulp_container/pull/304
>>>>>>> https://github.com/pulp/pulp_rpm/pull/1977
>>>>>>> https://github.com/pulp/pulp_ansible/pull/572
>>>>>>> https://github.com/pulp/pulp-2to3-migration/pull/362
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Fabricio Aguiar
>>>>>>> Software Engineer, Pulp Project
>>>>>>> Red Hat Brazil - Latam <https://www.redhat.com/>
>>>>>>> +55 22 999000595
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 27, 2021 at 5:35 PM Fabricio Aguiar 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I created https branch:
>>>>>>>> https://github.com/pulp/pulp-oci-images/tree/https
>>>>>>>> and pushed the following images:
>>>>>>>> - pulp/pulp-ci-centos:https
>>>>>>>> - pulp/pulp:https
>>>>>>>>
>>>>>>>> Now we

Re: [Pulp-dev] How to enable HTTPS for our tests in pulpcore and all plugins?

[David Davis]

To confirm, the "latest" tag will continue to ship with http? I imagine
most users will end up with http then.

Also, what (if anything) do we do about y release tags (e.g. the upcoming
3.13 tag)? Do they continue to ship with http?

David


On Fri, May 7, 2021 at 10:51 AM Brian Bouterse  wrote:

> a yis
>
> On Fri, May 7, 2021 at 10:46 AM Fabricio Aguiar 
> wrote:
>
>> I changed https://github.com/pulp/pulp-oci-images/pull/73 to ship both,
>> latest as is, and the new tag: https
>>
>> Best regards,
>> Fabricio Aguiar
>> Software Engineer, Pulp Project
>> Red Hat Brazil - Latam <https://www.redhat.com/>
>> +55 22 999000595
>>
>>
>>
>> On Fri, May 7, 2021 at 11:41 AM Brian Bouterse 
>> wrote:
>>
>>> +1 to this observation, we probably need to either ship both or make it
>>> configurable somehow. Shipping both is probably easier on users.
>>>
>>> On Fri, May 7, 2021 at 5:11 AM Matthias Dellweg 
>>> wrote:
>>>
>>>> This is a great piece of work!
>>>> The problem I see is that the SSL free container image may be used in
>>>> places we do not control. And having this http based container equipped
>>>> with an external https reverse proxy is imho a valid use case.
>>>> Therefore i would prefer, if we could provide both versions of the
>>>> image (with and without SSL) as different tags.
>>>> This would also give us the opportunity to switch the plugins one by
>>>> one to use the new container.
>>>> Ideally, the SSL container would be a thin OCI-layer on top of the http
>>>> version.
>>>>
>>>> On Thu, May 6, 2021 at 10:10 PM Fabricio Aguiar 
>>>> wrote:
>>>>
>>>>> I finally made pulp_container CI work with https,
>>>>> I also did some changes on pulp_installer, I believe these changes
>>>>> will make it possible to run functional tests on dev environment.
>>>>>
>>>>> I think now it is a matter of deciding when is the best time to merge
>>>>> the PR on the single container and if latest tag should be https or not
>>>>>
>>>>> PRs:
>>>>> https://github.com/pulp/pulp-oci-images/pull/73
>>>>> https://github.com/pulp/pulp_installer/pull/614
>>>>> https://github.com/pulp/plugin_template/pull/379
>>>>> https://github.com/pulp/pulpcore/pull/1283
>>>>> https://github.com/pulp/pulp_container/pull/304
>>>>> https://github.com/pulp/pulp_rpm/pull/1977
>>>>> https://github.com/pulp/pulp_ansible/pull/572
>>>>> https://github.com/pulp/pulp-2to3-migration/pull/362
>>>>>
>>>>> Best regards,
>>>>> Fabricio Aguiar
>>>>> Software Engineer, Pulp Project
>>>>> Red Hat Brazil - Latam <https://www.redhat.com/>
>>>>> +55 22 999000595
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 27, 2021 at 5:35 PM Fabricio Aguiar 
>>>>> wrote:
>>>>>
>>>>>> I created https branch:
>>>>>> https://github.com/pulp/pulp-oci-images/tree/https
>>>>>> and pushed the following images:
>>>>>> - pulp/pulp-ci-centos:https
>>>>>> - pulp/pulp:https
>>>>>>
>>>>>> Now we can test on the plugins,
>>>>>> I followed your suggestion and did it on pulp_npm:
>>>>>> https://github.com/pulp/pulp_npm/pull/89
>>>>>>
>>>>>> Best regards,
>>>>>> Fabricio Aguiar
>>>>>> Software Engineer, Pulp Project
>>>>>> Red Hat Brazil - Latam <https://www.redhat.com/>
>>>>>> +55 22 999000595
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 27, 2021 at 9:25 AM David Davis 
>>>>>> wrote:
>>>>>>
>>>>>>> This is great. Thank you for working on it.
>>>>>>>
>>>>>>> As a next step, would it make sense to create a branch and then try
>>>>>>> to deploy a new temporary tag from that branch? Then maybe we can test a
>>>>>>> plugin (eg pulp_npm) against this new image and see what breaks.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 26, 2021 at 5:01 PM Fabricio Aguiar 
&

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# May 4, 2021

## Topics
* New pulpcore meeting lead?
  * New lead rotation
* BaseDistribution drop migration problem
* https://pulp.plan.io/issues/8386#note-5
* Problem: using `run_before` prevents new plugins from being installed
* David to confirm that `run_before` won't work
* pulpcore meeting x open floor
* Goal: be more mindful of which topics can be discussed at open floor
* 3.13 - https://pulp.plan.io/versions/188
* dalley to release (bmbouter if release gets delayed past may 17)
* https://pulp.plan.io/issues/8656
* Django 2.2.21 introduced a change which breaks any workflows which use
stages API
* filename validation for file field fails
* https://docs.djangoproject.com/en/2.2/releases/2.2.21/
* individual orphan removal needs grooming
* https://pulp.plan.io/issues/8658
* prep for Docs day
* Installer release
* https://github.com/pulp/pulp_installer/pull/568
* Lately installer has been released by pulpcore team members
* Feedback from pulpcore people are welcome!

## Action Items
* [david] test out run_before for https://pulp.plan.io/issues/8386#note-5

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

Re: [Pulp-dev] Tracking issues for plugin_template

[David Davis]

Interesting. I did not know about this. Here's a link with more info:

https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

David


On Fri, Apr 30, 2021 at 11:34 AM Ewoud Kohl van Wijngaarden <
ewoud+p...@kohlvanwijngaarden.nl> wrote:

> On Sat, Apr 24, 2021 at 09:21:05PM -0400, Daniel Alley wrote:
> >On Fri, Apr 23, 2021 at 10:37 AM David Davis 
> wrote:
> >
> >> We started working on a plan to move repos over to Github Issues after
> >> PulpCon last year but I think it kind of fell by the wayside over the
> past
> >> few months due to how busy we've been with stakeholder work. It would
> >> definitely be a requirement in my mind to sort out things like how to
> link
> >> BZs to issues before moving plugins and other repos over to Gihub Issues
> >> that might have issues that affect downstream.
> >
> >I doubt there's any "good" way to link external bugs from Github because
> >Mozilla doesn't do so.  They just add an extra tag and you just have to
> >find the link somewhere in the comments.
> >
> >e.g.
> >
> https://github.com/servo/webrender/issues?q=is%3Aopen+is%3Aissue+label%3Abugzilled
> >
>
> If you're on a paid plan you can replace links to an external system. I
> can't find exactly where since it's hell to search for, but an example
> can be seen in https://github.com/puppetlabs/puppet where PUP-NNN links
> to their JIRA instance.
>
> It looks like it doesn't replace it everywhere as can be seen in a
> random PR: https://github.com/puppetlabs/facter/pull/2371
>
> Certainly this isn't great.
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Docs day revamp

[David Davis]

Sounds good to me. Thank you for organizing this.

David


On Thu, Apr 29, 2021 at 5:47 AM Ina Panova  wrote:

> Hi everyone,
>
> Historically we have had Docs Day before a release so we can get some more
> docs PRs in. But this did not work out well for us because of all the
> amount of work and commitments we had to fulfill just before the release
> date. Our focus was somewhere else which is understandable.
>
> There is a new suggestion to organize Docs Day that would not be aligned
> to any release date. Folks would feel less stressed and have more time to
> actually prioritize docs issues.
>
> Currently there are 73 doc issues spread across Pulp in the plan.io [0]
> And only 2 doc issues marked for the Q2 2021.
>
> I am suggesting each mini team, in preparation for the Docs Day to take an
> action item and go through the backlog and mark issues for the Q2 2021.
> Projects that are moved to github issues can apply an appropriate label.
>
> The proposed date for the next iteration of Docs Day would be May 19. By
> that time we should be over a pulpcore 3.13 release and the temperature
> should be relatively low.
>
> Suggestions are welcome.
>
> [0] https://tinyurl.com/r492c8s
> [1] https://tinyurl.com/ymctcr32
>
> 
> 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://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulpcore team meeting

[David Davis]

# April 27, 2021

## Topics
* Migration issue on galaxy
* https://github.com/pulp/pulpcore/pull/1174
* During migration it went out of memory
* Worries about migration breaking in the future when model(s) change
* Need better testing around upgrades
* 3.13 - https://pulp.plan.io/versions/188
* Revisit next week
* Move from `gnupg` to `pretty-bad-protocol`?
  * https://github.com/isislovecruft/python-gnupg
* 3.12.2/3.7.6 to release
* Investigating another potential issue
* Katello hits this 75% of the time on el8 runs
*  https://pulp.plan.io/issues/8603
*  daviddavis will look into it
* Testing the waters on removing RemoteArtifact
* TL;DR what if we just use "Artifact" + a small table for remote
sources, validated by constraints rather than a separate table schema.
*
https://github.com/pulp/pulpcore/compare/master...dralley:delete-remoteartifact#diff-81f6a78175bb93934b6beff952646d3ca1ef3731f1ff14492d4ec77bfc3fdf82R224-R241
* Fixes https://pulp.plan.io/issues/8305
* Simplifies working w/ artifacts
* can filter Artifact by whether it's on_demand or not
* update artifacts in-place when files are downloaded
* delete "RemoteArtifactSaver" stage and
_needed_remote_artifacts()
* I have a prototype that works for sync, should I invest more time in
it?
* Review old quarter open issues
  * https://tinyurl.com/pulpq12021

## Action Items
* [fao89] look at upgrade testing
* [fao89] find timeline for https://pulp.plan.io/issues/8192

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

Re: [Pulp-dev] How to enable HTTPS for our tests in pulpcore and all plugins?

[David Davis]

This is great. Thank you for working on it.

As a next step, would it make sense to create a branch and then try to
deploy a new temporary tag from that branch? Then maybe we can test a
plugin (eg pulp_npm) against this new image and see what breaks.

David


On Mon, Apr 26, 2021 at 5:01 PM Fabricio Aguiar  wrote:

> I started this POC: https://github.com/pulp/pulp-oci-images/pull/73
> It enables https on the single container, once merged, the CI for every
> plugin will run the functional tests using https.
> Probably it would break the majority of the CIs, we need to discuss when
> is the best moment to merge this PR or discuss alternatives
>
> Best regards,
> Fabricio Aguiar
> Software Engineer, Pulp Project
> Red Hat Brazil - Latam 
> +55 22 999000595
>
>
>
> On Tue, Feb 9, 2021 at 10:55 AM Fabricio Aguiar 
> wrote:
>
>> Our nginx conf only supports http now:
>> https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf#L15
>> For not breaking all plugins, I believe we can build a new CI image that
>> supports https.
>> Maybe a template_config parameter - test_https: true would switch the
>> images
>>
>> Best regards,
>> Fabricio Aguiar
>> Software Engineer, Pulp Project
>> Red Hat Brazil - Latam 
>> +55 22 999000595
>>
>>
>>
>> On Tue, Feb 9, 2021 at 5:16 AM Matthias Dellweg 
>> wrote:
>>
>>> I believe this is at least solving the problem partially:
>>>
>>> https://github.com/pulp/pulp-smash/pull/1251
>>>
>>> On Mon, Feb 8, 2021 at 9:48 PM Brian Bouterse 
>>> wrote:
>>>
 I believe all of our plugins (and CI) require HTTP and do not work with
 HTTPS. I'm not well versed in what needs to be done to fix this, but I
 think we should fix it.

 Can the CI group have a 30 min call to talk over what needs to be done?
 Or maybe share some info here?

 The main issue I'm aware of is that the tests are not prepared to trust
 an https certificate that is self-signed. I'm not exactly sure where we can
 change that in one place either.

 Thanks!
 Brian



 ___
 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://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Tracking issues for plugin_template

[David Davis]

We started working on a plan to move repos over to Github Issues after
PulpCon last year but I think it kind of fell by the wayside over the past
few months due to how busy we've been with stakeholder work. It would
definitely be a requirement in my mind to sort out things like how to link
BZs to issues before moving plugins and other repos over to Gihub Issues
that might have issues that affect downstream.

There is a way to view issues across the entire Pulp org in Github[0] but
it's not great. Definitely not as good as the redmine issue search. We
should figure out if it'll meet our needs and if not, find a  solution that
will.

[0]
https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Apulp+

David


On Thu, Apr 22, 2021 at 7:42 AM Grant Gainey  wrote:

> On Thu, Apr 22, 2021 at 6:48 AM Ina Panova  wrote:
>
>>
>> On Wed, Apr 21, 2021 at 7:55 PM David Davis 
>> wrote:
>>
>>> Wanted to bump this to hopefully get some feedback. Also, today during
>>> our CI/CD meeting we discussed also tracking issues for pulp-oci-images on
>>> github as well.
>>>
>>> If there are no objections by next week April 26, I'll assume I can
>>> proceed with moving these projects' issues over to Github.
>>>
>>> David
>>>
>>>
>> I have no objections regarding moving plugin_template and pulp-oci-images
>> to github.
>>
>> The question I have is - what is our long term goal? Do we aim to
>> eventually move all of the projects from pulp.plan.io? I know there were
>> discussions in the past but we have not found a solution on how to connect
>> issues with downstream trackers. The concern I have, if we don't have such
>> plan, then we might have plugins' issue tracking scattered between
>> plan.io and github where users, as a result, will file issues in the
>> redmine and then we will need to whether ask them to open a github issue or
>> do it ourselves.
>> We just had a python issue filed in the redmine last week.
>>
>
> This is a good point. I just looked at bugzilla, and 'Github' is listed as
> one of the Systems you can "Add Link" to. We'd (obviously) need to modify
> the linking/state-change-scripts. The complicating issues I can see there,
> are a) not having moved *all* the projects to github, so some BZs would
> want links to redmine and some to github, and b) being able to get "all"
> the issues - in redmine, I can go to pulp.plan.io/issues and see all the
> issues for every project, not sure we can get something equivalent from
> github.
>
> G
>
>
>>
>>> On Fri, Apr 16, 2021 at 8:38 AM David Davis 
>>> wrote:
>>>
>>>> I've always felt that tracking plugin_template issues under the main
>>>> pulp project in plan.io was suboptimal and with other repos such as
>>>> pulp-cli moving to github issues, I feel that it might make sense for the
>>>> plugin_template to move to github issues as well.
>>>>
>>>> There's only 11 open issues right now in pulp.plan.io? for the
>>>> plugin_template so I think it would be an easy move. I'd propose we also
>>>> remove the plugin_template tag from the list of options (but keep it on old
>>>> issues for history).
>>>>
>>>> Thoughts?
>>>>
>>>> David
>>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
> Grant Gainey
> Principal Software Engineer, Red Hat System Management Engineering
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulpcore meeting notes

[David Davis]

I'm interested to hear more about the label. Who sets it? And how is it
enforced?

Also an observation in Pulp: we tend to merge features right before a
release. If we want these demo videos to be part of the release
announcement, we'd either have to hold up the release announcement (not
great) or release the announcement without the demo videos (which maybe
defeats the purpose of the demo videos?).

David


On Fri, Apr 23, 2021 at 4:48 AM Melanie Corr  wrote:

> Hey David,
>
> Ar Déar 22 Aib 2021 ag 16:14, scríobh David Davis :
>
>>
>> On Tue, Apr 20, 2021 at 10:13 AM Melanie Corr  wrote:
>>
>>> Hi !
>>>
>>> Ar Máirt 20 Aib 2021 ag 15:02, scríobh David Davis <
>>> davidda...@redhat.com>:
>>>
>>>> # April 20, 2021
>>>>
>>>> ## Topics
>>>> * Demo videos?
>>>> * Was asked about a demo video for a feature
>>>> * I guess we're not doing these anymore?
>>>> * Fail to record anything due to capacity and commitments
>>>> * Record demos ad hoc?
>>>> * Ask feature writer to record demo when stakeholder asks for
>>>> one
>>>>
>>>
>>> I still think it would be easier for me to share updates and features
>>> with the community if there were short demos.
>>>
>>
>> Agree here. I've been trying to record demo videos for new features
>> whenever I implement them.
>>
> Your demos are great. daviddavis++
>
>
>>
>>>
>>> Can I be a stakeholder asking for demos?
>>>
>>
>> No objection from me.
>>
>
> By me, I should clarify that I mean the community as a stakeholder.
>
> As Pulp has a number of projects interacting with it, I try to improve the
> release announcements so it's easier for stakeholders and the wider
> community to understand the headline features and the purpose of
> implementing them in pulpcore. Small demos of the headline features, in
> many instances, would help.
>
>
>>
>>>
>>> So, should I remove the request for a demo from the contributor
>>> guidelines?
>>>
>>
>> At the very least, we should at least keep the information about how to
>> record a demo video.
>>
>
> Last October/November, we added the need for demos per substantial change
> to our contribution guidelines. Neither PR contributors nor reviewers seems
> to have enforced this guideline. I've no doubt that there are a number of
> valid reasons for this, with the most obvious and ultimate reason being
> time.
> I understand that a lot of the features in Pulpcore are probably more
> demoable when a plugin starts to avail of the features.
> Perhaps there might be a cleverer way to select which demo would be worthy
> of contributor time.
> In Foreman, a PR can have the label "demo-worthy" assigned to it.
> Would something like this work better?
>
>>
>>
>>>
>>> * Releasing https://pulp.plan.io/issues/8578
>>>> * Problem: BaseDistribution is deprecated but plugin api is missing
>>>> RepositoryVersionRelatedField
>>>> * 3.12.1 or early/small 3.13.0?
>>>> * bumping minor release would cause extra churn
>>>> * 3.13 - https://pulp.plan.io/versions/188
>>>> * Needs date and release lead (rotation on lines 10-11)
>>>> * make distribution update synchronous https://pulp.plan.io/issues/7762
>>>> * rhui would like to dev freeze by may
>>>> * Streamed endpoints
>>>> * https://github.com/pulp/pulp_ansible/pull/562
>>>> * faster
>>>> * query evaluation
>>>> * gunicorn timeout - blocks API worker
>>>> * Review old quarter open issues
>>>> * https://tinyurl.com/pulpq42020
>>>>
>>>> ## Action Items
>>>> * [david] release 3.12.1 with https://pulp.plan.io/issues/8578
>>>> * [dalley] confirm with rhui if https://pulp.plan.io/issues/7762 is
>>>> still needed given auto-publish/auto-distribute and on the their Dev Freeze
>>>> timeline
>>>> * [david] look at the pulp-oci-images and redmine integration
>>>>
>>>> David
>>>> ___
>>>> Pulp-dev mailing list
>>>> Pulp-dev@redhat.com
>>>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>
>>>
>>> --
>>>
>>> Melanie Corr, RHCE
>>>
>>> Community Manager
>>>
>>> Red Hat <https://www.redhat.com>
>>>
>>> Remote, Ireland
>>>
>>> mc...@redhat.com
>>> M: +353857774436 IM: mcorr
>>> <https://www.redhat.com>
>>>
>>>
>
> --
>
> Melanie Corr, RHCE
>
> Community Manager
>
> Red Hat <https://www.redhat.com>
>
> Remote, Ireland
>
> mc...@redhat.com
> M: +353857774436 IM: mcorr
> <https://www.redhat.com>
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulpcore meeting notes

[David Davis]

On Tue, Apr 20, 2021 at 10:13 AM Melanie Corr  wrote:

> Hi !
>
> Ar Máirt 20 Aib 2021 ag 15:02, scríobh David Davis  >:
>
>> # April 20, 2021
>>
>> ## Topics
>> * Demo videos?
>> * Was asked about a demo video for a feature
>> * I guess we're not doing these anymore?
>> * Fail to record anything due to capacity and commitments
>> * Record demos ad hoc?
>> * Ask feature writer to record demo when stakeholder asks for one
>>
>
> I still think it would be easier for me to share updates and features with
> the community if there were short demos.
>

Agree here. I've been trying to record demo videos for new features
whenever I implement them.


>
> Can I be a stakeholder asking for demos?
>

No objection from me.


>
> Do they take that long to record with asciinema?
>

No, it's rather simple/easy. Once you get the hang of it, it only takes
about an hour.


>
> So, should I remove the request for a demo from the contributor guidelines?
>

At the very least, we should at least keep the information about how to
record a demo video.


>
> * Releasing https://pulp.plan.io/issues/8578
>> * Problem: BaseDistribution is deprecated but plugin api is missing
>> RepositoryVersionRelatedField
>> * 3.12.1 or early/small 3.13.0?
>> * bumping minor release would cause extra churn
>> * 3.13 - https://pulp.plan.io/versions/188
>> * Needs date and release lead (rotation on lines 10-11)
>> * make distribution update synchronous https://pulp.plan.io/issues/7762
>> * rhui would like to dev freeze by may
>> * Streamed endpoints
>> * https://github.com/pulp/pulp_ansible/pull/562
>> * faster
>> * query evaluation
>> * gunicorn timeout - blocks API worker
>> * Review old quarter open issues
>> * https://tinyurl.com/pulpq42020
>>
>> ## Action Items
>> * [david] release 3.12.1 with https://pulp.plan.io/issues/8578
>> * [dalley] confirm with rhui if https://pulp.plan.io/issues/7762 is
>> still needed given auto-publish/auto-distribute and on the their Dev Freeze
>> timeline
>> * [david] look at the pulp-oci-images and redmine integration
>>
>> David
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
>
> Melanie Corr, RHCE
>
> Community Manager
>
> Red Hat <https://www.redhat.com>
>
> Remote, Ireland
>
> mc...@redhat.com
> M: +353857774436 IM: mcorr
> <https://www.redhat.com>
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] CI/CD meeting notes

[David Davis]

## April 21, 2021

* Moving plugin_template to github issues?
* https://listman.redhat.com/archives/pulp-dev/2021-April/msg00019.html
* pulp-oci-image changes not updating redmine
* Enable github/redmine integration
* Or track issues on github?
* Releasing pulp_installer is tedious/cumbersome
* Automate building/publishing the collection?
*
https://dev.to/imjoseangel/release-and-deploy-ansible-collection-with-github-actions-4a62
* Already done. Need to add a note to the release doc that it's
only needed for older branches.
* Can run "make dist" to build the collection
* New workers in the CI
* https://github.com/pulp/pulp-oci-images/pull/71
* Checked failing CI jobs

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

Re: [Pulp-dev] Tracking issues for plugin_template

[David Davis]

Wanted to bump this to hopefully get some feedback. Also, today during our
CI/CD meeting we discussed also tracking issues for pulp-oci-images on
github as well.

If there are no objections by next week April 26, I'll assume I can proceed
with moving these projects' issues over to Github.

David


On Fri, Apr 16, 2021 at 8:38 AM David Davis  wrote:

> I've always felt that tracking plugin_template issues under the main pulp
> project in plan.io was suboptimal and with other repos such as pulp-cli
> moving to github issues, I feel that it might make sense for the
> plugin_template to move to github issues as well.
>
> There's only 11 open issues right now in pulp.plan.io for the
> plugin_template so I think it would be an easy move. I'd propose we also
> remove the plugin_template tag from the list of options (but keep it on old
> issues for history).
>
> Thoughts?
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulpcore meeting notes

[David Davis]

# April 20, 2021

## Topics
* Demo videos?
* Was asked about a demo video for a feature
* I guess we're not doing these anymore?
* Fail to record anything due to capacity and commitments
* Record demos ad hoc?
* Ask feature writer to record demo when stakeholder asks for one
* Releasing https://pulp.plan.io/issues/8578
* Problem: BaseDistribution is deprecated but plugin api is missing
RepositoryVersionRelatedField
* 3.12.1 or early/small 3.13.0?
* bumping minor release would cause extra churn
* 3.13 - https://pulp.plan.io/versions/188
* Needs date and release lead (rotation on lines 10-11)
* make distribution update synchronous https://pulp.plan.io/issues/7762
* rhui would like to dev freeze by may
* Streamed endpoints
* https://github.com/pulp/pulp_ansible/pull/562
* faster
* query evaluation
* gunicorn timeout - blocks API worker
* Review old quarter open issues
* https://tinyurl.com/pulpq42020

## Action Items
* [david] release 3.12.1 with https://pulp.plan.io/issues/8578
* [dalley] confirm with rhui if https://pulp.plan.io/issues/7762 is still
needed given auto-publish/auto-distribute and on the their Dev Freeze
timeline
* [david] look at the pulp-oci-images and redmine integration

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

Re: [Pulp-dev] Issues with Python Plugin in Pulp 3 Container

[David Davis]

Are you running the pulp/pulp:latest image? If so, it should be:

{
  "component": "python",
  "version": "3.2.0"
},

Check "podman images --digests pulp/pulp:latest" and make sure it matches:

https://hub.docker.com/layers/pulp/pulp/latest/images/sha256-04e5cc0fe8418a6d836733f7e0c5ca39cd88f72c39f9b53a1545ad16470180b5

David


On Mon, Apr 19, 2021 at 9:09 AM Bob Fahr  wrote:

> I've following the instructions [1] to install the pulp3 container with
> podman and it appears to be running given that I'm able to get a status via
> the api.  The status report shows the following info about the python
> plugin:
>
> {
>   "component": "pulp_python",
>   "version": "3.0.0"
> },
>
> I've followed the instruction [2] to install the pulp cli in a local venv
> and created a config to point to the local container instance.  When I run
> a command using the cli using the python plugin I get the following error.
>
> $ pulp python content list
> Error: 'python>=3.1.0.dev is not available
>
> I haven't been able to find anything about this error and I'm hoping
> someone here can help.
>
> Thanks!
>
> [1] https://pulpproject.org/pulp-in-one-container/
> [2] https://pulp-python.readthedocs.io/en/latest/workflows/index.html
>
> --
>
> Bob Fahr
>
> Principal Software Engineer, CEE Insights
>
> Red Hat 
>
> bf...@redhat.comT: 256-217-0125
> M: 501-733-2516
> 
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Tracking issues for plugin_template

[David Davis]

I've always felt that tracking plugin_template issues under the main pulp
project in plan.io was suboptimal and with other repos such as pulp-cli
moving to github issues, I feel that it might make sense for the
plugin_template to move to github issues as well.

There's only 11 open issues right now in pulp.plan.io for the
plugin_template so I think it would be an easy move. I'd propose we also
remove the plugin_template tag from the list of options (but keep it on old
issues for history).

Thoughts?

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

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# April 13, 2021

## Topics

* Orphan endpoint
* As a user I want to see my orphaned content --> generic endpoint
* As a user I want to purge individual orphaned content
* As a user I want to purge orphaned content by type
* Whilst collection v1.2.3 is considered an orphan another v1.2.3 of
the same collection can NOT be published into any repo in Automation Hub
* can it enabled in the galaxy viewsets by comparing digest of the
uploaded binary data with the digest of the orphaned content ---> if
matches, reject upload?
* Orphan cleanup proposal https://pulp.plan.io/issues/7659
* Have orphan cleanup also consider longest running task?
* Use timestamp_of_interest or longest running task(LRT) start time
(whichever is greater)
* Leave out for now but recommend users don't set threshold above
LRT
* pulp_file release for pulpcore 3.12/3.13 https://pulp.plan.io/issues/8547
* Need to fix deprecations
* reclaim disk space story https://pulp.plan.io/issues/8459
* ROSI announcement
* pulp-smash removal from PyPI
*
https://github.com/pulp/Pulp-2-Tests/blob/013dffb728e4da5611b4b64e5310fe9cf1851479/setup.py#L43
*  Dynaconf or configuration issue?
https://bugzilla.redhat.com/show_bug.cgi?id=1937024#c11

## Action Items
* [david] update orphan cleanup proposal - https://pulp.plan.io/issues/7659
* [all] Look at ROSI announcement
* [all] Look at reclaim story https://pulp.plan.io/issues/8459
* [david] release pulp_file 1.7.0
* [david] ping ggainey about Pulp-2-Test's usage (of pulp-smash).

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

[Pulp-dev] Pulpcore meeting notes

[David Davis]

# April 6, 2021

## Topics

* Distribution migration
* problem removing the primary key on the reverse migration
* https://github.com/pulp/pulp_file/pull/495
* Changing a primary key:
https://vivekanandxyz.wordpress.com/2019/02/25/changing-primary-key-in-django-postgresql-setup/
* Orphan cleanup
* https://pulp.plan.io/issues/7659
* Fixing this issue would mean not having to add global locks to new
tasking system

## Action Items
* [all] review orphan cleanup proposal - https://pulp.plan.io/issues/7659
* Be prepared to discuss
* [david] move old notes to another hackmd

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

[Pulp-dev] Locking down Github Actions

[David Davis]

There have been reports of Github Actions being abused to run
cryptocurrency mining code by bad actors opening PRs against projects that
use GHA. To prevent our repos from being targeted, I've gone through and
either set repos to only allow select actions or disabled actions
completely (for repos not using GHA).

If you manage a pulp repo, please check that everything works in GHA and
that your repo is configured correctly.

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

Re: [Pulp-dev] Pulp 3 Roadmap for Django Upgrades - 3.2 LTS?

[David Davis]

Great question. We haven't had a compelling reason to upgrade to django 3.2
so there are no current plans or roadmap that I'm aware of.

It looks like the EOL for 2.2 security fixes is April 2022 so we definitely
need to upgrade by then. Our two main stakeholders (Katello and Galaxy) are
both about to release soon so maybe after that (summer/fall) might be a
good opportunity to upgrade to 3.2.

I think it'd be worthwhile for us to see how much of an impact upgrading
3.2 will have on our codebase. To that end, I've filed this issue:

https://pulp.plan.io/issues/8488

Will see if we can look at this soon.

David


On Wed, Mar 31, 2021 at 1:52 PM Chris Hambridge  wrote:

> Hi pulp-dev,
>
> We were discussing upcoming plans for Ansible Automation Platform and one
> of the items we touched on was Django upgrade to 3.2 which is the next LTS
> release. I wanted to reach out and understand if Pulp had any current
> plans/roadmap for a similar upgrade. Given the multiple consumers of Pulp
> and plugins for Pulp, I wasn't sure how much additional complexity that may
> add.
>
> Thanks for the info.
>
> Best,
> Chris
>
> --
>
> Chris Hambridge
>
> Senior Principal Software Engineer
>
> Red Hat 
>
> chamb...@redhat.com
> M: 770.365.6343
> @RedHat    Red Hat
>   Red Hat
> 
> 
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] [Pulp-list] PulpCon 2021

[David Davis]

After talking to some people this morning, it sounds like November 8-12
would also work. I think people would rather meet in the fall when the
weather is more conducive to being indoors.

Any objections/thoughts on us having PulpCon the week of Nov 8-12?

David


On Tue, Mar 30, 2021 at 3:01 PM David Davis  wrote:

> It looks like everyone on the team has voted. The week of September 13-17
> seems to be the most popular week. Let's try to aim for some time that
> week. September 20-25 can be a possible backup week if the week of
> September 13 doesn't work out for some reason.
>
> I'll try to get the ball rolling in the next month or so in terms of the
> actual days/times.
>
> Thanks again everyone.
>
> David
>
>
> On Wed, Mar 24, 2021 at 11:15 AM David Davis 
> wrote:
>
>> I haven't heard any objections to having PulpCon virtual this year so
>> under that assumption, I wanted to gather feedback on when to have PulpCon.
>> I've put together a doodle:
>>
>> https://doodle.com/poll/mnnv48t9m35cfzuf
>>
>> I've removed a few weeks that were nonstarters: the week of September 6th
>> has holidays in the US and Brazil; October 25th has holidays in Ireland and
>> CZ; November 1st has holidays in Brazil and Germany; Nov 15th has Brazil
>> and CZ holiday; and Nov 22 is the week of Thanksgiving in the US.
>>
>> Please double check though before voting as I probably missed some
>> holidays.
>>
>> David
>>
>>
>> On Tue, Mar 16, 2021 at 11:08 AM Brian Bouterse 
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 15, 2021 at 11:12 AM David Davis 
>>> wrote:
>>>
>>>> The topic of PulpCon came up today as spring is usually the time we
>>>> begin to plan PulpCon. The main question I think is whether we should hold
>>>> PulpCon again virtually this year or not.
>>>>
>>>> Optimally, we'd like to meet in person but given the uncertainty of our
>>>> current situation, I think we should consider going virtual again this
>>>> year. I noticed that other conferences such as DevConf.us (September 2021)
>>>> are already planning to be virtual this year. And also, if we meet
>>>> virtually this year, we could do an in-person PulpCon in early 2022 
>>>> perhaps.
>>>>
>>> +1 to planning on virtual again for fall 2021. I think it allowed for
>>> more attendance. +1 to also having an in-person event in early 2022.
>>>
>>>
>>>> As for time frame, we'd need at least 3 months to prepare if it's
>>>> virtual. So we'd be looking at sometime between July and December.
>>>>
>>>> Thoughts?
>>>>
>>>> David
>>>> ___
>>>> Pulp-list mailing list
>>>> pulp-l...@redhat.com
>>>> https://listman.redhat.com/mailman/listinfo/pulp-list
>>>
>>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Change to the release process

[David Davis]

Recently the release workflow was updated to use a manual trigger instead
of being triggered by a new tag[0]. This should allow us to rerun the
release workflow anytime there's a failure.

Once you pick up this change via plugin_template, you'll need to tweak your
release process. If your plugin has a step like this one:

- Create a release at https://github.com/pulp/pulp_file/releases/new from
the recent commit labeled "Release x.y.z"

Instead now, you'll need to do these steps:

- Check out master/release branch and tag the release commit (ie "Release
x.y.z"). Push the tag.
- Go to https://github.com/pulp/pulp_file/actions/workflows/release.yml to
trigger a release

Note that the release workflow will now automatically create the Github
release.

[0] https://github.com/pulp/plugin_template/pull/357

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

Re: [Pulp-dev] [Pulp-list] PulpCon 2021

[David Davis]

It looks like everyone on the team has voted. The week of September 13-17
seems to be the most popular week. Let's try to aim for some time that
week. September 20-25 can be a possible backup week if the week of
September 13 doesn't work out for some reason.

I'll try to get the ball rolling in the next month or so in terms of the
actual days/times.

Thanks again everyone.

David


On Wed, Mar 24, 2021 at 11:15 AM David Davis  wrote:

> I haven't heard any objections to having PulpCon virtual this year so
> under that assumption, I wanted to gather feedback on when to have PulpCon.
> I've put together a doodle:
>
> https://doodle.com/poll/mnnv48t9m35cfzuf
>
> I've removed a few weeks that were nonstarters: the week of September 6th
> has holidays in the US and Brazil; October 25th has holidays in Ireland and
> CZ; November 1st has holidays in Brazil and Germany; Nov 15th has Brazil
> and CZ holiday; and Nov 22 is the week of Thanksgiving in the US.
>
> Please double check though before voting as I probably missed some
> holidays.
>
> David
>
>
> On Tue, Mar 16, 2021 at 11:08 AM Brian Bouterse 
> wrote:
>
>>
>>
>> On Mon, Mar 15, 2021 at 11:12 AM David Davis 
>> wrote:
>>
>>> The topic of PulpCon came up today as spring is usually the time we
>>> begin to plan PulpCon. The main question I think is whether we should hold
>>> PulpCon again virtually this year or not.
>>>
>>> Optimally, we'd like to meet in person but given the uncertainty of our
>>> current situation, I think we should consider going virtual again this
>>> year. I noticed that other conferences such as DevConf.us (September 2021)
>>> are already planning to be virtual this year. And also, if we meet
>>> virtually this year, we could do an in-person PulpCon in early 2022 perhaps.
>>>
>> +1 to planning on virtual again for fall 2021. I think it allowed for
>> more attendance. +1 to also having an in-person event in early 2022.
>>
>>
>>> As for time frame, we'd need at least 3 months to prepare if it's
>>> virtual. So we'd be looking at sometime between July and December.
>>>
>>> Thoughts?
>>>
>>> David
>>> ___
>>> Pulp-list mailing list
>>> pulp-l...@redhat.com
>>> https://listman.redhat.com/mailman/listinfo/pulp-list
>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# March 30, 2021

## Previous AIs
* [bmbouter] to close https://github.com/pulp/pulpcore/pull/1122 based on
the recent convo at pulp_ansible meeting
* [ttereshc] to review https://github.com/pulp/pulpcore/pull/1194
* Done, merged

## Topics
* another go/no-go meeting? thursday
* MasterModel distribution work update
* daviddavis to take over the completion of the work
* https://github.com/pulp/pulpcore/pull/1198/
* https://github.com/pulp/pulp_file/pull/484/
* bmbouter and mdellweg updating worker redesign PoC
* https://hackmd.io/Y0l9nBm9SFmPiIBXBz8lwQ
* pulp_file 1.6.1
* Going out today

## Actions Items
* [bmbouter] to close https://github.com/pulp/pulpcore/pull/1122 based on
the recent convo at pulp_ansible meeting

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

Re: [Pulp-dev] pulpcore 3.12.0 release schedule & go/no-go irc meeting

[David Davis]

When is the next meeting?

David


On Tue, Mar 23, 2021 at 11:22 AM Ina Panova  wrote:

> Here's the tracker for the pulpcore 3.12.0 release
> https://pulp.plan.io/issues/8437
> The tentative GA date is April 6th.
>
> The first go/no-go meeting happened  today and so far we are on track.
>
> 
> 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://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing pulp-smash from PyPI

[David Davis]

Yes, that's the plan. Sorry I didn't mention that in my email.

David


On Fri, Mar 26, 2021 at 11:23 AM Mike DePaulo  wrote:

> It's declared in many plugins' test dependencies without the git path,
> such as pulp_file/functest_requirements.txt
>
> I often install those as part of my installer development, and support for
> other teams.
>
> So I agree with this approach, but update the plugins too.
>
> -Mike
>
> On Fri, Mar 26, 2021 at 11:16 AM David Davis 
> wrote:
>
>> It recently came up that the pulp-smash release PyPI is badly out of
>> date. It's an extra burden to release it and it doesn't seem to have any
>> benefit. So instead we're considering using the git repo directly (see [0])
>> but I wanted to first check if that's a problem for anyone?
>>
>> [0] https://github.com/pulp/pulpcore/pull/1210
>>
>> David
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
>
> Mike DePaulo
>
> He / Him / His
>
> Service Reliability Engineer, Pulp
>
> Red Hat <https://www.redhat.com/>
>
> IM: mikedep333
>
> GPG: 51745404
> <https://www.redhat.com/>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Removing pulp-smash from PyPI

[David Davis]

It recently came up that the pulp-smash release PyPI is badly out of date.
It's an extra burden to release it and it doesn't seem to have any benefit.
So instead we're considering using the git repo directly (see [0]) but I
wanted to first check if that's a problem for anyone?

[0] https://github.com/pulp/pulpcore/pull/1210

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

Re: [Pulp-dev] [Pulp-list] PulpCon 2021

[David Davis]

I haven't heard any objections to having PulpCon virtual this year so under
that assumption, I wanted to gather feedback on when to have PulpCon. I've
put together a doodle:

https://doodle.com/poll/mnnv48t9m35cfzuf

I've removed a few weeks that were nonstarters: the week of September 6th
has holidays in the US and Brazil; October 25th has holidays in Ireland and
CZ; November 1st has holidays in Brazil and Germany; Nov 15th has Brazil
and CZ holiday; and Nov 22 is the week of Thanksgiving in the US.

Please double check though before voting as I probably missed some
holidays.

David


On Tue, Mar 16, 2021 at 11:08 AM Brian Bouterse  wrote:

>
>
> On Mon, Mar 15, 2021 at 11:12 AM David Davis 
> wrote:
>
>> The topic of PulpCon came up today as spring is usually the time we begin
>> to plan PulpCon. The main question I think is whether we should hold
>> PulpCon again virtually this year or not.
>>
>> Optimally, we'd like to meet in person but given the uncertainty of our
>> current situation, I think we should consider going virtual again this
>> year. I noticed that other conferences such as DevConf.us (September 2021)
>> are already planning to be virtual this year. And also, if we meet
>> virtually this year, we could do an in-person PulpCon in early 2022 perhaps.
>>
> +1 to planning on virtual again for fall 2021. I think it allowed for more
> attendance. +1 to also having an in-person event in early 2022.
>
>
>> As for time frame, we'd need at least 3 months to prepare if it's
>> virtual. So we'd be looking at sometime between July and December.
>>
>> Thoughts?
>>
>> David
>> ___
>> Pulp-list mailing list
>> pulp-l...@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-list
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# March 16, 2021

## Previous AIs
[mdellweg] summarize "safety in deletion" of remotes feature onto
https://pulp.plan.io/issues/8305 [done]

## Topics
* deleting and rejecting, timeline and scheduling?
* https://pulp.plan.io/issues/7659 run orphan clean up in parallel
* ask for deleting artifact but keeping the content
* keeping the record but freeing diskspace;
* delete collection-1.2.3 tarball and never allow collection-1.2.3
to be uploaded again
* version consistency + free disk space
* retain N repository versions, request for comment
* https://pulp.plan.io/issues/8368
* improving how users can identify orphans, request for comment
* https://pulp.plan.io/issues/8372
* should this merge? https://github.com/pulp/pulp/pull/4020/
* may simplify satellite carrying downstream patch if they only need to
patch pulp_rpm. low-risk, small patch.
* Yes, merge it
* 3 month planning

## Action Items
* [ipanova] to set up meeting about content management (removal, rejecting,
etc)
* [bmbouter] to merge https://github.com/pulp/pulp/pull/4020/ and reply to
thread

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

Re: [Pulp-dev] pulp_rpm and The Pitfalls of urljoin()

[David Davis]

I've been bitten by this a couple times. I also noticed that ansible
actually defines its own version of urljoin:

https://github.com/ansible/ansible/blob/00bd0b893d5d21de040b53032c466707bacb3b93/lib/ansible/galaxy/api.py#L166-L167

David


On Mon, Mar 15, 2021 at 3:44 PM Grant Gainey  wrote:

> Hey folks,
>
> I was looking at https://pulp.plan.io/issues/7995 with an eye to fixing
> it for 3.12. The underlying problem can be summed up as "urljoin doesn't do
> what you expect if 'base' doesn't end in a '/'"[0][1]. Using urljoin() as
> if all it does is "concatenate these two strings with a '/' between them"
> is a pretty common misuse that works 'most of the time', alas.
>
> Looking around to see if we do this anywhere else, I find that pulp_rpm
> uses urljoin() in a number of places that I think might be subject to the
> same unintended problem. However, the semantics of sync'ing RPM
> repositories is even *more* nuanced than urljoin()'s is!
>
> I am tempted to replace urljoin() with just straightforward path-creation.
> Here's the list of places in pulp_rpm non-test python that uses it
> currently:
>
> (pulp3) (master) ~/github/Pulp3/pulp_rpm $ find . -name \*.py | grep -v
> tests | xargs grep -n "urljoin("
> ./pulp_rpm/app/kickstart/treeinfo.py:23:
>  url=urljoin(remote_url, namespace),
> silence_errors_for_response_status_codes={403, 404}
> ./pulp_rpm/app/models/repository.py:355:gpgkey_path =
> urllib.parse.urljoin(
> ./pulp_rpm/app/models/repository.py:358:gpgkey_path =
> urllib.parse.urljoin(gpgkey_path, self.base_path, True)
> ./pulp_rpm/app/tasks/synchronizing.py:101:downloader =
> remote.get_downloader(url=urljoin(url, "repodata/repomd.xml"))
> ./pulp_rpm/app/tasks/synchronizing.py:138:downloader =
> remote.get_downloader(url=urljoin(remote_url, "repodata/repomd.xml"))
> ./pulp_rpm/app/tasks/synchronizing.py:243:new_url =
> urljoin(remote_url, path)
> ./pulp_rpm/app/tasks/synchronizing.py:430:
>  url=urljoin(self.data.remote_url, "repodata/repomd.xml")
> ./pulp_rpm/app/tasks/synchronizing.py:460:
>  url=urljoin(self.data.remote_url, self.treeinfo["filename"]),
> ./pulp_rpm/app/tasks/synchronizing.py:470:
>  url=urljoin(self.data.remote_url, path),
> ./pulp_rpm/app/tasks/synchronizing.py:599:url =
> urljoin(self.data.remote_url, package.location_href)
> ./pulp_rpm/app/tasks/synchronizing.py:722:repodata_url =
> urljoin(self.data.remote_url, record.location_href)
> ./pulp_rpm/app/tasks/synchronizing.py:726:self.data.updateinfo_url
> = urljoin(self.data.remote_url, record.location_href)
> ./pulp_rpm/app/tasks/synchronizing.py:731:comps_url =
> urljoin(self.data.remote_url, record.location_href)
> ./pulp_rpm/app/tasks/synchronizing.py:735:self.data.modules_url =
> urljoin(self.data.remote_url, record.location_href)
> ./pulp_rpm/app/tasks/synchronizing.py:743:
>  url=urljoin(self.data.remote_url, record.location_href),
> ./pulp_rpm/app/downloaders.py:84:url = urljoin(self.url,
> auth_param)
> (pulp3) (master) ~/github/Pulp3/pulp_rpm $
>
> Any thoughts before I dive down this rabbithole? I'm afraid I don't even
> have a pocketwatch...
>
> G
>
> [0] https://docs.python.org/2/library/urlparse.html#urlparse.urljoin
> [1] https://stackoverflow.com/a/10893427
> --
> Grant Gainey
> Principal Software Engineer, Red Hat System Management Engineering
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://listman.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] PulpCon 2021

[David Davis]

The topic of PulpCon came up today as spring is usually the time we begin
to plan PulpCon. The main question I think is whether we should hold
PulpCon again virtually this year or not.

Optimally, we'd like to meet in person but given the uncertainty of our
current situation, I think we should consider going virtual again this
year. I noticed that other conferences such as DevConf.us (September 2021)
are already planning to be virtual this year. And also, if we meet
virtually this year, we could do an in-person PulpCon in early 2022 perhaps.

As for time frame, we'd need at least 3 months to prepare if it's virtual.
So we'd be looking at sometime between July and December.

Thoughts?

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

Re: [Pulp-dev] Nightly publish jobs broken

[David Davis]

The job should be fixed now in plugin_template. Please update your plugin's
CI files.

David


On Mon, Mar 1, 2021 at 10:30 AM David Davis  wrote:

> The nightly publish jobs are broken due to a recent change in how
> component names are returned in the status API. I have a potential fix that
> will require plugins to update their CI configuration from the
> plugin_template but I am waiting for a pulpcore CI nightly run to see if it
> works. Will reply to this email once I've confirmed that the fix is
> working. For more info see[0].
>
> [0] https://pulp.plan.io/issues/8311
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# March 2, 2021

## Previous AIs
* [mdellweg] ping quba42 about pulp_deb CI; Done

## Topics
* docs day for 3.11. Does it makes sense to schedule it this time? I don't
think anyone(?) has made any docs PR for 3.10 docs day due to the
workload[ipanova]
* Skip but mdellweg will check for any docs issues that we might need
for 3.11
* Deleting a remote breaks content artifacts:
https://pulp.plan.io/issues/8305
* Get more info (eg does recreating the remote fix everything?)
* Revisit next week
* should Pulp sync handle 429?
* It should currently
* removal of tech preview label .doc or .feature?
* We should be consistent. ttereshc demanded we use ".doc"
* Maybe introduce tech preview section in the future?
* https://github.com/pulp/pulpcore/pull/1086#issuecomment-788176427
* Checking remote artifacts for publications
* Pulpcore team to review PRs. Set up follow up discussion.
* worker timeouts
* HDD environments have WAL lock issues
* Removal (or not) of tech-preview labels in 3.11 and beyond!
* https://pulp.plan.io/versions/174
* Discuss at go/no-go meeting

## Action items
* [mdellweg] look for any docs issues that we might need for 3.11
* [dalley] get more info about what happens remote gets deleted to revisit
next week
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Nightly publish jobs broken

[David Davis]

The nightly publish jobs are broken due to a recent change in how component
names are returned in the status API. I have a potential fix that will
require plugins to update their CI configuration from the plugin_template
but I am waiting for a pulpcore CI nightly run to see if it works. Will
reply to this email once I've confirmed that the fix is working. For more
info see[0].

[0] https://pulp.plan.io/issues/8311

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

[Pulp-dev] pulp-cli 0.6.0 is generally available

[David Davis]

pulp-cli 0.6.0 has been released to PyPI[0]. It is considered beta software
until pulp-cli reaches its 1.0 release. Future releases will likely break
compatibility.

This release features support for the upcoming component name change in
pulpcore 3.11. See the changelog for more details[1]. For help installing
and configuring the CLI, see the docs[2].

If you find any bugs or want to suggest features, please file an issue on
Github[3].

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli/blob/develop/CHANGES.rst
[2] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[3] https://github.com/pulp/pulp-cli/issues

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

Re: [Pulp-dev] https://fixtures.pulpproject.org/ downtime

[David Davis]

One thing I noticed is that the urls still point to
fixtures-test.pulproject.org. I've notified @misc. Hopefully they can get
that resolved soon.

David


On Thu, Feb 25, 2021 at 7:33 AM Brian Bouterse  wrote:

> Thank you!
>
> On Thu, Feb 25, 2021, 5:47 AM David Davis  wrote:
>
>> The site has been updated and should be working now.
>>
>> On Tuesday, February 23, 2021, David Davis  wrote:
>>
>>> We're switching over to openshift for fixtures.pulpproject.org on
>>> Thursday February 25 at 10:00 UTC (5am ET). It may take some time for the
>>> DNS to update so we expect about an hour or so of downtime.
>>>
>>> David
>>>
>>
>>
>> --
>>
>> David
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] https://fixtures.pulpproject.org/ downtime

[David Davis]

The site has been updated and should be working now.

On Tuesday, February 23, 2021, David Davis  wrote:

> We're switching over to openshift for fixtures.pulpproject.org on
> Thursday February 25 at 10:00 UTC (5am ET). It may take some time for the
> DNS to update so we expect about an hour or so of downtime.
>
> David
>


-- 

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

[Pulp-dev] https://fixtures.pulpproject.org/ downtime

[David Davis]

We're switching over to openshift for fixtures.pulpproject.org on Thursday
February 25 at 10:00 UTC (5am ET). It may take some time for the DNS to
update so we expect about an hour or so of downtime.

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

[Pulp-dev] pulp-cli 0.5.0 is generally available

[David Davis]

pulp-cli 0.5.0 has been released to PyPI[0]. It is considered beta software
until pulp-cli reaches its 1.0 release. Future releases will likely break
compatibility.

This release features pulp 2to3 migration support, multiple config support,
a worker command, and better validation of task states when filtering. See
the changelog for all changes[1]. For help installing and configuring the
CLI, see the docs[2].

If you find any bugs or want to suggest features, please file an issue on
Github[3].

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli/blob/develop/CHANGES.rst
[2] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[3] https://github.com/pulp/pulp-cli/issues

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

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# February 16, 2021

## Previous action items
* [bmbouter] to revise https://pulp.plan.io/issues/8202 and
https://pulp.plan.io/issues/8167
* Done
* [bmbouter] update working dir changes issue to include docs section about
tempfile https://pulp.plan.io/issues/8231
* Done
* [fao] contribute back to drf_spectacular to simplify our code

## Topics
* Close out this issue? https://pulp.plan.io/issues/5510
* System checks
* https://github.com/pulp/pulpcore/blob/master/pulpcore/app/checks.py
* https://git.io/JtX46
* Migration plugin support
* Pulpcore broke migration plugin?
* How long do we support migration plugin?
* For the foreseeable future
* Review items on the sprint
* https://pulp.plan.io/projects/pulp/issues?query_id=124
* Removed items we don't think we'll get to in near future

## Action items
* [david] Close out https://pulp.plan.io/issues/5510 with comment directing
them to labels
* [david] file/update issues about checks
* [bmbouter] add galaxy tag in plan.io to track galaxy requests

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

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# February 9, 2021

## Previous action items
None

## Topics
* https://pulp.plan.io/issues/8202
* Which fields need to be write_only?
* 3.11 release date? volunteer?
* March 2
* ipanova to release
* Discuss rotating the role
* working directory changes
* https://pulp.plan.io/issues/8231
* drf_spectacular
* https://pulp.plan.io/issues/8209
* how to avoid copy code to customize? Is it ok to contribute back to
drf_spectacular?
* Content app performance
* https://pulp.plan.io/issues/8180
* At minimum, we need to tune some parameters, optimize codepaths
* We may want to investigate other means of serving content (or caching)
* RHUI and others want this anyway https://pulp.plan.io/issues/7810
Next steps:
* bring up at the katello integration meeting
* involve perf team to extend existing test plans
* start hackmd + schedule a meeting

## Action items
* [bmbouter] to revise https://pulp.plan.io/issues/8202 and
https://pulp.plan.io/issues/8167
* update working dir changes issue to include docs section about tempfile
https://pulp.plan.io/issues/8231
* [fao] contribute back to drf_spectacular to simplify our code

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

[Pulp-dev] pulp-cli 0.3.0 is generally available

[David Davis]

pulp-cli 0.3.0 has been released to PyPI[0]. It is considered beta software
until it reaches its 1.0 release. Future releases will likely break
compatibility.

The 0.3.0 release features support for labels, which were added in pulpcore
3.10. See the changelog for all changes[1]. For help installing and
configuring the CLI, see the docs[2].

If you find any bugs or want to suggest features, please file an issue on
Github[3].

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli/blob/develop/CHANGES.rst
[2] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[3] https://github.com/pulp/pulp-cli/issues


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

[Pulp-dev] Pulpcore meeting notes

[David Davis]

# February 2, 2021

## Previous action items
* [fao89] will port fr the rate limit code to pulpcore - david + brian will
review
* Done: https://github.com/pulp/pulpcore/pull/1091
* [brian and matthias] will meet to talk about security scanners
* Done https://pulp.plan.io/issues/8088
* will send to pulp-dev to advertise for feedback
* [bmbouter] to file story for adding proxy_username and proxy_password and
add to 3.11
* Done https://pulp.plan.io/issues/8167

## Topics
* Status API app name changing (bugfix, but backwards incompatible)
* https://github.com/pulp/pulpcore/pull/1102
* 4 options
* do nothing - things update and changed
* use the name attribute and strip off ".app" - this would get you
back to the original
~~* have plugins change their label as part of 3.10 compatibility
release~~
* defer??
* Decision: use labels
* Encrypting data at rest issue FYI ( get into pulpcore 3.12)
* https://pulp.plan.io/issues/8192
* Revisiting returning secrets in the API for authorized users
* rbac for artifacts

## Action items
None

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

[Pulp-dev] pulp-fixtures port change

[David Davis]

In moving fixtures.pulpproject.org to Openshift[0], we had to change the
port nginx listens on in the pulp-fixtures container to 8080 instead of 80.
If you're using pulp-fixtures locally or in your CI, you'll have to either
update your smash-config.json to point to 8080 (see [1]) or map that port
when starting the container.

[0] https://github.com/pulp/pulp-fixtures/pull/208
[1] https://github.com/pulp/plugin_template/pull/335

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

[Pulp-dev] Removing pulp/pulp-fedora31 image

[David Davis]

The pulp/pulp-fedora31 container image[0] has been replaced by
pulp/pulp[1]. I plan to remove pulp/pulp-fedora31 after February 5th if
there are no objections.

[0] https://hub.docker.com/r/pulp/pulp-fedora31
[1] https://hub.docker.com/r/pulp/pulp

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

[Pulp-dev] pulp-cli 0.2.0 is generally available

[David Davis]

pulp-cli 0.2.0 has been released to PyPI[0]. It is considered beta software
until it reaches its 1.0 release. Future releases will likely break
compatibility.

The 0.2.0 release features pulp_ansible support, a repository modify
command, and the ability to call --help without having to connect to a
server. See the changelog for all changes[1]. For help installing and
configuring the CLI, see the docs[2].

If you find any bugs or want to suggest features, please file an issue on
Github[3].

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli/blob/develop/CHANGES.rst#020-2021-01-26
[2] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[3] https://github.com/pulp/pulp-cli/issues


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

[Pulp-dev] Pulpcore team meeting notes

[David Davis]

# January 19, 2021

## Previous action items
* [bmbouter] to ask Satellite if they require this and when
https://pulp.plan.io/issues/7683
* Satellite PM doesn't need. David to check with support.
* [ipanova] open story to add write api for users
* Done.
* [daviddavis] schedule fips check in meeting
* Done. Next meeting is Jan 28.

## Topics
* FIPS estimate for pulpcore work
* https://tinyurl.com/pulpcorefips
* Estimate: 2.5 FTE
* Release automation - https://pulp.plan.io/issues/8093
* Added task to automate the pre-release steps
https://pulp.plan.io/issues/8119
* Proposal: start using github discussions
* https://github.com/orgs/pulp/teams/core
* let's not use it for now, let's instead explore using github issues
as planned fall 2020

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

[Pulp-dev] pulp-cli 0.1.0 Generally Available

[David Davis]

The first release of the pulp-cli has been released to PyPI[0]. While this
is the first release, the pulp-cli is still considered beta software until
it reaches its 1.0 release. Future releases will likely break compatibility.

The pulp-cli provides a user friendly alternative to the REST API in Pulp
3. For instructions on how to install, configure, and use the CLI, please
visit the docs[1]. Currently, the CLI supports pulpcore and pulp_file; it
also provides some basic support for pulp_container and pulp_rpm.

If you find any bugs or want to suggest features, please file an issue on
plan.io[2].

Special thanks to mdellweg, ggainey, dkliban, and other testers for
contributing to the first release of pulp-cli.

[0] https://pypi.org/project/pulp-cli/
[1] https://github.com/pulp/pulp-cli#pulp-command-line-interface
[2] https://pulp.plan.io/projects/pulp-cli/issues/new

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

Re: [Pulp-dev] Backports and LTS

[David Davis]

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

[Pulp-dev] Pulpcore team meeting

[David Davis]

# January 12, 2021

## Previous action items
* [dkliban] to close out pulp_file 1.5.0
* Done
* [ttereshc] start discussion about LTS versions of pulp
* https://www.redhat.com/archives/pulp-dev/2021-January/msg3.html
* Done

## Topics
* Download and verify - https://pulp.plan.io/issues/7683
* Needs to be implemented in pulpcore
* bmbouter to ask for deadline
* Deadline for https://pulp.plan.io/issues/7659?
* Would like to fix by march/april
* write api for users
* All agreed to proceed - AI open a story
* Restrict default permissions to admin users
* https://github.com/pulp/pulpcore/pull/1064

## Action Items
* [bmbouter] to ask find out if/when this is needed
https://pulp.plan.io/issues/7683
* [ipanova] open story to add write api for users
* [daviddavis] schedule fips check in meeting

David
___
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] 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] 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] Re-enable required status checks

[David Davis]

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

Re: [Pulp-dev] plugin release checklist templates

[David Davis]

+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] Pulpcore team meeting

[David Davis]

# January 5, 2021

## Previous action items
* [dkliban] to release pulp_file 1.5.0
* [ttereshc] work on https://pulp.plan.io/issues/7869
* done https://github.com/pulp/plugin_template/pull/325
* [x9c4] write a task to have a test that searches for log messages with
deprecation warnings
* https://pulp.plan.io/issues/7997 [Done]
* [x9c4] start a pulp-dev thread about RBAC - objects that do not have
access policy are accesible by default
* Done
* https://github.com/pulp/pulpcore/pull/1064
* [dklban] to look at https://github.com/pulp/pulpcore/pull/799
* Done. Needs some installer changes.
* [ttereshc] update the release guide and plugin templates in plan.io
clarify when to bump plugin's Y release.
* done
https://pulp.plan.io/projects/pulp/wiki/Pulp3_Release_Guide#Criteria-to-have-the-Y-release-for-plugins
* needs feedback
https://www.redhat.com/archives/pulp-dev/2020-December/msg00032.html

## Topics
* Move off Travis https://pulp.plan.io/issues/7859
* need a volunteer for the remaining task to publish docs on every push
* Backports https://pulp.plan.io/issues/7950 and
https://pulp.plan.io/issues/7951
* on hold till the fixes are merged
* galaxy requirement: pulpcore>=3.7,<3.9 (backport will be needed in
3.7 and 3.8) https://github.com/ansible/galaxy_ng/blob/4.2.0/setup.py#L60
* Object labels https://pulp.plan.io/issues/7127
 * Need a volunteer to deliver in pulpcore 3.10
 * daviddavis: started on this
* Can we make the users, groups and permissions resources manageble by the
rest-api?
* enables us to add cli commands for them
* Sounds good. Check with bmbouter.
* https://pulp.plan.io/issues/8010
* Should backports be backported to every (minor) version between the fix
and the requested version
* We need an LTS, 3.7 is defacto an LTS version.
* Mailing list discussion
* new idna (sub-dependency) releases break pulp installation
* https://pulp.plan.io/issues/6169
* Follow up at installer meeting to ensure users are using the newest
version of pip (has newest dependency solver)
* Signing service SMEs?
* matthias and dkliban

## Action Items
* [dkliban] to close out pulp_file 1.5.0
* [ttereshc] start discussion about LTS versions of pulp

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

Re: [Pulp-dev] FIPS/content checksums user stories

[David Davis]

To follow up, I've added the remaining issues to an epic in pulp.plan.io:
https://pulp.plan.io/issues/7960.

David


On Fri, Dec 11, 2020 at 8:00 AM David Davis  wrote:

> I wanted to email these user stories out to the Pulp community to call for
> any feedback. Any comments/questions welcome.
>
> https://hackmd.io/KzcCx9ZZR26kvQqJYp46GQ?view
>
> Thank you.
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] FIPS/content checksums user stories

[David Davis]

I wanted to email these user stories out to the Pulp community to call for
any feedback. Any comments/questions welcome.

https://hackmd.io/KzcCx9ZZR26kvQqJYp46GQ?view

Thank you.

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

Re: [Pulp-dev] Object label feature proposal

[David Davis]

Thank you all for the feedback. It seemed like most people were in favor of
option 1. Moreover, I looked into key/value fields in postgresql and our
options would be to use either jsonb (which would be painfully slow to
search across) or hstore (which is a separate module and not built into
postgresql). So I've updated the ticket with a version of option 1.

https://pulp.plan.io/issues/7127

More feedback is welcome. Also, please feel free to groom it. :)

David


On Wed, Dec 2, 2020 at 1:08 PM David Davis  wrote:

> I've put together some design proposals to support object labels in Pulp
> 3. This would add key/value labels to a variety of objects in Pulp that
> users could use to store information and to filter objects with.
>
> Story: https://pulp.plan.io/issues/7127
>
> Proposals: https://hackmd.io/N4WFhHGWQtib7D1JIKzCDQ?view
>
> The goal is to deliver this feature as part of 3.10.
>
> Thanks.
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Re-enable required status checks

[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] Pulpcore team meeting notes

[David Davis]

# December 8, 2020

## Previous action items
* [ttereshc] to file a task to implement plugin removal
* Done https://pulp.plan.io/issues/7822
* [fao89] to figure out the use case for this fix
https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32
* DRF raises 400/500 instead of 409
* https://issues.redhat.com/browse/AAH-152
* https://issues.redhat.com/browse/AAH-132
* https://httpstatusdogs.com/409-conflict
* https://http.cat/409
* Wait for user to report this. We need a reproducer

## Topics
* Backlog grooming
* pulp_file 1.5.0 release
* bmbouter to fix plugin config version and release
* Object label proposal
* https://hackmd.io/N4WFhHGWQtib7D1JIKzCDQ
* pulp_file docs
* Looks like the 1.4.0post1 release build succeeded? Docs still say 1.3
* [dkliban] fix in progress
* Task to take down read the docs for pulp_file:
https://pulp.plan.io/issues/7932
* Move off Travis check in
* https://pulp.plan.io/issues/7859
* Meet on Dec 15 & 22?
* Cancel Dec 22

## Action items
* [dkliban] to schedule backlog grooming meeting
* [dkliban] to email plugins about and close out
https://pulp.plan.io/issues/7895
* [bmbouter] release pulp_file 1.5.0

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

[Pulp-dev] Pulpcore 3.9.0 is generally available

[David Davis]

Pulpcore 3.9.0 [0] and pulp_installer 3.9.0 [1] have been released.

For a full list of changes, please check the changelog for pulpcore [2] and
pulp_installer [3].

# Installation and Upgrade

Users should use the 3.9.0 release of pulp_installer [1] to install or
upgrade their installations. This version of the installer will check
compatibility of all installed plugins with pulpcore 3.9. The installer
will abort if any plugin is incompatible.

The pulp_installer collection can be installed from Ansible Galaxy with the
following command:

ansible-galaxy collection install --force pulp.pulp_installer

The --force flag will upgrade the collection if you had a previous version
installed.

# Plugin API

Plugin writers can see the API changes here [4].

Due to the 1-cycle deprecation policy, the recommended strategy is to pin
plugins to a 3.y and 3.y+1 version of pulpcore. So for a compatibility
release with 3.9 use: "pulpcore>=3.9,<3.11".

If your plugin is compatible with earlier pulpcore releases, use:
"pulpcore>=3.y,<3.11", where y is the oldest pulpcore release your plugin
is compatible with.

[0] https://pypi.org/project/pulpcore/3.9.0/
[1] https://galaxy.ansible.com/pulp/pulp_installer
[2] https://docs.pulpproject.org/en/3.9/changes.html
[3] https://pulp-installer.readthedocs.io/en/latest/CHANGES/
[4] https://docs.pulpproject.org/en/3.9/changes.html#plugin-api

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

Re: [Pulp-dev] pulpcore 3.9.0 release timeline and go/no-go irc meeting

[David Davis]

Today we had our go/no-go meeting and the decision was made to release 3.9
on December 7th, 2020.

David


On Wed, Dec 2, 2020 at 11:37 AM David Davis  wrote:

> For now, we are still aiming to release on December 7th, 2020. But there
> are still some open issues which warrant another check in meeting.
>
> The next go/no-go meeting will be December 4, 2020 at 3:30pm UTC/10:30am
> ET.
>
> David
>
>
> On Mon, Nov 30, 2020 at 11:01 AM David Davis 
> wrote:
>
>> We met today and reviewed the outstanding issues along with the work left
>> on our CI/CD infrastructure. For now, we are still aiming to release on
>> December 7th, 2020.
>>
>> The next go/no-go meeting will be December 2, 2020 at 4:15pm UTC/11:15am
>> ET.
>>
>> David
>>
>>
>> On Mon, Nov 23, 2020 at 10:47 AM David Davis 
>> wrote:
>>
>>> Today at the go/no-go meeting we decided to push back the release date
>>> by one week to December 7th. This delay was caused by us needing to move
>>> off Travis. We'll be using Github Actions to perform the release.
>>>
>>> The next go/no-go meeting will be November 30 3:30pm UTC/November 30
>>> 10:30am ET.
>>>
>>> David
>>>
>>>
>>> On Tue, Nov 10, 2020 at 11:48 AM Tanya Tereshchenko 
>>> wrote:
>>>
>>>> Just fixed a typo. It's 3.9.0.
>>>>
>>>> On Tue, Nov 10, 2020 at 4:52 PM David Davis 
>>>> wrote:
>>>>
>>>>> Here's the tracker for the pulpcore 3.8.0 3.9.0 release:
>>>>> https://pulp.plan.io/issues/7789.
>>>>> The tentative GA date is November 30th.
>>>>>
>>>>> The first go/no-go meeting will happen in #pulp-meeting at the time
>>>>> below:
>>>>>
>>>>> November 23 3:30pm UTC/November 23 10:30am ET
>>>>> https://everytimezone.com/s/bc9ca71d
>>>>>
>>>>> 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] Object label feature proposal

[David Davis]

I've put together some design proposals to support object labels in Pulp 3.
This would add key/value labels to a variety of objects in Pulp that users
could use to store information and to filter objects with.

Story: https://pulp.plan.io/issues/7127

Proposals: https://hackmd.io/N4WFhHGWQtib7D1JIKzCDQ?view

The goal is to deliver this feature as part of 3.10.

Thanks.

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

Re: [Pulp-dev] pulpcore 3.9.0 release timeline and go/no-go irc meeting

[David Davis]

For now, we are still aiming to release on December 7th, 2020. But there
are still some open issues which warrant another check in meeting.

The next go/no-go meeting will be December 4, 2020 at 3:30pm UTC/10:30am ET.

David


On Mon, Nov 30, 2020 at 11:01 AM David Davis  wrote:

> We met today and reviewed the outstanding issues along with the work left
> on our CI/CD infrastructure. For now, we are still aiming to release on
> December 7th, 2020.
>
> The next go/no-go meeting will be December 2, 2020 at 4:15pm UTC/11:15am
> ET.
>
> David
>
>
> On Mon, Nov 23, 2020 at 10:47 AM David Davis 
> wrote:
>
>> Today at the go/no-go meeting we decided to push back the release date by
>> one week to December 7th. This delay was caused by us needing to move off
>> Travis. We'll be using Github Actions to perform the release.
>>
>> The next go/no-go meeting will be November 30 3:30pm UTC/November 30
>> 10:30am ET.
>>
>> David
>>
>>
>> On Tue, Nov 10, 2020 at 11:48 AM Tanya Tereshchenko 
>> wrote:
>>
>>> Just fixed a typo. It's 3.9.0.
>>>
>>> On Tue, Nov 10, 2020 at 4:52 PM David Davis 
>>> wrote:
>>>
>>>> Here's the tracker for the pulpcore 3.8.0 3.9.0 release:
>>>> https://pulp.plan.io/issues/7789.
>>>> The tentative GA date is November 30th.
>>>>
>>>> The first go/no-go meeting will happen in #pulp-meeting at the time
>>>> below:
>>>>
>>>> November 23 3:30pm UTC/November 23 10:30am ET
>>>> https://everytimezone.com/s/bc9ca71d
>>>>
>>>> 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] Pulpcore team meeting notes

[David Davis]

# December 1, 2020

### Previous action items
* [fao89] look at driving forward release automation.
* Automate post-release steps (branching, bumping to dev versions,
updating template config, etc)
* https://pulp.plan.io/issues/7817 (needs grooming, please provide
feedback)
* https://pulp.plan.io/issues/7818 (~~needs grooming~~)
* Done for now, focus is on moving off Travis for the short term.
* Defer until after 3.9 GA
* [ttereshc] to file a task to implement plugin removal
* [fao89] to figure out the use case for this fix
https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32
* [david] updates on tagging planning https://pulp.plan.io/issues/7127
* Design is in progress. Will email out this week.

### Topics
* pulp_file 1.4.0
* ttereshc can be voluntold to do that
* dkliban to work on this this week
* alternate content sources design review
* https://pulp.plan.io/issues/7832

### Action items
* [ttereshc] to file a task to implement plugin removal
* [fao89] to figure out the use case for this fix
https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32

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

Re: [Pulp-dev] pulpcore 3.9.0 release timeline and go/no-go irc meeting

[David Davis]

We met today and reviewed the outstanding issues along with the work left
on our CI/CD infrastructure. For now, we are still aiming to release on
December 7th, 2020.

The next go/no-go meeting will be December 2, 2020 at 4:15pm UTC/11:15am ET.

David


On Mon, Nov 23, 2020 at 10:47 AM David Davis  wrote:

> Today at the go/no-go meeting we decided to push back the release date by
> one week to December 7th. This delay was caused by us needing to move off
> Travis. We'll be using Github Actions to perform the release.
>
> The next go/no-go meeting will be November 30 3:30pm UTC/November 30
> 10:30am ET.
>
> David
>
>
> On Tue, Nov 10, 2020 at 11:48 AM Tanya Tereshchenko 
> wrote:
>
>> Just fixed a typo. It's 3.9.0.
>>
>> On Tue, Nov 10, 2020 at 4:52 PM David Davis 
>> wrote:
>>
>>> Here's the tracker for the pulpcore 3.8.0 3.9.0 release:
>>> https://pulp.plan.io/issues/7789.
>>> The tentative GA date is November 30th.
>>>
>>> The first go/no-go meeting will happen in #pulp-meeting at the time
>>> below:
>>>
>>> November 23 3:30pm UTC/November 23 10:30am ET
>>> https://everytimezone.com/s/bc9ca71d
>>>
>>> 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

Re: [Pulp-dev] Pulpcore meeting notes

[David Davis]

Ah, ok. thank you.

David


On Tue, Nov 24, 2020 at 3:40 PM Tanya Tereshchenko 
wrote:

> Just because you were not present, I carried over your items which were
> not marked as done and the ones we were not sure about the next steps.
> Feel free to adjust them as you see it.
> We didn't assign anything new to you while you were away :)
>
> Tanya
>
> On Tue, Nov 24, 2020 at 8:26 PM David Davis  wrote:
>
>> Thanks for taking notes and sorry I couldn't be at the meeting. Can you
>> explain more about the action item to give updates on the tagging story? I
>> was planning on following up on the mailing lists with updates since I
>> don't think the feature will be specific to pulpcore.
>>
>> As for the automatic merge PR (https://github.com/pulp/pulp-ci/pull/737),
>> I wasn't planning on carrying forward an AI for it. I don't have any time
>> to address in the near future but I'm happy to hand it off to someone else
>> if they're interested.
>>
>> David
>>
>>
>> On Tue, Nov 24, 2020 at 12:43 PM Tanya Tereshchenko 
>> wrote:
>>
>>> Previous action items
>>>
>>>- [david] To send out last call for feedback before merging
>>>https://github.com/pulp/pulp-ci/pull/737
>>>   - Hold off until after Github Actions move
>>>- [fao89] look at driving forward release automation.
>>>   - Automate post-release steps (branching, bumping to dev
>>>   versions, updating template config, etc)
>>>   - https://pulp.plan.io/issues/7817 (needs grooming, please
>>>   provide feedback)
>>>   - https://pulp.plan.io/issues/7818 (needs grooming)
>>>- [david] a Pulp query that shows issues for pulpcore (filters out
>>>installer, operator, etc)
>>>   - Done: https://pulp.plan.io/projects/pulp/issues?query_id=166
>>>- [david] move django fips repo to pulp
>>>   - Done: https://github.com/pulp/django/
>>>- [david] notify pulp-list mailing list of 3.9 release schedule
>>>- [ttereshc] file a task to have task management code manage working
>>>dir
>>>- [david] to start on tagging planning
>>>   - https://pulp.plan.io/issues/7127
>>>   - Started. Met with David Newswanger yesterday.
>>>   - Hope to have draft design by next week.
>>>
>>> <https://hackmd.io/XfI9DxymSAu6UJnblh7prQ?both#Topics>Topics
>>>
>>>- two feature plans pending for pulp-dev discussion
>>>   - parallelizing orphan cleanup while avoiding runtime
>>>   errors(ipanova)
>>>  - started writing down a proposal
>>>   - alternate content sources(bmbouter)
>>>  - needs feedback
>>>  - meeting with Katello next week
>>>  - https://pulp.plan.io/issues/7832
>>>   - RBAC pulpcore issue
>>>   - https://pulp.plan.io/issues/7710
>>>   - 3.9 blocker
>>>- how to remove a plugin, including the relevant data in the db
>>>   - pulpcore-manager command?
>>>  - checks if the plugin is installed
>>>  - if not, drops all _* tables?
>>>   - use cases
>>>  - migration plugin is the one which everyone would want to
>>>  remove eventually
>>> - it’s needed for katello
>>> - if no general solution is available, we will make some
>>> custom one for the migration plugin only
>>>  - incompatible plugins, one might want to remove one
>>>   - ttereshc to create a task
>>>- Validate existing group on pulpcore?
>>>   -
>>>   
>>> https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32
>>>   - pulpcore uses Django Group model, not a custom one, so likely
>>>   no need
>>>  -
>>>  
>>> https://github.com/django/django/blob/7af8f4127397279d19ef7c7899e93018274e2f9b/django/contrib/auth/models.py#L109
>>>   - 3.10 release
>>>   - Tentatively planned for Jan 8? due to holidays. Feedback
>>>   welcome.
>>>  - probably too early, maybe end of January?
>>> - Galaxy NG will likely need a release of pulpcore at the
>>> end of Jan’21
>>> - Conference driven release
>>> - Decide after 3.9 release
>>>  - Needs volunteer to release
>>>- An assumption in the ArtifactSaver stage that a d

Re: [Pulp-dev] Pulpcore meeting notes

[David Davis]

Thanks for taking notes and sorry I couldn't be at the meeting. Can you
explain more about the action item to give updates on the tagging story? I
was planning on following up on the mailing lists with updates since I
don't think the feature will be specific to pulpcore.

As for the automatic merge PR (https://github.com/pulp/pulp-ci/pull/737), I
wasn't planning on carrying forward an AI for it. I don't have any time to
address in the near future but I'm happy to hand it off to someone else if
they're interested.

David


On Tue, Nov 24, 2020 at 12:43 PM Tanya Tereshchenko 
wrote:

> Previous action items
>
>- [david] To send out last call for feedback before merging
>https://github.com/pulp/pulp-ci/pull/737
>   - Hold off until after Github Actions move
>- [fao89] look at driving forward release automation.
>   - Automate post-release steps (branching, bumping to dev versions,
>   updating template config, etc)
>   - https://pulp.plan.io/issues/7817 (needs grooming, please provide
>   feedback)
>   - https://pulp.plan.io/issues/7818 (needs grooming)
>- [david] a Pulp query that shows issues for pulpcore (filters out
>installer, operator, etc)
>   - Done: https://pulp.plan.io/projects/pulp/issues?query_id=166
>- [david] move django fips repo to pulp
>   - Done: https://github.com/pulp/django/
>- [david] notify pulp-list mailing list of 3.9 release schedule
>- [ttereshc] file a task to have task management code manage working
>dir
>- [david] to start on tagging planning
>   - https://pulp.plan.io/issues/7127
>   - Started. Met with David Newswanger yesterday.
>   - Hope to have draft design by next week.
>
> Topics
>
>- two feature plans pending for pulp-dev discussion
>   - parallelizing orphan cleanup while avoiding runtime
>   errors(ipanova)
>  - started writing down a proposal
>   - alternate content sources(bmbouter)
>  - needs feedback
>  - meeting with Katello next week
>  - https://pulp.plan.io/issues/7832
>   - RBAC pulpcore issue
>   - https://pulp.plan.io/issues/7710
>   - 3.9 blocker
>- how to remove a plugin, including the relevant data in the db
>   - pulpcore-manager command?
>  - checks if the plugin is installed
>  - if not, drops all _* tables?
>   - use cases
>  - migration plugin is the one which everyone would want to
>  remove eventually
> - it’s needed for katello
> - if no general solution is available, we will make some
> custom one for the migration plugin only
>  - incompatible plugins, one might want to remove one
>   - ttereshc to create a task
>- Validate existing group on pulpcore?
>   -
>   
> https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32
>   - pulpcore uses Django Group model, not a custom one, so likely no
>   need
>  -
>  
> https://github.com/django/django/blob/7af8f4127397279d19ef7c7899e93018274e2f9b/django/contrib/auth/models.py#L109
>   - 3.10 release
>   - Tentatively planned for Jan 8? due to holidays. Feedback welcome.
>  - probably too early, maybe end of January?
> - Galaxy NG will likely need a release of pulpcore at the end
> of Jan’21
> - Conference driven release
> - Decide after 3.9 release
>  - Needs volunteer to release
>- An assumption in the ArtifactSaver stage that a d_artifact always
>has a remote.
>   -
>   
> https://github.com/pulp/pulpcore/blob/master/pulpcore/plugin/stages/artifact_stages.py#L297
>  - Is it intentional?
> - Not intentional
> - move the check on line 300 couple of lines up
>  - Currently causes issues for the migration
>  - https://pulp.plan.io/issues/7876
>
> Action items
>
>- [david] To send out last call for feedback before merging
>https://github.com/pulp/pulp-ci/pull/737
>   - Hold off until after Github Actions move
>- [fao89] look at driving forward release automation.
>   - Automate post-release steps (branching, bumping to dev versions,
>   updating template config, etc)
>   - https://pulp.plan.io/issues/7817 (needs grooming, please provide
>   feedback)
>   - https://pulp.plan.io/issues/7818 (needs grooming)
>- [ttereshc] to file a task to implement plugin removal
>- [fao89] to figure out the use case for this fix
>
> https://github.com/ansible/galaxy_ng/pull/572/files#diff-6b9632eb49cb924f729282743cdac58a36f7625974fef12da2ea7b946ac19866R32
>- [david] updates on tagging planning https://pulp.plan.io/issues/7127
>
> ___
> Pulp-dev mailing 

Re: [Pulp-dev] pulpcore 3.9.0 release timeline and go/no-go irc meeting

[David Davis]

Today at the go/no-go meeting we decided to push back the release date by
one week to December 7th. This delay was caused by us needing to move off
Travis. We'll be using Github Actions to perform the release.

The next go/no-go meeting will be November 30 3:30pm UTC/November 30
10:30am ET.

David


On Tue, Nov 10, 2020 at 11:48 AM Tanya Tereshchenko 
wrote:

> Just fixed a typo. It's 3.9.0.
>
> On Tue, Nov 10, 2020 at 4:52 PM David Davis  wrote:
>
>> Here's the tracker for the pulpcore 3.8.0 3.9.0 release:
>> https://pulp.plan.io/issues/7789.
>> The tentative GA date is November 30th.
>>
>> The first go/no-go meeting will happen in #pulp-meeting at the time below:
>>
>> November 23 3:30pm UTC/November 23 10:30am ET
>> https://everytimezone.com/s/bc9ca71d
>>
>> 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

Re: [Pulp-dev] Migrating off Travis

[David Davis]

It looks like pulp was migrated over to the free plan on Travis. We used up
about 6400 minutes today so I've disabled all Travis builds for now to
conserve the remaining minutes.

Also, I've filed an epic to track the work to move to Github Actions. Feel
free to add tasks.

https://pulp.plan.io/issues/7859

David


On Fri, Nov 13, 2020 at 12:31 PM David Davis  wrote:

> A few of us met today to discuss moving the Pulp CI off Travis and onto
> Github Actions. I wanted to send out notes[0] and summarize the next steps.
>
> For Sprint 86, we hope to get pulp_npm fully working on Github Actions
> which will include getting tests, publishing docs and bindings, releasing,
> etc working on Github Actions. This will have the least impact on our users
> and other repos. Then we'll move the code from pulp_npm into
> plugin_template. After that, we'll start rolling it out to other plugins.
>
> We're also going to look at moving pulp_installer and pulp-fixtures off
> Travis.
>
> Any questions or comments are appreciated.
>
> [0] https://hackmd.io/kJsJCWlHRmiH5BA__M-2dg?edit
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Migrating off Travis

[David Davis]

A few of us met today to discuss moving the Pulp CI off Travis and onto
Github Actions. I wanted to send out notes[0] and summarize the next steps.

For Sprint 86, we hope to get pulp_npm fully working on Github Actions
which will include getting tests, publishing docs and bindings, releasing,
etc working on Github Actions. This will have the least impact on our users
and other repos. Then we'll move the code from pulp_npm into
plugin_template. After that, we'll start rolling it out to other plugins.

We're also going to look at moving pulp_installer and pulp-fixtures off
Travis.

Any questions or comments are appreciated.

[0] https://hackmd.io/kJsJCWlHRmiH5BA__M-2dg?edit

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

[Pulp-dev] pulpcore 3.9.0 release timeline and go/no-go irc meeting

[David Davis]

Here's the tracker for the pulpcore 3.8.0 release:
https://pulp.plan.io/issues/7789.
The tentative GA date is November 30th.

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

November 23 3:30pm UTC/November 23 10:30am ET
https://everytimezone.com/s/bc9ca71d

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

[Pulp-dev] Pulpcore meeting notes

[David Davis]

## November 10, 2020

### Previous action items
* [david] To send out last call for feedback before merging
https://github.com/pulp/pulp-ci/pull/737
* ~~[dkliban] file a task for running tests for multiple plugins in one
fips environment in the installer nightly~~
* [fao89] look at driving forward release automation.
* Automate post-release steps (branching, bumping to dev versions,
updating template config, etc)
* [david] a Pulp query that shows issues for pulpcore (filters out
installer, operator, etc)
* [david] move django fips repo to pulp
* [david] schedule go/no-go for nov 24
* Done
* ~~[x9c4] to follow up on mailing list with proposal for setting pulpcore
requirements for plugins [done]~~

### Topics
* Review 3 month planning
* Correlation ID PR https://github.com/pulp/pulpcore/pull/1017
* Ready for review
* No log messages from CI container
* Skip log check
* WorkingDirectory
* https://github.com/pulp/pulp_rpm/pull/1879#issuecomment-724653199
* Have task management code manage working directory in 3.9
* Remove WorkingDirectory in 3.10

### Action Items
* [david] To send out last call for feedback before merging
https://github.com/pulp/pulp-ci/pull/737
* [fao89] look at driving forward release automation.
* Automate post-release steps (branching, bumping to dev versions,
updating template config, etc)
* [david] a Pulp query that shows issues for pulpcore (filters out
installer, operator, etc)
* [david] move django fips repo to pulp
* [david] notify pulp-list mailing list of 3.9 release schedule
* [ttereshc] file a task to have task management code manage working dir
* [david] to schedule handoff meeting with bmbouter for tagging planning

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