Re: [Pulp-dev] pulpcore team meeting notes - May 25, 2021

[Neal Gompa]

Brian,

That's awesome! I'll also note that a variation of this workflow would
be desired for mirrors too, such as mirroring distributions or
prominent third-party repos (EPEL, Packman, COPRs, OBS repos, etc.).

On Thu, Jun 3, 2021 at 11:11 AM Brian Bouterse  wrote:
>
> Thank you for sharing this use case outline with me. I am hoping we can 
> prioritize rbac work like this. It's very important.
>
> On Wed, Jun 2, 2021 at 11:35 AM Neal Gompa  wrote:
>>
>> Hey Brian,
>>
>> Yes, for sure! I'm basically looking into using RBAC to support a
>> workflow like so:
>>
>> * Automation via a service account imports RPMs and DEBs into a pool
>> * Automation via another service account selects those packages to
>> publish into various staging repos
>> * Select users/groups can promote those packages to their assigned
>> "stable" repos
>>
>> The idea is that I can partition ACLs for various functions of Pulp to
>> prevent unwanted actions.
>>
>>
>> On Wed, Jun 2, 2021 at 10:56 AM Brian Bouterse  wrote:
>> >
>> > Hi Neal,
>> >
>> > Apologies for the late reply. We've added the RBAC to various endpoints in 
>> > pulpcore and some plugins, but what I think would be helpful is if we had 
>> > a way to more clearly identify what has RBAC and what doesn't across 
>> > pulpcore and plugins. Would that be helpful?
>> >
>> > Thank you,
>> > Brian
>> >
>> >
>> > On Tue, May 25, 2021 at 11:46 AM Neal Gompa  wrote:
>> >>
>> >> On Tue, May 25, 2021 at 11:23 AM Brian Bouterse  
>> >> wrote:
>> >> >
>> >> > * Making top-level Authentication page in docs
>> >> > * https://pulp.plan.io/issues/8799
>> >>
>> >> The docs currently mention that RBAC stuff is planned, is there
>> >> something that shows the status of that? This is something that I'd
>> >> love to see in Pulp sooner rather than later...
>> >>
>> >>
>> >> --
>> >> 真実はいつも一つ！/ Always, there's only one truth!
>> >>
>>
>>
>> --
>> 真実はいつも一つ！/ 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

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

[Brian Bouterse]

I did this also for the pulpcore meeting:
https://github.com/pulp/community/discussions/8

My format was a little different, but the same idea.

On Thu, Jun 3, 2021 at 10:13 AM Grant Gainey  wrote:

> On Thu, Jun 3, 2021 at 9:40 AM David Davis  wrote:
>
>> Based on feedback, I've moved discussions to its own repo:
>> https://github.com/pulp/community/discussions.
>>
>
> Brillliant!
>
> One discovery I made this week - for 'Meetings' threads that exist to have
> meeting-minutes posted, the first entry should be a description of what the
> meeting you're recording is for, and each set of minutes should be a
> comment. This lets the reader sort by "Newest" and get
> most-recent-minutes-first.The initial message in a discussion is always at
> the top, no matter how you sort - so if it's your first meeting-minutes,
> they'll always be first.
>
> I redid the katello/pulp and community/pulp integration discussion-threads
> (in their new location) in light of this, apologies to anyone who got some
> notification-spam as a result this morning.
>
>- https://github.com/pulp/community/discussions/7
>- https://github.com/pulp/community/discussions/4
>
> G
>
>>
>> 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-list mailing list
>> pulp-l...@redhat.com
>> https://listman.redhat.com/mailman/listinfo/pulp-list
>
>
>
> --
> 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] Pulp Installers team meeting minutes 2021-05-27 & 2021-06-03

[Mike DePaulo]

## Jun 03 Agenda
* [mikedep333] I don't think we should specify the pulpcore-selinux version
in the release script
* The installer never installs the master branch anyway.
* We'll need the fixes of the latest pulpcore-selinux version in the
pulp master branch.
* It's good to have the fixes in the changelog when we bump it via a
pulp_installer PR.
* Alternatives could include having it track a branch for devel
installs, and specify the version at release time.
* We'll need separate selinux policies for pulpcore stable release
branches eventually.

## May 27 Agenda
* Is fao89 the primary pulp_installer maintainer still, or is mikedep333 it
again?
* [agreed] mikedep333 will step up
* ansible 4.0.0 is out!
* read more about the changes later
* continue to support the last 2, or possibly last 3, versions of
ansible-base
* [RPM signing service script PR from months ago](
https://github.com/pulp/pulp_installer/pull/371)
* Agreed: mike to rebase. If it doesn't work, either fix it, or hand it
off.
* Also, pulpcore-manager command can install it. (rather than the shell)
* Operator nodeports
*
https://github.com/operate-first/support/issues/176#issuecomment-848976108
* https://pulp.plan.io/issues/8833
* Not doing a pulp_installer release for each micro release
* This is similar to the original plan for the installer to revolve
around minor release of pulpcore & of plugins.
* Original discussion:
* [mikedep333's proposal](
https://github.com/pulp/pulp_installer/pull/203#issue-361269733)
* [bmbouter's couter-proposal to do micro-versioned releases](
https://github.com/pulp/pulp_installer/pull/203#issuecomment-577903411)
* [mikedep333's agreement/details for micro-versioned releases](
https://github.com/pulp/pulp_installer/pull/203#issuecomment-579450153)
* Lack of CI on branches (or at least I don't see it.)
* This is partially mitigated currently by doing releases.
* Common breakage we catch is that python package needs to be
pinned for pulp to actually install (e.g., pip)
* Implementation would include:
* `pulpcore_update` variable (false for idempotency)
* I'm noticing lots of instances where we update code/docs in some places,
but not in the other places. (molecule tests, GHA workflows, especially)
* FIPS runners disabled from PR due to GHA runners being blocked, still
running on nightly
* https://github.com/pulp/pulp_installer/pull/632
* agreed: This was part of the plan all along. (If the FIPS tests take
up too much time, we'll disable them at PR time.)


-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat 

IM: mikedep333

GPG: 51745404

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

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

[Grant Gainey]

On Thu, Jun 3, 2021 at 9:40 AM David Davis  wrote:

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

Brillliant!

One discovery I made this week - for 'Meetings' threads that exist to have
meeting-minutes posted, the first entry should be a description of what the
meeting you're recording is for, and each set of minutes should be a
comment. This lets the reader sort by "Newest" and get
most-recent-minutes-first.The initial message in a discussion is always at
the top, no matter how you sort - so if it's your first meeting-minutes,
they'll always be first.

I redid the katello/pulp and community/pulp integration discussion-threads
(in their new location) in light of this, apologies to anyone who got some
notification-spam as a result this morning.

   - https://github.com/pulp/community/discussions/7
   - https://github.com/pulp/community/discussions/4

G

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



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