Re: [Pulp-dev] saftladen pulp's take on asciinema?

[Daniel Alley]

>
> Like a juice store whose shopman tells you no orange juice today, next
> delivery in two weeks.
>

Reminds me of this Monty Python sketch

https://www.youtube.com/watch?v=Hz1JWzyvv8A

On Thu, Aug 6, 2020 at 3:24 AM Matthias Dellweg  wrote:

>
>
> On Wed, Aug 5, 2020 at 8:02 PM Robin Chan  wrote:
>
>> I looked it up and according to the internets saftladen means juice store?
>>
> In the literal translation...  It has a second meaning, where you use it
> to paraphrase an organization in a slightly disrespectful manner that has
> disappointed you.
> Like a juice store whose shopman tells you no orange juice today, next
> delivery in two weeks.
> This very repository contains a bunch of tools hacked together in an
> afternoon. So it will either do exactly what you need, or it will frustrate
> you badly.
>
>> Could be a nice easter egg for the readme. :-)
>> +1 to Ina's suggestions those are great ideas.
>>
>> Robin Chan
>>
>> She/Her/Hers
>>
>> Satellite Software Engineering Manager - Pulp
>>
>> Red Hat 
>>
>> IRC: rchan
>>
>> Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> 
>>
>>
>>
>> On Wed, Aug 5, 2020 at 6:22 AM Ina Panova  wrote:
>>
>>> This is great, +1 to the automation business.
>>> Even though shell scripts are quite self explanatory, could you write
>>> some Readme?
>>> We could eventually add this to our Wiki
>>> https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes#Recording-a-Video
>>>
>>>
>>> 
>>> 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, Jul 30, 2020 at 5:38 PM Matthias Dellweg 
>>> wrote:
>>>
 Hi list,
 as much as animations help our documentation to be appealing, as
 little appealing it sounded to me to record a demo over and over until
 i liked it. But what can i say: We are in the automation business. So
 this adventure ended in a set of tools to generate an asciinema
 demonstration from a rather simple shellscript, wrapped in a Makefile
 to be able to adjust and rerecord it over and over. Let's hope i can
 encourage you all to add similar demos to that repository:

 https://github.com/mdellweg/saftladen

 Cheers, Matthias

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

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

Re: [Pulp-dev] RBAC Status Thread

[Brian Bouterse]

# Update:

django-lifecycle merged + released, and all tests are passing on Travis
now  https://github.com/pulp/pulpcore/pull/815/files


# Regarding assigning permissions to objects created prior to RBAC...

I now believe we do not need to apply permissions for the 'admin' user, and
that is the only user we could expect at migration time because it's the
only user we deal with prior to 3.6. I've learned that by default,
django-guardian considers any user with `is_superuser=True` to have the
permission being checked. As such the 'admin' user already sidesteps RBAC
anyway. So my next step in this area is to add this to the docs only.
Plugin writers will *not* need to add permissions for prior existing
objects.




On Wed, Aug 5, 2020 at 5:59 PM Brian Bouterse  wrote:

> Alright we're close to the end of pulpcore's RBAC additions for 3.6, but
> there are still some challanges! Here's what's been accomplished:
>
> * The tests are now passing locally
>   * We are waiting on django-lifecycle to merge my PR and release it
> https://github.com/rsinger86/django-lifecycle/pull/58 We actually can't
> release on my fork (PyPI install_requires won't work with git checkouts
> I've learned) so if he can't release django-lifecycle by Friday then I'm
> going to push an alternate package to PyPI in the meantime under a
> different name. This is what #python recommended to me. I have emailed the
> author asking for review and release so I'm hoping it does not come to that
> * lots more docs have been written
> * I can't show the tests passing on Travis until this django-lifecycle
> issue is resolved, so I'm going to keep the WIP on it until then.
>
> User docs are still needed, I'm working on those tomorrow
>
> Please do review, I want to merge on Friday to be included in 3.6.
>
>
> On Fri, Jul 31, 2020 at 4:58 PM Brian Bouterse 
> wrote:
>
>> A lot of plugin writer docs about adding RBAC support have been added to
>> the newly opened WIP PR: https://github.com/pulp/pulpcore/pull/815/files
>> Please come review the WIP PR. Code-wise it's 90% there, with just a few
>> polish things I still need to finish. From a high level I still need to:
>>
>> * finish the plugin writer docs
>> * add users docs (smaller and easier than plugin writer docs)
>> * ensure all the changelogs and issues are good
>> * get Tasks showing with their object-level permissions in the
>> Django-admin
>> * fix the tests so they are passing on Travis
>>
>> The plan is to have this go into 3.6 to be released Aug 11th.
>>
>> The other big area of work (also for 3.6) is that galaxy_ng is needing
>> Groups (and because of that Users) APIs added for read-only. Those stores
>> got a lot of grooming today and are linked to below. @fabricio is taking
>> the lead on implementing that. Thanks @fabricio!
>>
>> https://pulp.plan.io/issues/7231
>> https://pulp.plan.io/issues/7232
>>
>> Feedback and other concerns are welcome.
>>
>>
>> On Fri, Jul 24, 2020 at 4:58 PM Brian Bouterse 
>> wrote:
>>
>>> I've gotten various feedback and I want to relay some of the changes
>>> based on that.
>>>
>>> 1) Pulp should ship a "user isolation" policy by default. If users want
>>> other things they can configure it further. This is a change from my
>>> original proposal of Pulp shipping an "RBAC is off" policy. This will work
>>> for Katello because all Katello calls show up as one user anyway.
>>>
>>> 2) We have challenges around assigning permissions. This is the proposed
>>> solution that was discussed at open floor today:
>>> https://pulp.plan.io/issues/7210  I've added this to my pulpcore PR
>>> (link below)
>>>
>>> https://github.com/pulp/pulpcore/compare/master...bmbouter:rbac-PoC
>>>
>>>
>>>
>>> On Fri, Jul 10, 2020 at 2:20 PM David Davis 
>>> wrote:
>>>
 On Wed, Jul 8, 2020 at 4:54 PM Brian Bouterse 
 wrote:

> My next goal is to have object-level permissions assigned through
> signals so that anywhere you save the model the permissions are correctly
> created. To do this I need to get a few things working:
>
> 1) Move the permissions creation to the signals [done]
> 2) Have the user be well-known, this is accomplished by pulpcore
> picking up this dependency
> https://github.com/PaesslerAG/django-currentuser [done]
> 3) Have the user information persisted in tasks so signals can work
> there also ... there are two obvious options
>
> option a) Have tasks themselves have RBAC which we know we need
> anyway, then query the RBAC permissions inside a task to determine which
> user has the object level permissions for this task. This is what I'm
> currently prototyping. It at least will provide a mechanism we can use for
> now until we find something better.
>

 Are task permissions mutable? If so, then what happens if someone kicks
 off a task and then this permission gets removed?


>
> option b) Add a user field to the Task itself and have the RBAC assign
> 

Re: [Pulp-dev] Dealing with our redmine backlog

[Ina Panova]

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, Aug 5, 2020 at 8:54 PM David Davis  wrote:

> We've been discussing the possibility of closing issues in redmine due to
> the overwhelming number of issues at NEW. Currently, we have 930 issues at
> NEW and I think that exceeds our capacity to address each issue
> individually.
>
> The first item I want to bring up for discussion is expanding the ability
> for users to reopen closed issues. Currently only authors can reopen issues
> at CLOSED excluding CLOSED - DUPLICATE and CLOSED - COMPLETE. Should we
> expand this to all redmine users?
>

+1 to expand it to all users.

>
> If we expand this permission, this should give us the ability to safely
> close out issues that fit some criteria. I looked at the pulpcore issues
> and limited the issues to just ones without a Katello tag or a BZ and that
> were created before 2020[0]. This still leaves us with almost 300 NEW
> issues in pulpcore which still seems unrealistic to go through. Any
> thoughts on what criteria to use?
>

We could also exclude issues that have Pulp2 tag.
Even if we end up having 300 issues to process, I know that sounds a lot,
but we can regularly dedicate 5 mins(timeboxed!) of our pulpcore team
meeting, or open floor to go through. For some issues it is enough to read
the title to make a decision.
I *think* this might be a feasible idea, look how many and good
improvements we did in redmine having it on the agenda for each open floor.

Alsom, what will be the state of the issues we are going to mass close -
CLOSED-WON'TFIX?

>
> [0] It would be better to use updated at to scope issues but unfortunately
> a lot of older issues have been updated recently due to spam comment
>

> 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] Container plugin meeting notes

[Ina Panova]

August 5 , 2020

Pulp 3:

   -

   Discussed purpose of PulpTempFile and how it works
   -

  Lubos will continue to work on adding it to pulp_container
  -

   Disable cherrypick -- needs a task?dkliban will open
   -

  https://pulp.plan.io/issues/7278 work on the upcoming sprint
  -

   Let’s review and merge https://github.com/pulp/pulp_container/pull/127 I
   doubt we will have a release of pulp_container before pulpcore release
   -

   Signed schema on conversion https://pulp.plan.io/issues/7113
   -

  Close issue
  -

  Quay is not signing anymore, ipanova asked why
  -

   As a user i can push my content to a repo but make it available later
   -

  Ipanova will open a story
  -

   One last item left to close 2.0 milestone. We want to release 2.0 GA
   once pulpcore 3.6 is available
   -

  Mdellweg will take on last item

Pulp 2:

   -


Open PRs:

   -

   https://github.com/pulp/pulp_docker/pulls
   -

   https://github.com/pulp/pulp_container/pulls
   -

Triage:

   -

   Un-triaged bugs
   https://pulp.plan.io/projects/pulp_container/issues?query_id=30
   -

   https://pulp.plan.io/projects/pulp_docker/issues?query_id=30




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://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] saftladen pulp's take on asciinema?

[Matthias Dellweg]

On Wed, Aug 5, 2020 at 8:02 PM Robin Chan  wrote:

> I looked it up and according to the internets saftladen means juice store?
>
In the literal translation...  It has a second meaning, where you use it to
paraphrase an organization in a slightly disrespectful manner that has
disappointed you.
Like a juice store whose shopman tells you no orange juice today, next
delivery in two weeks.
This very repository contains a bunch of tools hacked together in an
afternoon. So it will either do exactly what you need, or it will frustrate
you badly.

> Could be a nice easter egg for the readme. :-)
> +1 to Ina's suggestions those are great ideas.
>
> Robin Chan
>
> She/Her/Hers
>
> Satellite Software Engineering Manager - Pulp
>
> Red Hat 
>
> IRC: rchan
>
> Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> 
>
>
>
> On Wed, Aug 5, 2020 at 6:22 AM Ina Panova  wrote:
>
>> This is great, +1 to the automation business.
>> Even though shell scripts are quite self explanatory, could you write
>> some Readme?
>> We could eventually add this to our Wiki
>> https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes#Recording-a-Video
>>
>>
>> 
>> 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, Jul 30, 2020 at 5:38 PM Matthias Dellweg 
>> wrote:
>>
>>> Hi list,
>>> as much as animations help our documentation to be appealing, as
>>> little appealing it sounded to me to record a demo over and over until
>>> i liked it. But what can i say: We are in the automation business. So
>>> this adventure ended in a set of tools to generate an asciinema
>>> demonstration from a rather simple shellscript, wrapped in a Makefile
>>> to be able to adjust and rerecord it over and over. Let's hope i can
>>> encourage you all to add similar demos to that repository:
>>>
>>> https://github.com/mdellweg/saftladen
>>>
>>> Cheers, Matthias
>>>
>>> ___
>>> 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