Austin reported to me that this msg didn' show up in his inbox. I didn't
get it either.
https://www.redhat.com/archives/pulp-dev/2018-April/msg00136.html

I've opened up a ticket, so until then, we may need to check the archives.
https://www.redhat.com/archives/pulp-dev/index.html

On Thu, Apr 12, 2018 at 5:49 PM, Dennis Kliban <dkli...@redhat.com> wrote:

> On Thu, Apr 12, 2018 at 2:49 PM, Jeff Ortel <jor...@redhat.com> wrote:
>
>>
>>
>> On 04/11/2018 01:13 PM, Dennis Kliban wrote:
>>
>> On Tue, Apr 10, 2018 at 6:44 PM, Jeff Ortel <jor...@redhat.com> wrote:
>>
>>>
>>>
>>> On 04/10/2018 04:15 PM, Dennis Kliban wrote:
>>>
>>> On Tue, Apr 10, 2018 at 2:04 PM, Brian Bouterse <bbout...@redhat.com>
>>> wrote:
>>>
>>>> These are good problem statements. I didn't understand all of the
>>>> aspects of it, so I put some inline questions.
>>>>
>>>> My overall question is: are these related problems? To share my answer
>>>> to this, I believe the first two problems are related and the third is
>>>> separate. The classic divide and conquor approach we could use here is to
>>>> confirm that the problems are unrelated and focus on resolving one of them
>>>> first.
>>>>
>>>>
>>> I don't think all 3 are related problems. The motivation for grouping
>>> all together is that a subset of the action endpoints from problem 1 are
>>> used to create repository versions and Problem 3 is a problem with the
>>> repository version creation API.
>>>
>>>
>>>>
>>>> On Mon, Apr 9, 2018 at 3:18 PM, Austin Macdonald <aus...@redhat.com>
>>>> wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> Austin, Dennis, and Milan have identified the following issues with
>>>>> current Pulp3 REST API design:
>>>>>
>>>>>    - Action endpoints are problematic.
>>>>>    - Example POST@/importers/<plugin>/sync/
>>>>>       - They are non-RESTful and would make client code tightly
>>>>>       coupled with the server code.
>>>>>       - These endpoints are inconsistent with the other parts of the
>>>>>       REST API.
>>>>>
>>>>> Is self-consistency really a goal? I think it's a placeholder for
>>>> consistency for REST since the "rest" of the API is RESTful. After reading
>>>> parts of Roy Fielding's writeup of the definition of REST I believe "action
>>>> endpoints are not RESTful" to be a true statement. Maybe "Action endpoints
>>>> are problematic" should be replaced with "Action endpoints are not RESTful"
>>>> perhaps and have the self-consistency bullet removed?
>>>>
>>>
>>> +1 to "Action endpoints are not RESTful"
>>> +1 to removing the self-consistency language
>>>
>>>
>>>>
>>>>>    - DRF is not being used as intended for action endpoints so we
>>>>>       have to implement extra code. (against the grain)
>>>>>
>>>>> I don't know much about this. Where is the extra code?
>>>>
>>>>
>>>>>
>>>>>    - We don't have a convention for where plug-in-specific, custom
>>>>>    repository version creation endpoints.
>>>>>    - example POST@/api/v3/<where?>/docker/add/
>>>>>       - needs to be discoverable through the schema
>>>>>
>>>>> What does discoverable via the schema ^ mean? Aren't all urls listed
>>>> in the schema?
>>>>
>>>> I think of ^ problem somewhat differently. Yes all urls need to be
>>>> discoverable (a REST property), but isn't it more of an issue that the urls
>>>> which produce repo versions can't be identified distinctly from any other
>>>> plugin-contributed url? To paraphrase this perspective: making a repo
>>>> version is strewn about throughout the API in random places which is a bad
>>>> user experience. Is that what is motivation url discovery?
>>>>
>>>>
>>>
>>> Yes. I envision a CLI that can discover new plugin
>>> repository-version-creating functionality without having to install new
>>> client packages. Allowing plugin writers to add endpoints in arbitrary
>>> places for creating repository versions will make it impossible for the
>>> client to know what all the possible ways of creating a repository version
>>> are.
>>>
>>>
>>>>
>>>>>    - For direct repository version creation, plugins are not involved.
>>>>>    - validation correctness problem: https://pulp.plan.io/issues/3541
>>>>>       - example: POST@/api/v3/repositories/<repository_id>/versions/
>>>>>
>>>>> I agree with this problem statement. In terms of scope it affects some
>>>> plugin writers but not all.
>>>>
>>>
>>> I think it affects all plugin writers. Even the File plugin needs to
>>> provide some validation when creating a repository version. Right now you
>>> can add a FileContent with the same relative path as another FileContent in
>>> the repository version. This should not be possible because it's not a
>>> valid combination of FileContent units in the same repository version.
>>>
>>>
>>> Not necessarily.  Two files with the same relative path will have
>>> different digest (different content).  The assumption that they both cannot
>>> be in the same repository makes assumptions about how the repository is
>>> used which I don't think is a good idea.  Image two different versions of
>>> abc.iso.
>>>
>>>
>> Why is it bad to assume that a repository version is going to be
>> published? What are the other ways to use a repository version?
>>
>>
>> The repository may not be publish and/or may not be published by the
>> FilePublisher in the file plugin project.  A user may want to sync and
>> store many version of an iso in the repository and then selectively *add*
>> a specific version to another repository for promotion work flows.  Also,
>> the user could use another (custom) publisher that deals differently with
>> multiple files with the same path in the repository.  The FilePublisher
>> currently publishes the newest.  My point being, we, really cannot assume
>> how the repository will be used or which publisher *may* publish it.
>>
>>
> The problem was initially stated as "For direct repository version
> creation, plugins are not involved". It sounds like you disagree that this
> is a problem. Can you confirm this by telling us if plugins should be able
> to provide validation for this API provided by core?
>
>>
>> A File repository version cannot be properly published if it contains 2
>> FileContent units that both have the same relative path. The publisher has
>> to decide which FileContent to publish at the relative path. That decision
>> cannot be made intelligently by the publisher. The decision on which
>> content unit to include in the repository version rests with the user that
>> is creating the repository version. When a user tries to create a
>> repository version with a FileContent that has the same relative path as
>> another FileContent that was added previously, Pulp needs to inform the
>> user that there is a conflict (and not create the repositiory version).
>> This validation can only be provided by the File plugin.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>> We would like to get feedback on these issues being sound and worth
>>>>> resolving before we resume particular solution discussion[1].
>>>>>
>>>>> Thanks,
>>>>> Austin, Dennis, and Milan
>>>>>
>>>>> [1] https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.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 
>>> 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

Reply via email to