Re: [Pulp-dev] Partially constructed data in the DB

[Brian Bouterse]

Defining the field's behaivor a bit more could help us with the name. Will
it actually be shown to the user in viewsets and filter results?

I think the answer should be no, not until it's fully finished. I can't
think of a reason why a user would want to see inconsistent content during
a sync or publish. There are some downsides when users thinking things are
done when they aren't. For instance, the user could mistakenly think the
publish is done when its not, trigger package updates, and many machines
will still receive the old content because it hasn't been switched over to
auto-publish for the expected distribution.

Also how is this related to when the 'created_resources' field is set on a
Task? I had imagined core would set that at as the last thing it does so
that when the user sees it everthing is "consistent" and "live" already.

-Brian

On Wed, Dec 13, 2017 at 2:42 PM, David Davis  wrote:

> Thanks for answering my questions. I agree on not using an “is_” prefix
> and avoiding “visible.”
>
> Your suggestion of “valid” sounds fine. Maybe some other options:
> finished, complete[d], ready.
>
>
> David
>
> On Wed, Dec 13, 2017 at 2:15 PM, Jeff Ortel  wrote:
>
>>
>>
>> On 12/13/2017 12:46 PM, David Davis wrote:
>>
>> A few questions. First, what is meant by incomplete? I’m assuming it
>> refers to a version in the process of being created or one that was not
>> successfully created?
>>
>>
>> Both.
>>
>>
>> Also, what’s the motivation behind storing this information? Is there
>> something in Pulp that needs to know this or is this so that the user can
>> know?
>>
>>
>> There may be others but an importer needs to be passed the new version so
>> it can add/remove content.  It needs to exist in the DB so that it can
>> add/remove content in separate transaction(s).
>>
>>
>> Lastly, I imagine that a task will be associated with the creation of a
>> version. Does knowing its state not suffice for determining if a version is
>> visible/valid?
>>
>>
>> IMHO, absolutely not.  That is not what tasks records in the DB are for.
>> Completed task records can be deleted at any time.
>>
>>
>>
>> David
>>
>> On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel  wrote:
>>
>>> There has been discussion on IRC about a matter related to versioned
>>> repositories that needs to be broadened.  It dealt with situations whereby
>>> a new repository version exists in the DB in an incomplete state.  The
>>> incomplete state exists because conceptually a repository version includes
>>> both the version record itself and all of the DB records that associate
>>> content.  For several reasons, the entire version cannot be constructed in
>>> the DB in a single DB transaction.  The problem of *Incomplete State*
>>> is not unique to repository versions.  It applies to publications as well.
>>> I would like to discuss and decide on a standard approach to resolving this
>>> throughout the data model.
>>>
>>> The IRC discussion (as related to me) suggested we use a common approach
>>> of having a field in the DB that indicates this state.  This seems
>>> reasonable to me.  As noted, it's a common approach.  Thoughts?
>>>
>>> Assume we did use a field, let's discuss name.  It's my understanding
>>> that a field named *is_visible* or just *visible* was discussed.  I
>>> would argue two things.  1) the is_ prefix is redundant to the fact it's a
>>> boolean field and we have not used this convention anywhere else in the
>>> model.  2) Historically, the term *"visible"* has strong ties to user
>>> interfaces and is used to mask fields or records from being displayed to
>>> users.  I propose we use a more appropriate field name.  Perhaps
>>> *"valid"*.  Thoughts?
>>>
>>> ___
>>> 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] Partially constructed data in the DB

[David Davis]

Thanks for answering my questions. I agree on not using an “is_” prefix and
avoiding “visible.”

Your suggestion of “valid” sounds fine. Maybe some other options: finished,
complete[d], ready.


David

On Wed, Dec 13, 2017 at 2:15 PM, Jeff Ortel  wrote:

>
>
> On 12/13/2017 12:46 PM, David Davis wrote:
>
> A few questions. First, what is meant by incomplete? I’m assuming it
> refers to a version in the process of being created or one that was not
> successfully created?
>
>
> Both.
>
>
> Also, what’s the motivation behind storing this information? Is there
> something in Pulp that needs to know this or is this so that the user can
> know?
>
>
> There may be others but an importer needs to be passed the new version so
> it can add/remove content.  It needs to exist in the DB so that it can
> add/remove content in separate transaction(s).
>
>
> Lastly, I imagine that a task will be associated with the creation of a
> version. Does knowing its state not suffice for determining if a version is
> visible/valid?
>
>
> IMHO, absolutely not.  That is not what tasks records in the DB are for.
> Completed task records can be deleted at any time.
>
>
>
> David
>
> On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel  wrote:
>
>> There has been discussion on IRC about a matter related to versioned
>> repositories that needs to be broadened.  It dealt with situations whereby
>> a new repository version exists in the DB in an incomplete state.  The
>> incomplete state exists because conceptually a repository version includes
>> both the version record itself and all of the DB records that associate
>> content.  For several reasons, the entire version cannot be constructed in
>> the DB in a single DB transaction.  The problem of *Incomplete State* is
>> not unique to repository versions.  It applies to publications as well.  I
>> would like to discuss and decide on a standard approach to resolving this
>> throughout the data model.
>>
>> The IRC discussion (as related to me) suggested we use a common approach
>> of having a field in the DB that indicates this state.  This seems
>> reasonable to me.  As noted, it's a common approach.  Thoughts?
>>
>> Assume we did use a field, let's discuss name.  It's my understanding
>> that a field named *is_visible* or just *visible* was discussed.  I
>> would argue two things.  1) the is_ prefix is redundant to the fact it's a
>> boolean field and we have not used this convention anywhere else in the
>> model.  2) Historically, the term *"visible"* has strong ties to user
>> interfaces and is used to mask fields or records from being displayed to
>> users.  I propose we use a more appropriate field name.  Perhaps
>> *"valid"*.  Thoughts?
>>
>> ___
>> 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] Tasking System Improvement

[Dennis Kliban]

I read through the story and it looks good to me. I marked it as groomed.

On Fri, Dec 8, 2017 at 3:50 PM, Brian Bouterse  wrote:

> Recently @ttereshc brought up a tasking system improvement while
> investigating a user reported issue. I think it's something we want to get
> added to both Pulp3 and Pulp2. The story I wrote up is written as a Pulp3
> story [0]. What do others think about this tasking system change? Can
> others post questions or groom that story?
>
> After adding it into Pulp3 I think we can have a separate issue (not yet
> created) to track to backporting of a similar change to the pulp2 API.
>
> [0]: https://pulp.plan.io/issues/3176
>
> -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

Re: [Pulp-dev] Partially constructed data in the DB

[Jeff Ortel]

On 12/13/2017 12:46 PM, David Davis wrote:
A few questions. First, what is meant by incomplete? I’m assuming it 
refers to a version in the process of being created or one that was 
not successfully created?


Both.



Also, what’s the motivation behind storing this information? Is there 
something in Pulp that needs to know this or is this so that the user 
can know?


There may be others but an importer needs to be passed the new version 
so it can add/remove content.  It needs to exist in the DB so that it 
can add/remove content in separate transaction(s).




Lastly, I imagine that a task will be associated with the creation of 
a version. Does knowing its state not suffice for determining if a 
version is visible/valid?


IMHO, absolutely not.  That is not what tasks records in the DB are 
for.  Completed task records can be deleted at any time.





David

On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel > wrote:


There has been discussion on IRC about a matter related to
versioned repositories that needs to be broadened. It dealt with
situations whereby a new repository version exists in the DB in an
incomplete state.  The incomplete state exists because
conceptually a repository version includes both the version record
itself and all of the DB records that associate content.  For
several reasons, the entire version cannot be constructed in the
DB in a single DB transaction. The problem of /Incomplete State/
is not unique to repository versions.  It applies to publications
as well.  I would like to discuss and decide on a standard
approach to resolving this throughout the data model.

The IRC discussion (as related to me) suggested we use a common
approach of having a field in the DB that indicates this state. 
This seems reasonable to me.  As noted, it's a common approach. 
Thoughts?

Assume we did use a field, let's discuss name.  It's my
understanding that a field named /is_visible/ or just /visible/
was discussed.  I would argue two things.  1) the is_ prefix is
redundant to the fact it's a boolean field and we have not used
this convention anywhere else in the model.  2) Historically, the
term /"visible"/ has strong ties to user interfaces and is used to
mask fields or records from being displayed to users.  I propose
we use a more appropriate field name.  Perhaps /"valid"/. Thoughts?


___
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] Partially constructed data in the DB

[David Davis]

A few questions. First, what is meant by incomplete? I’m assuming it refers
to a version in the process of being created or one that was not
successfully created?

Also, what’s the motivation behind storing this information? Is there
something in Pulp that needs to know this or is this so that the user can
know?

Lastly, I imagine that a task will be associated with the creation of a
version. Does knowing its state not suffice for determining if a version is
visible/valid?


David

On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel  wrote:

> There has been discussion on IRC about a matter related to versioned
> repositories that needs to be broadened.  It dealt with situations whereby
> a new repository version exists in the DB in an incomplete state.  The
> incomplete state exists because conceptually a repository version includes
> both the version record itself and all of the DB records that associate
> content.  For several reasons, the entire version cannot be constructed in
> the DB in a single DB transaction.  The problem of *Incomplete State* is
> not unique to repository versions.  It applies to publications as well.  I
> would like to discuss and decide on a standard approach to resolving this
> throughout the data model.
>
> The IRC discussion (as related to me) suggested we use a common approach
> of having a field in the DB that indicates this state.  This seems
> reasonable to me.  As noted, it's a common approach.  Thoughts?
>
> Assume we did use a field, let's discuss name.  It's my understanding that
> a field named *is_visible* or just *visible* was discussed.  I would
> argue two things.  1) the is_ prefix is redundant to the fact it's a
> boolean field and we have not used this convention anywhere else in the
> model.  2) Historically, the term *"visible"* has strong ties to user
> interfaces and is used to mask fields or records from being displayed to
> users.  I propose we use a more appropriate field name.  Perhaps *"valid"*.
> Thoughts?
>
> ___
> 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] Partially constructed data in the DB

[Jeff Ortel]

There has been discussion on IRC about a matter related to versioned 
repositories that needs to be broadened.  It dealt with situations 
whereby a new repository version exists in the DB in an incomplete 
state.  The incomplete state exists because conceptually a repository 
version includes both the version record itself and all of the DB 
records that associate content.  For several reasons, the entire version 
cannot be constructed in the DB in a single DB transaction.  The problem 
of /Incomplete State/ is not unique to repository versions.  It applies 
to publications as well.  I would like to discuss and decide on a 
standard approach to resolving this throughout the data model.


The IRC discussion (as related to me) suggested we use a common approach 
of having a field in the DB that indicates this state. This seems 
reasonable to me.  As noted, it's a common approach. Thoughts?


Assume we did use a field, let's discuss name.  It's my understanding 
that a field named /is_visible/ or just /visible/ was discussed.  I 
would argue two things.  1) the is_ prefix is redundant to the fact it's 
a boolean field and we have not used this convention anywhere else in 
the model.  2) Historically, the term /"visible"/ has strong ties to 
user interfaces and is used to mask fields or records from being 
displayed to users.  I propose we use a more appropriate field name.  
Perhaps /"valid"/. Thoughts?


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

Re: [Pulp-dev] Pulp 3: using JWT to request a JWT

[David Davis]

+1


David

On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse 
wrote:

> +1 to this
>
>
> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley  wrote:
>
>>  - close issues 3163 and 3164
>>>  - move JWT auth use cases from the MVP document[2] to the 3.1+
>>> document[3].
>>>  - add a story for removing "djangorestframework-jwt" from pulp 3.0
>>
>>
>> s/story/task, and
>>
>> - remove the JWT auth documentation from the 3.0 docs
>>
>> +1
>>
>> On Tue, Dec 12, 2017 at 5:01 PM, Dennis Kliban 
>> wrote:
>>
>>> tl;dr We should support only basic auth for 3.0 and implement JWT
>>> authentication in 3.1+
>>>
>>> We currently have 2 stories[0-1] related to JWT authentication that we
>>> wanted to implement for 3.0. As @bmbouter, @daviddavis, and I tried to
>>> groom them earlier today, we decided that we are not ready to commit to
>>> using "djangorestframework-jwt" app for handling JWT authentication.
>>> This app has some behaviors that we want to override and also comes with
>>> several configuration options that we don't want to support long term. I am
>>> proposing that we remove JWT authentication from the MVP and move it to the
>>> 3.1+ list. I'd like to
>>>
>>>  - close issues 3163 and 3164
>>>  - move JWT auth use cases from the MVP document[2] to the 3.1+
>>> document[3].
>>>  - add a story for removing "djangorestframework-jwt" from pulp 3.0
>>>
>>> [0] https://pulp.plan.io/issues/3163
>>> [1] https://pulp.plan.io/issues/3164
>>> [2] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>> e_Product/#Authentication
>>> [3] https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>>>
>>>
>>> On Fri, Dec 1, 2017 at 3:48 PM, Brian Bouterse 
>>> wrote:
>>>
 +1 to just those use cases. Since we can rollback the change I updated
 the MVP with this change:  https://pulp.plan.io/projects/
 pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93&
 version=125&version_from=124&commit=View+differences

 I also added an explicit use case saying that basic auth can
 authenticate to all urls. I think that got lost in the language revisions.
 It's also in the diff ^.

 Anyone feel free to suggest other changes or edit and send links with
 the diff.

 On Fri, Dec 1, 2017 at 2:47 PM, David Davis 
 wrote:

> I would just do:
>
> As a JWT authenticated user, I can refresh my JWT token if Pulp is
> configured with JWT_ALLOW_REFRESH set to True (default is False).
>
> Having two user stories means two separate items in redmine, and both
> of these user stories will probably be fixed in one commit/PR.
>
>
> David
>
> On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse 
> wrote:
>
>> +1 to using JWT_ALLOW_REFRESH as the name, I read the other name from
>> some other docs. +1 to adding a refresh token endpoint and some docs.
>>
>> We need to update this area in the MVP which is currently in red. We
>> could replace the use case in red with:  "As an API user, I can
>> authenticate any API call with a JWT" and then add the following two use
>> cases:
>>
>> As a JWT authenticated user, I can receive a new JWT if Pulp is
>> configured with JWT_ALLOW_REFRESH=True
>> As a Pulp administrator, my Pulp system disallows JWT renewal by
>> default (JWT_ALLOW_REFRESH=False)
>>
>> What about these use case changes to the MVP to reflect this convo?
>>
>> On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet 
>> wrote:
>>
>>> I think @misa's point is that if a valid token becomes compromised,
 it could be renewed for a long-maybe-forever time.

 I'm reading a desire to have Pulp exhibit both of these types of
 behaviors, and both for good reasons. What if we introduce a setting
 JWT_REFRESH. If enabled, JWT_REFRESH will allow you to receive a new 
 JWT
 when authenticating with an existing JWT. Defaults to False.

 I'm picking False as the default on the idea that not renewing
 tokens would be a more secure system by limiting access in more case 
 than
 when JWT_REFRESH is True. In the implementation, when JWT_REFRESH is 
 set to
 True it would fully disable the JWT_REFRESH_EXPIRATION_DELTA setting so
 that it could be refreshed indefinitly. The user would never know about
 JWT_REFRESH_EXPIRATION_DELTA.
>>>
>>>
>>> Being secure-by-default, with the option to do useful-but-dangerous
>>> things, is a great design approach.
>>>
>>
>>
>

 ___
 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] Voting for PUP 4: Code of Conduct

[Brian Bouterse]

+1

On Wed, Dec 13, 2017 at 11:24 AM, Ina Panova  wrote:

> +1
>
>
>
> 
> Regards,
>
> Ina Panova
> 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 Tue, Dec 12, 2017 at 8:32 PM, Austin Macdonald 
> wrote:
>
>> +1
>>
>> On Tue, Dec 12, 2017 at 2:01 PM, Bihan Zhang  wrote:
>>
>>> +1
>>>
>>> On Tue, Dec 12, 2017 at 1:45 PM, David Davis 
>>> wrote:
>>>
 +1


 David

 On Tue, Dec 12, 2017 at 1:39 PM, Daniel Alley 
 wrote:

> +1
>
> On Tue, Dec 12, 2017 at 12:25 PM, Dennis Kliban 
> wrote:
>
>> We had some discussion about this PUP in a separate thread[0]. We
>> have now reached consensus on the wording of the PUP to open it up to
>> voting.
>>
>> To refresh everyone’s memory, voting is outlined in PUP-1:
>>
>> https://github.com/pulp/pups/blob/master/pup-0001.md#voting
>>
>> And here’s the PUP in question:
>>
>> https://github.com/dkliban/pups/blob/pup4/pup-0004.md
>>
>> Please respond to this thread with your vote or any
>> comments/questions.
>>
>>
>>
>>
>> [0] https://www.redhat.com/archives/pulp-dev/2017-November/msg00
>> 110.html
>>
>> ___
>> 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
>>>
>>>
>>
>> ___
>> 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] Pulp 3: using JWT to request a JWT

[Brian Bouterse]

+1 to this

On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley  wrote:

>  - close issues 3163 and 3164
>>  - move JWT auth use cases from the MVP document[2] to the 3.1+
>> document[3].
>>  - add a story for removing "djangorestframework-jwt" from pulp 3.0
>
>
> s/story/task, and
>
> - remove the JWT auth documentation from the 3.0 docs
>
> +1
>
> On Tue, Dec 12, 2017 at 5:01 PM, Dennis Kliban  wrote:
>
>> tl;dr We should support only basic auth for 3.0 and implement JWT
>> authentication in 3.1+
>>
>> We currently have 2 stories[0-1] related to JWT authentication that we
>> wanted to implement for 3.0. As @bmbouter, @daviddavis, and I tried to
>> groom them earlier today, we decided that we are not ready to commit to
>> using "djangorestframework-jwt" app for handling JWT authentication.
>> This app has some behaviors that we want to override and also comes with
>> several configuration options that we don't want to support long term. I am
>> proposing that we remove JWT authentication from the MVP and move it to the
>> 3.1+ list. I'd like to
>>
>>  - close issues 3163 and 3164
>>  - move JWT auth use cases from the MVP document[2] to the 3.1+
>> document[3].
>>  - add a story for removing "djangorestframework-jwt" from pulp 3.0
>>
>> [0] https://pulp.plan.io/issues/3163
>> [1] https://pulp.plan.io/issues/3164
>> [2] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>> e_Product/#Authentication
>> [3] https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>>
>>
>> On Fri, Dec 1, 2017 at 3:48 PM, Brian Bouterse 
>> wrote:
>>
>>> +1 to just those use cases. Since we can rollback the change I updated
>>> the MVP with this change:  https://pulp.plan.io/projects/
>>> pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93&
>>> version=125&version_from=124&commit=View+differences
>>>
>>> I also added an explicit use case saying that basic auth can
>>> authenticate to all urls. I think that got lost in the language revisions.
>>> It's also in the diff ^.
>>>
>>> Anyone feel free to suggest other changes or edit and send links with
>>> the diff.
>>>
>>> On Fri, Dec 1, 2017 at 2:47 PM, David Davis 
>>> wrote:
>>>
 I would just do:

 As a JWT authenticated user, I can refresh my JWT token if Pulp is
 configured with JWT_ALLOW_REFRESH set to True (default is False).

 Having two user stories means two separate items in redmine, and both
 of these user stories will probably be fixed in one commit/PR.


 David

 On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse 
 wrote:

> +1 to using JWT_ALLOW_REFRESH as the name, I read the other name from
> some other docs. +1 to adding a refresh token endpoint and some docs.
>
> We need to update this area in the MVP which is currently in red. We
> could replace the use case in red with:  "As an API user, I can
> authenticate any API call with a JWT" and then add the following two use
> cases:
>
> As a JWT authenticated user, I can receive a new JWT if Pulp is
> configured with JWT_ALLOW_REFRESH=True
> As a Pulp administrator, my Pulp system disallows JWT renewal by
> default (JWT_ALLOW_REFRESH=False)
>
> What about these use case changes to the MVP to reflect this convo?
>
> On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet 
> wrote:
>
>> I think @misa's point is that if a valid token becomes compromised,
>>> it could be renewed for a long-maybe-forever time.
>>>
>>> I'm reading a desire to have Pulp exhibit both of these types of
>>> behaviors, and both for good reasons. What if we introduce a setting
>>> JWT_REFRESH. If enabled, JWT_REFRESH will allow you to receive a new JWT
>>> when authenticating with an existing JWT. Defaults to False.
>>>
>>> I'm picking False as the default on the idea that not renewing
>>> tokens would be a more secure system by limiting access in more case 
>>> than
>>> when JWT_REFRESH is True. In the implementation, when JWT_REFRESH is 
>>> set to
>>> True it would fully disable the JWT_REFRESH_EXPIRATION_DELTA setting so
>>> that it could be refreshed indefinitly. The user would never know about
>>> JWT_REFRESH_EXPIRATION_DELTA.
>>
>>
>> Being secure-by-default, with the option to do useful-but-dangerous
>> things, is a great design approach.
>>
>
>

>>>
>>> ___
>>> 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] Crane redirects - internal and external content

[Mihai Ibanescu]

Hi,

In our current setup, we have a purely internal pulp deployment, that
publishes to an NFS share.

HTTP frontend machines handle the cert-based authn/authz and serve the
content from the NFS share.

We have an internal set of HTTP frontend machines, and an internal customer
has access to published content for all development stages (dev/test/prod).

We also have an external set of HTTP frontend machines, that handle
external customer requests, and only serve the prod stage. Content from the
internal NFS share is selectively rsynced into the external disk share.

This all works great for rpm and such.

I believe there is a problem with docker. We would have one internal and
one external crane deployment, as expected. Content would be rsynced, as
usual. However, because the redirect URL is "baked" into the redirect json
files, the external Crane would redirect to the internal system, which is
not helpful.

We would prefer not to republish / recreate the redirect files in our
transition from internal to external content.

One way to handle this would be a Crane configuration option that directs
crane to rewrite the redirect URL. In that case, internal and external
crane systems would be configured differently.

The questions:
* Is there such an option in Crane? (looking at the code, I believe the
answer is no)
* Is there a feature request for something like this already?
* If not, do you agree what I've described above is a valid customer use
case, and should I file it as a feature request?

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

Re: [Pulp-dev] Voting for PUP 4: Code of Conduct

[Ina Panova]

+1




Regards,

Ina Panova
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 Tue, Dec 12, 2017 at 8:32 PM, Austin Macdonald 
wrote:

> +1
>
> On Tue, Dec 12, 2017 at 2:01 PM, Bihan Zhang  wrote:
>
>> +1
>>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Davis 
>> wrote:
>>
>>> +1
>>>
>>>
>>> David
>>>
>>> On Tue, Dec 12, 2017 at 1:39 PM, Daniel Alley  wrote:
>>>
 +1

 On Tue, Dec 12, 2017 at 12:25 PM, Dennis Kliban 
 wrote:

> We had some discussion about this PUP in a separate thread[0]. We have
> now reached consensus on the wording of the PUP to open it up to voting.
>
> To refresh everyone’s memory, voting is outlined in PUP-1:
>
> https://github.com/pulp/pups/blob/master/pup-0001.md#voting
>
> And here’s the PUP in question:
>
> https://github.com/dkliban/pups/blob/pup4/pup-0004.md
>
> Please respond to this thread with your vote or any
> comments/questions.
>
>
>
>
> [0] https://www.redhat.com/archives/pulp-dev/2017-November/msg00
> 110.html
>
> ___
> 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
>>
>>
>
> ___
> 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] Deferring 3 things for Pulp3 to 3.1+

[Dennis Kliban]

+1

On Wed, Dec 13, 2017 at 10:04 AM, Austin Macdonald 
wrote:

> +1
>
> On Wed, Dec 13, 2017 at 10:02 AM, Bihan Zhang  wrote:
>
>> +1
>>
>> On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel  wrote:
>>
>>> +1
>>>
>>> On 12/12/2017 10:47 AM, Brian Bouterse wrote:
>>>
>>> As we get to the end of the MVP planning for Pulp3, I want to check-in
>>> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
>>> looking for feedback, especially -1s, about deferring the following 3
>>> things from the Pulp 3.0 release. This would finalize a few still-red or
>>> totally missing areas of the MVP [1].
>>>
>>> - Consumer Applicability. Pulp3 won't manage consumers, but Pulp is
>>> still in a good position to offer applicability. Katello uses it
>>> significantly, but they won't be using the 3.0 release.
>>>
>>> - Lazy downloading. I think this should be a top 3.1 priority. It will
>>> take a significant effort to update/test/release the streamer so I don't
>>> think we can include it in 3.0 for practical timeline reasons.
>>>
>>> - Content Protection. I believe we want both basic auth and key based
>>> verification of content served by the Pulp content app. This is an easy
>>> feature to add, but not one I think we should plan fully or do as part of
>>> the 3.0 MVP.
>>>
>>> Please send thoughts or ideas on these changes soon, so we can finalize
>>> the MVP document in the next few days.
>>>
>>> [0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>>> 
>>> [1]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>> e_Product/
>>>
>>> Thank you,
>>> Brian
>>>
>>>
>>> ___
>>> Pulp-dev mailing 
>>> listPulp-dev@redhat.comhttps://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
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Deferring 3 things for Pulp3 to 3.1+

[Austin Macdonald]

+1

On Wed, Dec 13, 2017 at 10:02 AM, Bihan Zhang  wrote:

> +1
>
> On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel  wrote:
>
>> +1
>>
>> On 12/12/2017 10:47 AM, Brian Bouterse wrote:
>>
>> As we get to the end of the MVP planning for Pulp3, I want to check-in
>> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
>> looking for feedback, especially -1s, about deferring the following 3
>> things from the Pulp 3.0 release. This would finalize a few still-red or
>> totally missing areas of the MVP [1].
>>
>> - Consumer Applicability. Pulp3 won't manage consumers, but Pulp is still
>> in a good position to offer applicability. Katello uses it significantly,
>> but they won't be using the 3.0 release.
>>
>> - Lazy downloading. I think this should be a top 3.1 priority. It will
>> take a significant effort to update/test/release the streamer so I don't
>> think we can include it in 3.0 for practical timeline reasons.
>>
>> - Content Protection. I believe we want both basic auth and key based
>> verification of content served by the Pulp content app. This is an easy
>> feature to add, but not one I think we should plan fully or do as part of
>> the 3.0 MVP.
>>
>> Please send thoughts or ideas on these changes soon, so we can finalize
>> the MVP document in the next few days.
>>
>> [0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>> 
>> [1]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>> e_Product/
>>
>> Thank you,
>> Brian
>>
>>
>> ___
>> Pulp-dev mailing 
>> listPulp-dev@redhat.comhttps://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] Pulp 3: using JWT to request a JWT

[Daniel Alley]

>
>  - close issues 3163 and 3164
>  - move JWT auth use cases from the MVP document[2] to the 3.1+
> document[3].
>  - add a story for removing "djangorestframework-jwt" from pulp 3.0


s/story/task, and

- remove the JWT auth documentation from the 3.0 docs

+1

On Tue, Dec 12, 2017 at 5:01 PM, Dennis Kliban  wrote:

> tl;dr We should support only basic auth for 3.0 and implement JWT
> authentication in 3.1+
>
> We currently have 2 stories[0-1] related to JWT authentication that we
> wanted to implement for 3.0. As @bmbouter, @daviddavis, and I tried to
> groom them earlier today, we decided that we are not ready to commit to
> using "djangorestframework-jwt" app for handling JWT authentication. This
> app has some behaviors that we want to override and also comes with several
> configuration options that we don't want to support long term. I am
> proposing that we remove JWT authentication from the MVP and move it to the
> 3.1+ list. I'd like to
>
>  - close issues 3163 and 3164
>  - move JWT auth use cases from the MVP document[2] to the 3.1+
> document[3].
>  - add a story for removing "djangorestframework-jwt" from pulp 3.0
>
> [0] https://pulp.plan.io/issues/3163
> [1] https://pulp.plan.io/issues/3164
> [2] https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_
> Viable_Product/#Authentication
> [3] https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>
>
> On Fri, Dec 1, 2017 at 3:48 PM, Brian Bouterse 
> wrote:
>
>> +1 to just those use cases. Since we can rollback the change I updated
>> the MVP with this change:  https://pulp.plan.io/projects/
>> pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93&
>> version=125&version_from=124&commit=View+differences
>>
>> I also added an explicit use case saying that basic auth can authenticate
>> to all urls. I think that got lost in the language revisions. It's also in
>> the diff ^.
>>
>> Anyone feel free to suggest other changes or edit and send links with the
>> diff.
>>
>> On Fri, Dec 1, 2017 at 2:47 PM, David Davis 
>> wrote:
>>
>>> I would just do:
>>>
>>> As a JWT authenticated user, I can refresh my JWT token if Pulp is
>>> configured with JWT_ALLOW_REFRESH set to True (default is False).
>>>
>>> Having two user stories means two separate items in redmine, and both of
>>> these user stories will probably be fixed in one commit/PR.
>>>
>>>
>>> David
>>>
>>> On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse 
>>> wrote:
>>>
 +1 to using JWT_ALLOW_REFRESH as the name, I read the other name from
 some other docs. +1 to adding a refresh token endpoint and some docs.

 We need to update this area in the MVP which is currently in red. We
 could replace the use case in red with:  "As an API user, I can
 authenticate any API call with a JWT" and then add the following two use
 cases:

 As a JWT authenticated user, I can receive a new JWT if Pulp is
 configured with JWT_ALLOW_REFRESH=True
 As a Pulp administrator, my Pulp system disallows JWT renewal by
 default (JWT_ALLOW_REFRESH=False)

 What about these use case changes to the MVP to reflect this convo?

 On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet 
 wrote:

> I think @misa's point is that if a valid token becomes compromised, it
>> could be renewed for a long-maybe-forever time.
>>
>> I'm reading a desire to have Pulp exhibit both of these types of
>> behaviors, and both for good reasons. What if we introduce a setting
>> JWT_REFRESH. If enabled, JWT_REFRESH will allow you to receive a new JWT
>> when authenticating with an existing JWT. Defaults to False.
>>
>> I'm picking False as the default on the idea that not renewing tokens
>> would be a more secure system by limiting access in more case than when
>> JWT_REFRESH is True. In the implementation, when JWT_REFRESH is set to 
>> True
>> it would fully disable the JWT_REFRESH_EXPIRATION_DELTA setting so that 
>> it
>> could be refreshed indefinitly. The user would never know about
>> JWT_REFRESH_EXPIRATION_DELTA.
>
>
> Being secure-by-default, with the option to do useful-but-dangerous
> things, is a great design approach.
>


>>>
>>
>> ___
>> 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] Deferring 3 things for Pulp3 to 3.1+

[Bihan Zhang]

+1

On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel  wrote:

> +1
>
> On 12/12/2017 10:47 AM, Brian Bouterse wrote:
>
> As we get to the end of the MVP planning for Pulp3, I want to check-in
> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
> looking for feedback, especially -1s, about deferring the following 3
> things from the Pulp 3.0 release. This would finalize a few still-red or
> totally missing areas of the MVP [1].
>
> - Consumer Applicability. Pulp3 won't manage consumers, but Pulp is still
> in a good position to offer applicability. Katello uses it significantly,
> but they won't be using the 3.0 release.
>
> - Lazy downloading. I think this should be a top 3.1 priority. It will
> take a significant effort to update/test/release the streamer so I don't
> think we can include it in 3.0 for practical timeline reasons.
>
> - Content Protection. I believe we want both basic auth and key based
> verification of content served by the Pulp content app. This is an easy
> feature to add, but not one I think we should plan fully or do as part of
> the 3.0 MVP.
>
> Please send thoughts or ideas on these changes soon, so we can finalize
> the MVP document in the next few days.
>
> [0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
> 
> [1]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_
> Viable_Product/
>
> Thank you,
> Brian
>
>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://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] Deferring 3 things for Pulp3 to 3.1+

[Jeff Ortel]

+1


On 12/12/2017 10:47 AM, Brian Bouterse wrote:
As we get to the end of the MVP planning for Pulp3, I want to check-in 
about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. 
I'm looking for feedback, especially -1s, about deferring the 
following 3 things from the Pulp 3.0 release. This would finalize a 
few still-red or totally missing areas of the MVP [1].


- Consumer Applicability. Pulp3 won't manage consumers, but Pulp is 
still in a good position to offer applicability. Katello uses it 
significantly, but they won't be using the 3.0 release.


- Lazy downloading. I think this should be a top 3.1 priority. It will 
take a significant effort to update/test/release the streamer so I 
don't think we can include it in 3.0 for practical timeline reasons.


- Content Protection. I believe we want both basic auth and key based 
verification of content served by the Pulp content app. This is an 
easy feature to add, but not one I think we should plan fully or do as 
part of the 3.0 MVP.


Please send thoughts or ideas on these changes soon, so we can 
finalize the MVP document in the next few days.


[0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP) 

[1]: 
https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product/


Thank you,
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

Re: [Pulp-dev] Deferring 3 things for Pulp3 to 3.1+

[Daniel Alley]

+1 here too

On Wed, Dec 13, 2017 at 8:28 AM, David Davis  wrote:

> I think this makes sense. +1 from me.
>
>
> David
>
> On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse 
> wrote:
>
>> As we get to the end of the MVP planning for Pulp3, I want to check-in
>> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
>> looking for feedback, especially -1s, about deferring the following 3
>> things from the Pulp 3.0 release. This would finalize a few still-red or
>> totally missing areas of the MVP [1].
>>
>> - Consumer Applicability. Pulp3 won't manage consumers, but Pulp is still
>> in a good position to offer applicability. Katello uses it significantly,
>> but they won't be using the 3.0 release.
>>
>> - Lazy downloading. I think this should be a top 3.1 priority. It will
>> take a significant effort to update/test/release the streamer so I don't
>> think we can include it in 3.0 for practical timeline reasons.
>>
>> - Content Protection. I believe we want both basic auth and key based
>> verification of content served by the Pulp content app. This is an easy
>> feature to add, but not one I think we should plan fully or do as part of
>> the 3.0 MVP.
>>
>> Please send thoughts or ideas on these changes soon, so we can finalize
>> the MVP document in the next few days.
>>
>> [0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>> [1]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>> e_Product/
>>
>> Thank you,
>> 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://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Deferring 3 things for Pulp3 to 3.1+

[David Davis]

I think this makes sense. +1 from me.


David

On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse 
wrote:

> As we get to the end of the MVP planning for Pulp3, I want to check-in
> about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm
> looking for feedback, especially -1s, about deferring the following 3
> things from the Pulp 3.0 release. This would finalize a few still-red or
> totally missing areas of the MVP [1].
>
> - Consumer Applicability. Pulp3 won't manage consumers, but Pulp is still
> in a good position to offer applicability. Katello uses it significantly,
> but they won't be using the 3.0 release.
>
> - Lazy downloading. I think this should be a top 3.1 priority. It will
> take a significant effort to update/test/release the streamer so I don't
> think we can include it in 3.0 for practical timeline reasons.
>
> - Content Protection. I believe we want both basic auth and key based
> verification of content served by the Pulp content app. This is an easy
> feature to add, but not one I think we should plan fully or do as part of
> the 3.0 MVP.
>
> Please send thoughts or ideas on these changes soon, so we can finalize
> the MVP document in the next few days.
>
> [0]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
> [1]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_
> Viable_Product/
>
> Thank you,
> 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