So I think eventually we’ll need a top level /repository_versions/ resource endpoint to allow users to search for versions across repos. A couple examples:
1. As a user, I can list all repo versions that contain a particular content unit 2. As a user, I can view repo versions that were created yesterday I was going to propose that we have both endpoints (one under repositories and one top-level one) kind of like how we have two endpoints for content. David On Mon, Aug 6, 2018 at 12:43 PM Brian Bouterse <bbout...@redhat.com> wrote: > Does anyone have strong feelings or concerns about unnesting repository > versions from /repositories/1/version/1/ to something like /repoversion/1/ ? > > As a mini-group of devs talk it over this week, understanding how > users/devs feel about this nesting would be helpful. > > Also thank you @bizhang for the great prototyping and communication. > > On Fri, Aug 3, 2018 at 4:05 PM, Bihan Zhang <bizh...@redhat.com> wrote: > >> I've opened a PR that implements a new field that will resolve and >> display both _href and id. >> https://github.com/pulp/pulp/pull/3575 >> >> Take a look and let me know what y'all think. >> >> >> On Thu, Jul 26, 2018 at 2:33 PM, Robin Chan <rc...@redhat.com> wrote: >> >>> I really appreciate recent trend on our mailing lists that when >>> conversations are happening on irc or in meetings, that updates are >>> reported back to the relevant thread. I like that individuals are taking >>> the initiative to have that real time communication and work out concerns >>> in a timely manner, and I really like that everyone else can get caught up. >>> This supports the timezone- diverse pulp community as well as time away for >>> summer travel. I personally have found this update and others like it on >>> other threads here in pulp-land to be very helpful. >>> >>> Thanks, >>> Robin >>> >>> On Thu, Jul 26, 2018 at 12:13 PM, Bihan Zhang <bizh...@redhat.com> >>> wrote: >>> >>>> bmbouter, dkliban, daviddavis, jsherril and I just chatted about this >>>> in person. Here are the minutes from that meeting: >>>> >>>> We have tools (API, docs, bindings+3rd party applications, CLI) that >>>> needs to refer to references somehow, and we need to figure out whether >>>> these references should be the href or a combination of the href and the >>>> id. >>>> Dkliban has opened a PR updating the schemas to only use the hrefs, but >>>> this schema isn't valid. [0] >>>> Bmbouter has proposed some solutions to using both hrefs and ids, and >>>> option 2 is by far the most popular [1] >>>> >>>> If we go the hybrid href and id route there are some concerns: >>>> - How do we serialize createdresource that can be either >>>> publications or repositoryversion? >>>> - additionalproperties field in openapi should take care of it >>>> - repository has to be referenced with 2 parameters (repo id and >>>> version number) instead of just an id like all other resources, this isn't >>>> consistent >>>> - maybe we should unnest repoversion, this also allows us to >>>> search for content across repository versoins >>>> - probably should leave as is, since it works, and can be >>>> described in openapiv2 >>>> - we need to restructure our API, and this could be time consuming >>>> - changes needed to hyperlinked related field, created resource >>>> schema, content added api endpoint, need to validate openapi schema is >>>> compliant for all requests and responses >>>> >>>> If we merge dkliban's PR, and use only hrefs there's also some concerns: >>>> - noncompliant schema >>>> - we aren't in a position to ship and support the tool chain >>>> for a noncompliant schema, unlike google >>>> - following spec gives some peace of mind for future support >>>> >>>> We decided on the following action items: >>>> - bizhang will take some time to write out a hybrid href and id POC >>>> next week >>>> - dkliban will reach out to openapi, to see what the status is of >>>> the href work, and maybe get an estimation of when that will be accepted >>>> into the specification >>>> >>>> >>>> [0] https://github.com/pulp/pulp/pull/3561#issuecomment-407496845 >>>> [1] https://github.com/pulp/pulp/pull/3561#issuecomment-407888652 >>>> >>>> On Wed, Jul 25, 2018 at 4:43 PM, Brian Bouterse <bbout...@redhat.com> >>>> wrote: >>>> >>>>> I'm exploring the changes required to use IDs and hrefs on the PR >>>>> here: https://github.com/pulp/pulp/pull/3561#issuecomment-407888652 >>>>> >>>>> On Wed, Jul 25, 2018 at 4:24 PM, David Davis <davidda...@redhat.com> >>>>> wrote: >>>>> >>>>>> I know we don’t support things like accepting hrefs as references to >>>>>> resources but if I remember correctly we do return hrefs alongside ids in >>>>>> responses in Pulp 2. Is that not correct? >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On Wed, Jul 25, 2018 at 4:17 PM Dennis Kliban <dkli...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> I don't think we support both hrefs and ids in Pulp 2. The Pulp 2 >>>>>>> REST API does not accept HREFs as references to resources. In Pulp 2's >>>>>>> REST >>>>>>> API we do not even have resources that have relationships to other >>>>>>> resources. The relationships between resources are established by >>>>>>> nesting >>>>>>> them under one another. e.g.: /pulp/api/v2/repositories/<repo_id>/ >>>>>>> and /pulp/api/v2/repositories/<repo_id>/importers/<importer_id>/. >>>>>>> In Pulp 2, if a user wanted to reference content units in a request, the >>>>>>> API requires writing a filter that uses Mongodb syntax. >>>>>>> >>>>>>> Pulp 3's REST API has a resources called Task that has a >>>>>>> 'created_resource' attribute. This resource is a reference to either a >>>>>>> repository version or a publication at this time. Pulp 3's REST API also >>>>>>> supports users specifying references to content units that should be >>>>>>> added >>>>>>> or removed from a repository. These needs do not exist in Pulp 2's REST >>>>>>> API. >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 25, 2018 at 3:55 PM, David Davis <davidda...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Correct me if I’m wrong but Pulp 2 supported @bizhang’s model of >>>>>>>> providing both hrefs and ids. Was that a source of problems or >>>>>>>> complaints >>>>>>>> by Pulp 2 users? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 25, 2018 at 3:08 PM Dennis Kliban <dkli...@redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> For everyone following along, the conversation has moved to Github >>>>>>>>> - on the PR[0] with the proposed changes. >>>>>>>>> >>>>>>>>> [0] https://github.com/pulp/pulp/pull/3561 >>>>>>>>> >>>>>>>>> On Tue, Jul 24, 2018 at 11:15 AM, Bihan Zhang <bizh...@redhat.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> @dkliban I've tried out your PR and left a question: >>>>>>>>>> https://github.com/pulp/pulp/pull/3561#issuecomment-407425172 >>>>>>>>>> >>>>>>>>>> Won't it be problematic with the openapi definitions causing us >>>>>>>>>>> to have two schemas? Accepting the data in two forms is one thing, >>>>>>>>>>> but >>>>>>>>>>> using openapi to describe it both ways is something I don't >>>>>>>>>>> understand >>>>>>>>>>> well. Are we going to ship and test two? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think we'll be defining the data in two different ways >>>>>>>>>> in openapi. We need to pass a {repository identifier} to /sync/, >>>>>>>>>> openapi >>>>>>>>>> expects a string, what we do with that string is up to us. (In the >>>>>>>>>> following example the format is "uri" but this isn't actually used >>>>>>>>>> for >>>>>>>>>> validation at all, since it's not defined by the swagger >>>>>>>>>> specification [0], >>>>>>>>>> we can also clear out the format field, since format is only there to >>>>>>>>>> support documentation needs) >>>>>>>>>> >>>>>>>>>> - RepositorySyncURL: >>>>>>>>>> { >>>>>>>>>> - required: >>>>>>>>>> [ >>>>>>>>>> - "repository" >>>>>>>>>> ], >>>>>>>>>> - type: "object", >>>>>>>>>> - properties: >>>>>>>>>> { >>>>>>>>>> - repository: >>>>>>>>>> { >>>>>>>>>> - title: "Repository", >>>>>>>>>> - description: "A URI of the repository to be >>>>>>>>>> synchronized.", >>>>>>>>>> - type: "string", >>>>>>>>>> - format: "uri" >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> }, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can see why some users would want to refer to things in the api >>>>>>>>>>> using ID not an href. I think about the case that when calling >>>>>>>>>>> publish and >>>>>>>>>>> referring to a RepositoryVersion with id=827561, num=3, and for >>>>>>>>>>> repository=1234. With an ID alternately accepted, you could call >>>>>>>>>>> publish >>>>>>>>>>> and submit repo_version=827561 instead of >>>>>>>>>>> repo_version='repositories/1234/version/3/'. I can see that >>>>>>>>>>> benefit, but it >>>>>>>>>>> comes with downsides. Saving/storing a url I know feels a little >>>>>>>>>>> strange, >>>>>>>>>>> but I do see several upsides... >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Doing it only with hrefs, ensures those benefits (nice recap >>>>>>>>>>> btw) will always be true. Having to submit the references using >>>>>>>>>>> something >>>>>>>>>>> like 'repositories/1234/version/3/' will cause any client to store >>>>>>>>>>> them >>>>>>>>>>> that way. I think that's a good thing because someone >>>>>>>>>>> troubleshooting their >>>>>>>>>>> scripts or in katello's db will instead >>>>>>>>>>> have 'repositories/1234/version/3/', which they can directly use >>>>>>>>>>> with HTTP. >>>>>>>>>>> I think this is valuable. Otherwise they would have repo version >>>>>>>>>>> 827561, >>>>>>>>>>> which now they have to do extra work to start interacting with that >>>>>>>>>>> object >>>>>>>>>>> via HTTP. Storing urls removes the "templating" step from the >>>>>>>>>>> troubleshooter's responsibilities so we're making their job easier. >>>>>>>>>>> Spacewise, I don't think the clients benefit hugely from storing >>>>>>>>>>> 827561 >>>>>>>>>>> instead of 'repositories/1234/version/3/', but humans do. >>>>>>>>>>> >>>>>>>>>> Why don't we provide the ability to use both href and id as >>>>>>>>>> identifiers, and katello can choose the route that is right for them >>>>>>>>>> based >>>>>>>>>> on the points you bring up? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I don't know much about the CLI, but if we want to enable a >>>>>>>>>>> specific user experience, I think we can find a way to make that >>>>>>>>>>> work. >>>>>>>>>>> Overall I think users should be able to specify things in the most >>>>>>>>>>> intuitive way possible, and I don't see how API data formats >>>>>>>>>>> directly >>>>>>>>>>> influence that. For example I think referring to a repository by >>>>>>>>>>> it's name >>>>>>>>>>> is the most natural; it's more natural than 1234 or >>>>>>>>>>> repositories/1234. >>>>>>>>>>> >>>>>>>>>> +1 the CLI can resolve name to identifiers (either id or href), >>>>>>>>>> so I'm not too concerned with that. >>>>>>>>>> >>>>>>>>>> [0] >>>>>>>>>> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types >>>>>>>>>> >>>>>>>>>> On Mon, Jul 23, 2018 at 9:51 PM, Dennis Kliban < >>>>>>>>>> dkli...@redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> I've made a work in progress PR[0] that demonstrates the changes >>>>>>>>>>> I was suggesting. >>>>>>>>>>> >>>>>>>>>>> [0] https://github.com/pulp/pulp/pull/3561 >>>>>>>>>>> >>>>>>>>>>> On Mon, Jul 23, 2018 at 3:50 PM, Brian Bouterse < >>>>>>>>>>> bbout...@redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Having two ways to refer to objects in the API makes me >>>>>>>>>>>> nervous. I have some questions/concerns/ideas. I'm also interested >>>>>>>>>>>> to see >>>>>>>>>>>> what dkliban's bindings produce in terms of a resolution of the >>>>>>>>>>>> swagger >>>>>>>>>>>> issues. >>>>>>>>>>>> >>>>>>>>>>>> Won't it be problematic with the openapi definitions causing us >>>>>>>>>>>> to have two schemas? Accepting the data in two forms is one thing, >>>>>>>>>>>> but >>>>>>>>>>>> using openapi to describe it both ways is something I don't >>>>>>>>>>>> understand >>>>>>>>>>>> well. Are we going to ship and test two? >>>>>>>>>>>> >>>>>>>>>>>> I can see why some users would want to refer to things in the >>>>>>>>>>>> api using ID not an href. I think about the case that when calling >>>>>>>>>>>> publish >>>>>>>>>>>> and referring to a RepositoryVersion with id=827561, num=3, and for >>>>>>>>>>>> repository=1234. With an ID alternately accepted, you could call >>>>>>>>>>>> publish >>>>>>>>>>>> and submit repo_version=827561 instead of >>>>>>>>>>>> repo_version='repositories/1234/version/3/'. I can see that >>>>>>>>>>>> benefit, but it >>>>>>>>>>>> comes with downsides. Saving/storing a url I know feels a little >>>>>>>>>>>> strange, >>>>>>>>>>>> but I do see several upsides... >>>>>>>>>>>> >>>>>>>>>>>> Doing it only with hrefs, ensures those benefits (nice recap >>>>>>>>>>>> btw) will always be true. Having to submit the references using >>>>>>>>>>>> something >>>>>>>>>>>> like 'repositories/1234/version/3/' will cause any client to store >>>>>>>>>>>> them >>>>>>>>>>>> that way. I think that's a good thing because someone >>>>>>>>>>>> troubleshooting their >>>>>>>>>>>> scripts or in katello's db will instead >>>>>>>>>>>> have 'repositories/1234/version/3/', which they can directly use >>>>>>>>>>>> with HTTP. >>>>>>>>>>>> I think this is valuable. Otherwise they would have repo version >>>>>>>>>>>> 827561, >>>>>>>>>>>> which now they have to do extra work to start interacting with >>>>>>>>>>>> that object >>>>>>>>>>>> via HTTP. Storing urls removes the "templating" step from the >>>>>>>>>>>> troubleshooter's responsibilities so we're making their job easier. >>>>>>>>>>>> Spacewise, I don't think the clients benefit hugely from storing >>>>>>>>>>>> 827561 >>>>>>>>>>>> instead of 'repositories/1234/version/3/', but humans do. >>>>>>>>>>>> >>>>>>>>>>>> I don't know much about the CLI, but if we want to enable a >>>>>>>>>>>> specific user experience, I think we can find a way to make that >>>>>>>>>>>> work. >>>>>>>>>>>> Overall I think users should be able to specify things in the most >>>>>>>>>>>> intuitive way possible, and I don't see how API data formats >>>>>>>>>>>> directly >>>>>>>>>>>> influence that. For example I think referring to a repository by >>>>>>>>>>>> it's name >>>>>>>>>>>> is the most natural; it's more natural than 1234 or >>>>>>>>>>>> repositories/1234. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 19, 2018 at 8:30 AM, Daniel Alley < >>>>>>>>>>>> dal...@redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Keep in mind that as of yesterday, unless we revert the >>>>>>>>>>>>> change, we are using Integers IDs instead of UUIDs >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/pulp/pulp/pull/3549 >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 18, 2018 at 9:57 PM, Bihan Zhang < >>>>>>>>>>>>> bizh...@redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jul 18, 2018 at 1:05 PM, Dennis Kliban < >>>>>>>>>>>>>> dkli...@redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was asked on IRC to state what problems the proposed >>>>>>>>>>>>>>> changes are trying to address. There are two problems I see >>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>> current OpenAPI 2.0 schema Pulp's REST API provides. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The path parameters in the schema don't reflect the >>>>>>>>>>>>>>> parameters our users should be using for identifying the >>>>>>>>>>>>>>> resources >>>>>>>>>>>>>>> available via REST API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not convinced that we should use hrefs as the sole >>>>>>>>>>>>>> identifiers for the resources. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here are the reasons I see that we use hrefs as identifiers >>>>>>>>>>>>>> in a REST API context: >>>>>>>>>>>>>> 1. Each href provides full context into the resource it >>>>>>>>>>>>>> identifies. When given a href you would know exactly which >>>>>>>>>>>>>> resource it is >>>>>>>>>>>>>> referencing and would never run into the issue of: what is this >>>>>>>>>>>>>> {uuid} >>>>>>>>>>>>>> because you know it is a 'repositories/{uuid}' >>>>>>>>>>>>>> 2. discoverability, you know exactly how to access >>>>>>>>>>>>>> resources from hitting the root url (and in a webui can just >>>>>>>>>>>>>> click) >>>>>>>>>>>>>> 3. You would not need to construct urls from templates >>>>>>>>>>>>>> >>>>>>>>>>>>>> But things are different if we look at it from a >>>>>>>>>>>>>> bindings/client context. The difference is mainly due to how >>>>>>>>>>>>>> discoverability is done: in the REST API context the user has >>>>>>>>>>>>>> little prior >>>>>>>>>>>>>> knowledge to what resources are available, and how to access >>>>>>>>>>>>>> theses >>>>>>>>>>>>>> resoruces. But the bindings/client are generated from the >>>>>>>>>>>>>> schema, which >>>>>>>>>>>>>> defines exactly how resources are structured, and what the >>>>>>>>>>>>>> context of each >>>>>>>>>>>>>> {uuid} is. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Given an {uuid} the client/bindings knows exactly what >>>>>>>>>>>>>> resource this {uuid} refers to. With hrefs there would be >>>>>>>>>>>>>> redundant >>>>>>>>>>>>>> information pulp.repositories('repositories/{uuid}') (why do I >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> specify repositories twice?) >>>>>>>>>>>>>> 2. Discoverability is done with the schema which contains >>>>>>>>>>>>>> all the information about available resources/endpoints >>>>>>>>>>>>>> 3. URL construction is done by the client, so the user >>>>>>>>>>>>>> would also never need to do any url construction themselves >>>>>>>>>>>>>> (unless we >>>>>>>>>>>>>> continue to force href only identifiers, in which case they >>>>>>>>>>>>>> might have to >>>>>>>>>>>>>> do some url construction to pass as arguments) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think hrefs and uuid identifiers are mutually >>>>>>>>>>>>>> exclusive. I propose that we extend HyperlinkedRelatedFields to >>>>>>>>>>>>>> accept >>>>>>>>>>>>>> either href or uuid, and map these HyperlinkedRelatedFields to >>>>>>>>>>>>>> each other >>>>>>>>>>>>>> in the schema with openapi definition objects [0]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [0] >>>>>>>>>>>>>> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#responses-definitions-object >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - The path parameters don't have a description in the >>>>>>>>>>>>>>> schema. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 to updating the schema descriptions for these parameters >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do others agree with these problem statements? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jul 18, 2018 at 9:31 AM, Dennis Kliban < >>>>>>>>>>>>>>> dkli...@redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am working on improving the OpenAPI 2.0 schema for Pulp >>>>>>>>>>>>>>>> 3. I would like to get some input on the improvements I am >>>>>>>>>>>>>>>> proposing. The >>>>>>>>>>>>>>>> schema is used to generate our REST API documentation as well >>>>>>>>>>>>>>>> as the >>>>>>>>>>>>>>>> bindings with swagger-codegen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The docs generated from our current schema look something >>>>>>>>>>>>>>>> like this: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> GET >>>>>>>>>>>>>>>> /repositories/{repository_pk}/versions/{number}/content/ >>>>>>>>>>>>>>>> <https://docs.pulpproject.org/en/3.0/nightly/integration-guide/rest-api/index.html#get--repositories-repository_pk-versions-number-content-> >>>>>>>>>>>>>>>> Parameters: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - *number* (*integer*) – >>>>>>>>>>>>>>>> - *repository_pk* (*string*) – >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Status Codes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 200 OK >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1> >>>>>>>>>>>>>>>> – >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since Pulp identifies resources using their HREFs, I am >>>>>>>>>>>>>>>> proposing that the schema produce documentation that states: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> GET /{repository_version_href}/content/ >>>>>>>>>>>>>>>> Parameters: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - *repository_version_href* (string) – HREF for the >>>>>>>>>>>>>>>> repository version >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Status Codes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - 200 OK >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1> >>>>>>>>>>>>>>>> – >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thoughts? Ideas? All feedback is welcome. Thank you! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
