[Pulp-dev] Pulp Installer - Cluster Install | Request for feedbacks

2020-06-22 Thread Yanis Guenane
Hello all,

I wanted/needed to deploy a Pulp 3 cluster (via Pulp Installer) and I
couldn't find a sample to get me started.

So I created the following repo[1] to show live/hands on examples of how
the pulp installer could be used to deploy a cluster install.

In a nutshell the installer almost works out of the box for cluster
install. I have found myself needing only few tweaks:

  * Ensure DB migration use the `run_once` pattern[2]
  * Ensure Redis is not an hardcoded dependency for workers and resource
manager[3]
  * Ensure one can specify on which IP Redis can be listening[4]

All of the aforementioned patches are now merged in main branch.

The example in the repo[1] is with 3 all-in-one nodes, but it can be easily
extended to any kind of topology one seems fit.

If you have any feedback, see things done incorrectly, etc... I'd love
to hear it and improve the mentioned playbook.

Thanks in advance,


[1] https://github.com/Spredzy/pulp-installer-scenarios
[2] https://github.com/pulp/pulp_installer/pull/331
[3] https://github.com/pulp/pulp_installer/pull/332
[4] https://github.com/pulp/pulp_installer/pull/324


-- 
*Yanis Guenane*
Principal Software Engineer, Ansible Automation Platform
Red Hat  | IM: Spredzy
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


Re: [Pulp-dev] RBAC Status Thread

2020-06-22 Thread Brian Bouterse
# ldap PoC updates
Now users, groups, and group membership are populating from ldap
automatically on login (with auth backed by ldap also)! I'll be sharing my
configs for both ldap and how to configure django-auth-ldap
 here soon
in an organized way. This was done with django-auth-ldap and 0
customization to pulp code. It's 100% enabled through settings so this work
is more of an approach we can document for users that they can enable and
not a feature Pulp ships itself.

# django-admin progress
Thanks to @alikins existing PRs, I got django admin enabled and able to
view/edit users, groups, group membership, and permissions at both the user
and group levels. This is important because this will be the primary
mechanism of administrators. This part is looking good.

# new resources to help us out
Through collaboration with @ttereshc and someone off list named @adelton
(who actually authored this reference approach

I referenced early on in this exploration), this very cool repository of
testing tools was identified:  https://github.com/adelton/webauthinfra  It
has a treasure trove of testing containers which Pulp devs in the future
can test against. It keeps the user/group check in the apache which is fine
alternative to the django-auth-ldap approach above. Pulp doesn't have to
choose, it could work with either just configured differently. The pending
PoC outline will go over these alternative approaches in detail.

# Next Steps:  back to the PoC itself
Now that we have demonstrated good options of external
users/groups/membership loading into Pulp we can confidently move back to
finishing the RBAC PoC itself. I've started back into this. So the
remaining work are the two steps below:

1. Finish the PoC that uses RBAC to restrict remotes, sync, and repository
content modification. Currently I prototyped restriction of operations on
Remotes, but I need to replicate the access policies to Repositories and
Sync next.
2. Write it up and share it.
3. Schedule public meeting to review it (targeting next-week)



On Fri, Jun 19, 2020 at 5:09 PM Brian Bouterse  wrote:

> I got the LDAP users both authenticating and importing into Pulp! Next
> I'll do the groups and then I think the ldap parts will be done.
>
> FYI: I'm going to write up the implementation design and have that come
> with this proof of concept code . This will let us know what choices it
> makes, why it makes them, and we can determine if these are the right
> choices together.
>
> On Wed, Jun 17, 2020 at 4:57 PM Brian Bouterse 
> wrote:
>
>> I got a lot further on this today. I have the test ldap setup with
>> several test users and groups. I have django-auth-ldap configured mostly
>> authenticating username/password against ldap instead of the internal
>> database first. Once that is fully working the users will auto-populate
>> into django and the groups should follow easily.
>>
>> Once that's done I'll be unblocked to finish the RBAC PoC. The rest of
>> the parts are straightforward given the testing I've already done. More
>> updates to come.
>>
>> On Mon, Jun 15, 2020 at 5:03 PM Brian Bouterse 
>> wrote:
>>
>>> I got the ldap reference implementation performing auth really nicely
>>> against a test ldap with this guide:
>>> https://www.nginx.com/blog/nginx-plus-authenticate-users/ Now there are
>>> some new challenges though:
>>>
>>> * Great that we can auth users, but we need nginx to extract-and-forward
>>> the group information to Pulp itself. That way a middleware can create the
>>> user AND group info in the backend.
>>> * we have to figure this out all again in Apache...
>>>
>>> Maybe we should be integrating Pulp directly against django-auth-ldap
>>> [0]. I am going to try that next. The work I've done isn't 100% reusable
>>> there, but most of it is because the test server and configs I used can all
>>> be reused directly with django-auth-ldap. The concern with this approach is
>>> that we would be supporting LDAP (and transitively Active Directory) but
>>> are there other directory services Pulp needs to support?
>>>
>>> I also emailed Bin Li asking for info on how their user and group
>>> management works.
>>>
>>> On Tue, Jun 9, 2020 at 11:48 AM Adrian Likins 
>>> wrote:
>>>


 On Fri, Jun 5, 2020 at 8:23 PM Brian Bouterse 
 wrote:

>
> 1) django admin (the built in django UI) will be the mechanism
> administrators use to assign permissions to users and groups. This means
> the use of django admin with pulp is very likely (to me).
>
> Hopefully https://github.com/pulp/pulpcore/pull/705 will be useful
 here.


> 2) externally defined users and groups will need to be "replicated" to
> django's db at login time, probably using headers from the webserver This
> is consistent w/ the approach recommended here:
> 

[Pulp-dev] 2.21.3 release schedule

2020-06-22 Thread Tatiana Tereshchenko
A 2.21.3 release is being planned with recent fixes. Here [0] is a release
schedule which outlines some tentative dates, starting with a* dev freeze*
on Thursday, *June 25*, 2020  @ 17:00 UTC.
A query with the list of bug fixes to be released will be added to the
release schedule page.

Tanya

[0] https://pulp.plan.io/projects/pulp/wiki/2213_Release_Schedule
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


[Pulp-dev] Pulp Container meeting notes

2020-06-22 Thread Ina Panova
Pulp 3:

   -

   Token auth refactor
   -

  Ready for review https://github.com/pulp/pulp_container/pull/103
  - Next on the list is to add token with admin rights
  -

   Black formatting against 2.0 branch enabled. Thanks davidavis!
   -

   List of work that needs to be done before 2.0 release
   -

  https://tinyurl.com/ya4t993x
  - start with push repo type, other works depends on it
  -

   Investigate how to use chunk uploads from core (opened, aligned to 2.0
   milestone)
   -

  https://pulp.plan.io/issues/7025
  -

   Performance issue
   -

  https://pulp.plan.io/issues/6940
  - Lubos will pick it up


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