Re: [Pulp-dev] Draft Community Demo - Your Opinion Please

[Robin Chan]

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 Thu, Jul 23, 2020 at 12:37 PM David Davis  wrote:

> Thanks for working on this. Responses inline below.
>
> David
>
>
> On Thu, Jul 23, 2020 at 11:55 AM Melanie Corr  wrote:
>
>> Hi all,
>>
>> I need your help in shaping the survey[0].
>>
>> I copied over some questions from last year's survey and added what I
>> thought might be interesting. Last year's survey contains a lot of
>> "planning" questions for future upgrades to Pulp 3. Many things have
>> changed since then, and I think you know best where we need to focus.
>>
>> I added conditions to the survey to try and separate the following:
>>
>> * Questions for Pulp 2 Users
>> * Questions for Pulp 3 Users
>> * Questions for people who are in-between their migration. This last
>> category of user may exist only in my head. Let me know :)
>>
>
>> Questions for you:
>>
>> Do you think streaming the survey into separate user groups like this is
>> a good idea?
>>
>
> Is it possible though to compare the results across surveys (like what OS
> people are using)?
>
>
>>
>> With the Pulp 2 survey, do we want to collect, for example, what version
>> of MongoDB they're using? I'm assuming we ultimately want to guide users
>> away from Pulp 2, so most of what I added related to a future migration to
>> Pulp 3. I kept all the "what features would you like" type questions for
>> the Pulp 3 part of the survey and focused on what they need to get away
>> from Pulp 2. What do you think?
>>
>
> For Pulp 2, I would ditch most of the questions that aren't relevant to
> why they are still on Pulp 2 and what their upgrade/trial experience of
> Pulp 3 is like (if any).
>

Agreed. I think the EOL on Pulp 2 was a question just to try to get that
info out/awareness.


>
>
>>
>> For the Pulp 3 users, are there any areas I haven't covered where you
>> want to focus and learn their experiences?
>>
> What content types they are using. What features they want still. anything
we need to know to get users to use Pulp 3 (start or move to).


>
>>
>
>> I asked Greg Sutcliffe, the MBU's Data Analyst, a question related to
>> rewording I was doing on one question. One piece of advice he gave me was
>> to beware of asking about solutions to complex problems. For example, on
>> his advice, I changed "If there was a Pulp 3 web-based interface, would you
>> use it?" from the 2019 survey to "Do you need a Pulp 3 web UI for your
>> environment?" with the follow-up question to describe that workflow if they
>> answer yes. He said to focus the questions on their experiences and their
>> problems rather than having them propose hypothetical solutions.
>>
>
> +1, good idea.
>
agreed. no leading questions. I think before we asked a similar question
about the cli. "Would like a free cookie" vs. "what do you need right now"


>
>
>>
>> Feel free to reply here or enter "That is a terrible question, Melanie"
>> into the survey :)
>> Am happy to apply any feedback.
>>
>> [0]
>> https://forms.gle/aynaM4d4wX5Aterz5
>>
>>
>>
>>
>>
>> --
>>
>> Melanie Corr, RHCE
>>
>> Community Manager
>>
>> Red Hat 
>>
>> Remote, Ireland
>>
>> mc...@redhat.com
>> M: +353857774436 IM: mcorr
>> 
>>
>> ___
>> 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] Draft Community Demo - Your Opinion Please

[David Davis]

Thanks for working on this. Responses inline below.

David


On Thu, Jul 23, 2020 at 11:55 AM Melanie Corr  wrote:

> Hi all,
>
> I need your help in shaping the survey[0].
>
> I copied over some questions from last year's survey and added what I
> thought might be interesting. Last year's survey contains a lot of
> "planning" questions for future upgrades to Pulp 3. Many things have
> changed since then, and I think you know best where we need to focus.
>
> I added conditions to the survey to try and separate the following:
>
> * Questions for Pulp 2 Users
> * Questions for Pulp 3 Users
> * Questions for people who are in-between their migration. This last
> category of user may exist only in my head. Let me know :)
>

> Questions for you:
>
> Do you think streaming the survey into separate user groups like this is a
> good idea?
>

Is it possible though to compare the results across surveys (like what OS
people are using)?


>
> With the Pulp 2 survey, do we want to collect, for example, what version
> of MongoDB they're using? I'm assuming we ultimately want to guide users
> away from Pulp 2, so most of what I added related to a future migration to
> Pulp 3. I kept all the "what features would you like" type questions for
> the Pulp 3 part of the survey and focused on what they need to get away
> from Pulp 2. What do you think?
>

For Pulp 2, I would ditch most of the questions that aren't relevant to why
they are still on Pulp 2 and what their upgrade/trial experience of Pulp
3 is like (if any).


>
> For the Pulp 3 users, are there any areas I haven't covered where you want
> to focus and learn their experiences?
>

>

> I asked Greg Sutcliffe, the MBU's Data Analyst, a question related to
> rewording I was doing on one question. One piece of advice he gave me was
> to beware of asking about solutions to complex problems. For example, on
> his advice, I changed "If there was a Pulp 3 web-based interface, would you
> use it?" from the 2019 survey to "Do you need a Pulp 3 web UI for your
> environment?" with the follow-up question to describe that workflow if they
> answer yes. He said to focus the questions on their experiences and their
> problems rather than having them propose hypothetical solutions.
>

+1, good idea.


>
> Feel free to reply here or enter "That is a terrible question, Melanie"
> into the survey :)
> Am happy to apply any feedback.
>
> [0]
> https://forms.gle/aynaM4d4wX5Aterz5
>
>
>
>
>
> --
>
> Melanie Corr, RHCE
>
> Community Manager
>
> Red Hat 
>
> Remote, Ireland
>
> mc...@redhat.com
> M: +353857774436 IM: mcorr
> 
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 3/Katello integration meeting notes

[David Davis]

July 23, 2020

Pulp

   -

   Core
   -

  Move to OpenAPI v3 in pulpcore 3.6
  -

 Some of the binding method signatures will change (names and order
 of args)
 -

 https://www.redhat.com/archives/pulp-dev/2020-July/msg00061.html
 -

  Added toc= support for import (see PR#794
  )
  -

  3.6 will introduce RBAC which may not impact katello as long as all
  calls occur with the same user.
  -

  https://pulp.plan.io/issues/6989 - could not reproduce with 3.5.0
  -

 Iballou to revisit/reproduce
 -

   RPM
   -

  PIE: remaining advisory models waiting on low-level model fix
  -

  Modular advisory bug is fixed
  -

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

  DistributionTrees, new approach - usual content type
  -

 No recursive copy in 3.5
 -

  3.5 should be out this week, compatible with pulpcore 3.4
  -

   Migration
   -

  Errata migration bugs are fixed
  -

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

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

  DistributionTree migration was blocked by RPM work, it’s the next
  priority item
  -

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

  Memory consumption issue, PR is up
  -

 https://github.com/pulp/pulp-2to3-migration/pull/179
 -

  Fedora repos migration issues found
  -

 “Large package migration issue”, ultimately probably not specific
 to Fedora
 -

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

   SELinux
   -

  Discovered katello is not running Pulp3 in a constrained mode so
  SELinux is installed but not en-force
  -

 https://github.com/theforeman/puppet-pulpcore/pull/116
 -

   Certguard
   -

  1.0.1 was released, no changes except compatible with pulpcore 3.5


Katello

   -

   Most blockers from last week completed
   -

  https://pulp.plan.io/issues/6950 - WIP


Topics

   -

   https://pulp.plan.io/issues/7186 - Try with a different
   download_concurrency to see if that helps fix the problem
   - https://pulp.plan.io/issues/6989 - Couldn’t reproduce


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

Re: [Pulp-dev] pulp_deb plugin maintenance meeting

[Dennis Kliban]

I would like to participate. Can we move the meeting time to 14:00 o'clock
CEST ?

On Tue, Jul 21, 2020 at 10:11 AM Quirin Pamp  wrote:

> Hi everyone,
>
> I would like to propose a meeting on handling pulp_deb plugin maintenance.
>
> I will contact several people individually, that I think should be there,
> but I also wanted to announce on the mailing list in case anyone is
> interested who is not on my radar.
>
> I propose Monday, July 27th, 13:00 o'clock CET as a preliminary date, but
> this will likely still change, since I have not yet checked with anyone's
> schedule.
>
> Feel free to propose a different time, or amend the Agenda here:
>
> [1] https://hackmd.io/kGjFFGtWTJSGuIDlVlgqZw
>
> thanks,
> Quirin Pamp
>
> ___
> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Distribution Tree model changes
   -

  https://github.com/pulp/pulp_rpm/pull/1782
  -

   3.5 branching/release once DistTree change is merged
   -

   UpdateCollection model fixes and uniqueness - in progress


Pulp 2:

   -

   https://pulp.plan.io/issues/7141 - closed as works for me, but
   continuing to investigate with Katello devs to find a different reproducer


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Draft Community Demo - Your Opinion Please

[Melanie Corr]

Hi all,

I need your help in shaping the survey[0].

I copied over some questions from last year's survey and added what I
thought might be interesting. Last year's survey contains a lot of
"planning" questions for future upgrades to Pulp 3. Many things have
changed since then, and I think you know best where we need to focus.

I added conditions to the survey to try and separate the following:

* Questions for Pulp 2 Users
* Questions for Pulp 3 Users
* Questions for people who are in-between their migration. This last
category of user may exist only in my head. Let me know :)

Questions for you:

Do you think streaming the survey into separate user groups like this is a
good idea?

With the Pulp 2 survey, do we want to collect, for example, what version of
MongoDB they're using? I'm assuming we ultimately want to guide users away
from Pulp 2, so most of what I added related to a future migration to Pulp
3. I kept all the "what features would you like" type questions for the
Pulp 3 part of the survey and focused on what they need to get away from
Pulp 2. What do you think?

For the Pulp 3 users, are there any areas I haven't covered where you want
to focus and learn their experiences?

I asked Greg Sutcliffe, the MBU's Data Analyst, a question related to
rewording I was doing on one question. One piece of advice he gave me was
to beware of asking about solutions to complex problems. For example, on
his advice, I changed "If there was a Pulp 3 web-based interface, would you
use it?" from the 2019 survey to "Do you need a Pulp 3 web UI for your
environment?" with the follow-up question to describe that workflow if they
answer yes. He said to focus the questions on their experiences and their
problems rather than having them propose hypothetical solutions.

Feel free to reply here or enter "That is a terrible question, Melanie"
into the survey :)
Am happy to apply any feedback.

[0]
https://forms.gle/aynaM4d4wX5Aterz5





-- 

Melanie Corr, RHCE

Community Manager

Red Hat 

Remote, Ireland

mc...@redhat.com
M: +353857774436 IM: mcorr

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

Re: [Pulp-dev] Name uniqueness problem in Pulp 3 REST API

[Matthias Dellweg]

Sounds good.

On Thu, Jul 23, 2020 at 2:57 PM Ina Panova  wrote:
>
> Matthias,
> I think the conclusion of this thread is that people are on board to *change* 
> (not drop) the uniqueness constraint for the repo to name and type.
> For the multi-user/tenancy we will see a follow up in a separate thread.
>
> We already have an issue filed around remote names [0].
> Shall we update it in a more generalized way so we add in addition to 'name' 
> also 'type' to the uniqueness constraint to all the master/detail models 
> where it makes sense?
>
> [0] https://pulp.plan.io/issues/5656.
> 
> 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, Jul 22, 2020 at 10:56 AM Matthias Dellweg  wrote:
>>
>> Sorry for my short interjection. I was in a hurry and needed to make
>> sure i won't need to "hold my peace once and for all".
>> I am still quite worried, when you say "to change the uniqueness
>> constraint for repositories", as it is not clear to me whether it
>> means to lift the constraint completely or to change the set of
>> db-fields that represent the natural key of the resource.
>> Let me try to elaborate what i mean by the "ansible use case":
>> Consider a playbook to create a repository, a remote and trigger a
>> sync. It might look roughly like:
>> ---
>> - file_repository:
>> name: my_namespace/my_repository
>> state: present
>> - file_remote:
>> name: my_namespace/my_remote
>> url: http://example.org
>> state: present
>> - file_sync:
>> repository: my_namespace/my_repository
>> remote: my_namespace/my_remote
>> ...
>> Note, that there are no uuids in the playbook, because you cannot know
>> them upfront. Also if you run the playbook a second time, referencing
>> the resources by their natural key (that is the name atm) allows the
>> playbook to be idempotent. There will not be a second repository
>> created. That said, i am ok with changing the "natural
>> key"/"uniquene_together" to ["name", "namespace", "type"], but do not
>> want to see it dropped.
>> Additionally to that, i think it makes for a bad user experience too,
>> if a user needs to remember uuids of repositories, because there is
>> nothing else to identify them.
>>   Matthias
>>
>> On Tue, Jul 21, 2020 at 11:08 PM Brian Bouterse  wrote:
>> >
>> > Grand and David and I met for a *long* conversation about all the issues 
>> > here. I'll try to summarize some of the highlights. Nothing was decided 
>> > that was clear.
>> >
>> > * Grant's language about multi-tenancy is helpful, that is at the heart of 
>> > my concern
>> > * I believe we need multi-tenancy for Pulp to be safe and achieve the 
>> > project's goals, I've added a multi-tenancy discussion to the pulpcon 
>> > agenda if we don't get to it sooner 
>> > https://hackmd.io/hIOjFsFiSkGJR7VqtAJ8eQ
>> > * Generally namespaces or some other form of multi-tenancy mechanisms 
>> > seems to be the solution
>> > * I agree it won't resolve situations where there are data conflicts 
>> > around URLs, e.g. with Distributions specifically
>> >
>> > So for this thread, if it's helpful to change the uniqueness constraint 
>> > for repositories that seemed fine by everyone I've talked to. I'm 
>> > interested in organizing an effort to make sure we don't introduce RBAC 
>> > that users dislike with 3.6 but that needs more comprehensive planning. If 
>> > anyone has a simple proposal on how to do that please let me know. I'll 
>> > likely draft a problem statement here soon and probably collab w/ @ggainey 
>> > on it.
>> >
>> > On Tue, Jul 21, 2020 at 12:38 PM Matthias Dellweg  
>> > wrote:
>> >>
>> >> The user story you are describing there is inevitably not satisfiable.
>> >> At the very least, not every user can randomly create distributions
>> >> with base paths colliding with existing distributions.
>> >> I believe the answer to that is namespaces, where users can create
>> >> entities in their namespaces that they can also see. BTW, the
>> >> namespace could be used to decide upon a certain group permission to
>> >> be added to new resources.
>> >> In the global namespace, only an administrator can create entities.
>> >> If you lift, the uniqueness of names in a certain content-type, you
>> >> are definitely breaking the ansible usecase.
>> >>
>> >> On Tue, Jul 21, 2020 at 5:56 PM Grant Gainey  wrote:
>> >> >
>> >> > On Tue, Jul 21, 2020 at 11:38 AM Dennis Kliban  
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse  
>> >> >> wrote:
>> >> >>>
>> >> >>> I'm concerned if we don't make a change, here's the user experience 
>> >> >>> I'm worried about.
>> >> >>>
>> >> >>> 1. User A creates repo 'rhel7'
>> >> >>> 2. user B can't see repo 'rhel7' because of queryset scoping
>> >> >>> 3. user B goes to create 'rhel7'
>> >> >>> 4. user B is told 'rhel7' already exists
>> >> >>>
>> >> >>> Users should be able 

Re: [Pulp-dev] Name uniqueness problem in Pulp 3 REST API

[Ina Panova]

Matthias,
I think the conclusion of this thread is that people are on board to
*change* (not drop) the uniqueness constraint for the repo to name and type.
For the multi-user/tenancy we will see a follow up in a separate thread.

We already have an issue filed around remote names [0].
Shall we update it in a more generalized way so we add in addition to
'name' also 'type' to the uniqueness constraint to all the master/detail
models where it makes sense?

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

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, Jul 22, 2020 at 10:56 AM Matthias Dellweg 
wrote:

> Sorry for my short interjection. I was in a hurry and needed to make
> sure i won't need to "hold my peace once and for all".
> I am still quite worried, when you say "to change the uniqueness
> constraint for repositories", as it is not clear to me whether it
> means to lift the constraint completely or to change the set of
> db-fields that represent the natural key of the resource.
> Let me try to elaborate what i mean by the "ansible use case":
> Consider a playbook to create a repository, a remote and trigger a
> sync. It might look roughly like:
> ---
> - file_repository:
> name: my_namespace/my_repository
> state: present
> - file_remote:
> name: my_namespace/my_remote
> url: http://example.org
> state: present
> - file_sync:
> repository: my_namespace/my_repository
> remote: my_namespace/my_remote
> ...
> Note, that there are no uuids in the playbook, because you cannot know
> them upfront. Also if you run the playbook a second time, referencing
> the resources by their natural key (that is the name atm) allows the
> playbook to be idempotent. There will not be a second repository
> created. That said, i am ok with changing the "natural
> key"/"uniquene_together" to ["name", "namespace", "type"], but do not
> want to see it dropped.
> Additionally to that, i think it makes for a bad user experience too,
> if a user needs to remember uuids of repositories, because there is
> nothing else to identify them.
>   Matthias
>
> On Tue, Jul 21, 2020 at 11:08 PM Brian Bouterse 
> wrote:
> >
> > Grand and David and I met for a *long* conversation about all the issues
> here. I'll try to summarize some of the highlights. Nothing was decided
> that was clear.
> >
> > * Grant's language about multi-tenancy is helpful, that is at the heart
> of my concern
> > * I believe we need multi-tenancy for Pulp to be safe and achieve the
> project's goals, I've added a multi-tenancy discussion to the pulpcon
> agenda if we don't get to it sooner
> https://hackmd.io/hIOjFsFiSkGJR7VqtAJ8eQ
> > * Generally namespaces or some other form of multi-tenancy mechanisms
> seems to be the solution
> > * I agree it won't resolve situations where there are data conflicts
> around URLs, e.g. with Distributions specifically
> >
> > So for this thread, if it's helpful to change the uniqueness constraint
> for repositories that seemed fine by everyone I've talked to. I'm
> interested in organizing an effort to make sure we don't introduce RBAC
> that users dislike with 3.6 but that needs more comprehensive planning. If
> anyone has a simple proposal on how to do that please let me know. I'll
> likely draft a problem statement here soon and probably collab w/ @ggainey
> on it.
> >
> > On Tue, Jul 21, 2020 at 12:38 PM Matthias Dellweg 
> wrote:
> >>
> >> The user story you are describing there is inevitably not satisfiable.
> >> At the very least, not every user can randomly create distributions
> >> with base paths colliding with existing distributions.
> >> I believe the answer to that is namespaces, where users can create
> >> entities in their namespaces that they can also see. BTW, the
> >> namespace could be used to decide upon a certain group permission to
> >> be added to new resources.
> >> In the global namespace, only an administrator can create entities.
> >> If you lift, the uniqueness of names in a certain content-type, you
> >> are definitely breaking the ansible usecase.
> >>
> >> On Tue, Jul 21, 2020 at 5:56 PM Grant Gainey 
> wrote:
> >> >
> >> > On Tue, Jul 21, 2020 at 11:38 AM Dennis Kliban 
> wrote:
> >> >>
> >> >> On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse 
> wrote:
> >> >>>
> >> >>> I'm concerned if we don't make a change, here's the user experience
> I'm worried about.
> >> >>>
> >> >>> 1. User A creates repo 'rhel7'
> >> >>> 2. user B can't see repo 'rhel7' because of queryset scoping
> >> >>> 3. user B goes to create 'rhel7'
> >> >>> 4. user B is told 'rhel7' already exists
> >> >>>
> >> >>> Users should be able to use simple names. I don't know what the
> answer is to the import/export implementation conflict, but let's
> brainstorm some. For the benefit of our users, I don't think that
> implementation should interfere with this basic use.
> >> >>>
> >> >>
> >> >> I