<div dir="ltr">Calling a create endpoint and getting back a 202 with a way to monitor the status of the request is pretty common practice in REST APIs[0]. I think it would be intuitive to users familiar with REST APIs that have async operations.<div><br></div><div>I think we could support allowing users to submit one-time publish params with their call to POST /../publications. It’s not great option but it’s an option.</div><div><br></div><div>[0] <a href="http://jsonapi.org/format/#crud-creating-responses-202" target="_blank">http://jsonapi.org/format/<wbr>#crud-creating-responses-202</a></div><div class="gmail_extra"><br clear="all"><div><div class="m_-3342564301073969609m_2058415817846505051gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 1, 2017 at 10:58 AM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 11/01/2017 09:16 AM, Brian Bouterse wrote:<br>
> Thanks for the response. Let's not move forward until we have more agreement in this area. I've written some<br>
> responses inline.<br>
><br>
</span><span>> On Wed, Nov 1, 2017 at 9:05 AM, Jeff Ortel <<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>>> wrote:<br>
><br>
> I'm not yet convinced about the proposed URL change for publishing. Can you help me understand why a POST to<br>
> the publications collection is more appropriate than the a POST to a publisher?<br>
><br>
><br>
> I believe the thinking is: REST suggests that POSTing to a resource is expected to create a new resource of<br>
> that type. So assume a users knows REST and they know they want to get a Publication created in Pulp, they<br>
> know exactly how to do that just by knowing REST. In the case of a POST to a publisher url with a special<br>
> 'publish' keyword on the end of it (the controller endpoint), they only way a user could know to do that is by<br>
> reading our docs. Both approaches would work, but I believe the former is more aligned with REST which means<br>
> users can do more without having to read Pulp docs.<br>
<br>
</span>I believe that if the user is experienced with REST, they will be expecting a 201 and an href to the created<br>
resource to be returned instead of a 202 and a task href. Further, they will expect the resource to be<br>
created as defined in the POST body. I think the side-effect of running the publisher to actually create the<br>
resource will be unexpected. The user would still need to read the docs to understand what's happening. Not<br>
saying this is all together wrong, just challenging the assertion that this would be more intuitive to the user.<br>
<span><br>
><br>
><br>
><br>
> A POST to the publications/ collection means the POST body should define the publication to be created.<br>
> Right? What about options that need to be passed to the publisher?<br>
><br>
><br>
> Yes, if we look at the fields of the publisher (link below), there are only two fields: 'created' and<br>
> 'publisher'. Since 'created' is set on the server automatically, the user would specify only the href to the<br>
> publisher in the POST body. For the MVP, we don't accept one-time options, and all other options are<br>
> configured on the publisher which is a different url call from both the publish controller and the publication<br>
> resource. So for the MVP this approach would work well. The future case also is better with this approach (I<br>
> think). When we do introduce one-time options, where will we store them?<br>
<br>
</span>Options are not stored. That's the point of them being one-time options vs. publisher attributes. My concern<br>
is that making this choice means that we will never support one-time publishing options. What do others think<br>
of that?<br>
<span><br>
We will probably be store them on the<br>
> publication too, and that makes sense, because we can't store N, one-time publish options on 1 publisher<br>
> instance, but we can store N, one-time publish options on N publications.<br>
><br>
> <a href="https://github.com/pulp/pulp/blob/15857fb0831c0998219a32e8d6ba52abdba20888/platform/pulpcore/app/models/publication.py#L6" rel="noreferrer" target="_blank">https://github.com/pulp/pulp/b<wbr>lob/15857fb0831c0998219a32e8d6<wbr>ba52abdba20888/platform/pulpco<wbr>re/app/models/publication.py#<wbr>L6</a><br>
><br>
><br>
><br>
> On 10/31/2017 03:13 PM, Brian Bouterse wrote:<br>
> > @dkliban, I'm +1 on that.<br>
> ><br>
> > @all, Please jump in if this is not the best direction for us to go.<br>
> ><br>
> > On Tue, Oct 31, 2017 at 3:55 PM, Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>><br>
</span>> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>>>> wrote:<br>
> ><br>
> > On Tue, Oct 31, 2017 at 3:52 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a><br>
<span>> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>>><wbr>> wrote:<br>
> ><br>
> > Would that return the 202 w/ a link to the task because the publication hasn't been created yet? Then<br>
> > using the created_resources they can see what was created, and in the event of failure the task fails<br>
> > and there are no created_resources.<br>
> ><br>
> > @dkliban is ^ the idea?<br>
> ><br>
> ><br>
> > Yes, the response would the same as it for the /publish URL right now. This is just a change in the URL<br>
> > that is used to make the request.<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Oct 31, 2017 at 3:48 PM, Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>><br>
</span><span>> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Oct 31, 2017 at 3:40 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a><br>
</span>> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>>>><br>
<span>> > wrote:<br>
> ><br>
> > +1 to updating #3033 to have a created_resources attribute which would be a list of<br>
> > GenericForeignKeys. It also needs docs, but I'm not entirely sure where.<br>
> ><br>
> > If we're going to introduce the above attribute, I think having the controller endpoint as-is<br>
> > would be the most usable. @dkliban do you see value in changing the URL structure if the<br>
> > created_resources attribute is introduced?<br>
> ><br>
> ><br>
> > This API call creates a publication resource. A POST to publishers/<id>/publications/ seems most<br>
> > appropriate for creating new publication resources.<br>
> ><br>
> > I can help review/groom these if that is helpful.<br>
> ><br>
> > -Brian<br>
> ><br>
> ><br>
> > On Tue, Oct 31, 2017 at 1:39 PM, David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a> <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>><br>
</span><span>> > <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a> <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>><wbr>>> wrote:<br>
> ><br>
> > Personally I am not opposed to the url endpoint you suggest.<br>
> ><br>
> > It also seems like there is some consensus around adding a ‘created resources’<br>
> > relationship to Task or at least prototyping that out to see what it would look like.<br>
> ><br>
> > If no one disagrees, should I update issue #3033 with those two items?<br>
> ><br>
> ><br>
> > David<br>
> ><br>
> > On Wed, Oct 25, 2017 at 1:23 PM, Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>><br>
</span><span>> > <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>>>> wrote:<br>
> ><br>
> > On Wed, Oct 25, 2017 at 11:24 AM, David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a> <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>><br>
</span><span>> > <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a> <mailto:<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>><wbr>>> wrote:<br>
> ><br>
> > I don’t know that the ambiguity around whether a task has a publication or not is<br>
> > a big deal. If I call the publication endpoint, I’d expect a publication task<br>
> > which either has 1 publication or 0 (if the publication failed) attached to it.<br>
> ><br>
> > In terms of ambiguity, I see a worse problem around adding a task_id field to<br>
> > publications. As a user, I don’t know if a publication failed or not when I get<br>
> > back a publication object. Instead, I have to look up the task to see if it is a<br>
> > real (or successful) publication. Moreover, since we allow users to remove/clean<br>
> > up tasks, that task may not even exist anymore.<br>
> ><br>
> ><br>
> > I agree that the ephemeral nature of tasks makes the originally proposed solution<br>
> > non-deterministic. I am open to associating 'resources created' with a task instead.<br>
> ><br>
> > However, I still think there is value in changing the rest API endpoint for starting a<br>
> > publish task to POST<br>
> > /api/v3/repositories/<repo-id<wbr>>/publishers/<type>/<name>/pub<wbr>lications/. However, I will<br>
> > start a separate thread for that discussion.<br>
> ><br>
> > - Dennis<br>
> ><br>
> ><br>
> ><br>
> > David<br>
> ><br>
> > On Wed, Oct 25, 2017 at 11:03 AM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>><br>
</span><span>> > <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Oct 24, 2017 at 10:00 PM, Michael Hrivnak <<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a> <mailto:<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>><br>
</span><span>> > <mailto:<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a> <mailto:<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Oct 24, 2017 at 2:11 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>><br>
</span><div><div class="m_-3342564301073969609m_2058415817846505051h5">> > <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>>>> wrote:<br>
> ><br>
> > Thanks everyone for all the discussion! I'll try to recap the<br>
> problem<br>
> > and some of the solutions I've heard. I'll also share some of my<br>
> > perspective on them too.<br>
> ><br>
> > What problem are we solving?<br>
> > When a user calls "publish" (the action API endpoint) they get a 202<br>
> > w/ a link to the task. That task will produce a publication. How can<br>
> > the user find the publication that was produced by the task? How can<br>
> > the user be sure the publication is fully complete?<br>
> ><br>
> ><br>
> > What are our options?<br>
> > 1) Start linking to created objects from task status. I believe its<br>
> > been clearly stated about why we can't do this. If it's not<br>
> clear, or<br>
> > if there are other things we should consider, let's talk about it.<br>
> > Acknowledging or establishing agreement on this is crucial because a<br>
> > change like this would bring back a lot of the user pain from<br>
> pulp2. I<br>
> > believe the HAL suggestion falls into this area.<br>
> ><br>
> ><br>
> > I may have missed something, but I do not think this is clear. I<br>
> know that<br>
> > Pulp 2's API included a lot of unstructured data, but that is not at all<br>
> > what I'm suggesting here.<br>
> ><br>
> > It is standard and recommended practice for REST API responses to<br>
> include<br>
> > links to resources along with information about what type of<br>
> resource each<br>
> > link references. We could include a reference to the created<br>
> resource and<br>
> > an identifier for what type of resource it is, and that would be well<br>
> > within the bounds of good REST API design. HAL is just one of<br>
> several ways<br>
> > to accomplish that, and I'm not pitching any particular solution<br>
> there. In<br>
> > any case, I'm not sure what the problem would be with this approach.<br>
> ><br>
> ><br>
> > I agree it is a standard practice for a resource to include links to other<br>
> > resources, but the proposal is to include "generic" links is different and<br>
> > creates a different user experience. I believe referencing the task from the<br>
> > publication will be easier for users and clients. When a user looks up a<br>
> > publication, they will always know they'll get between 0 and 1 links to a<br>
> > task. You can use that to check the state of the publication. If we link to<br>
> > "generic" resources (like a publication) from a task, then if I ask a<br>
> user "do<br>
> > you expect task ede3af3e-d5cf-4e18-8c57-69ac4d<wbr>4e4de6 to contain a link to a<br>
> > publication or not?" you can't know until you query it. I think that<br>
> ambiguity<br>
> > was a pain point in Pulp2. I don't totally reject this solution, but this is<br>
> > an undesirable property (I think).<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > 2) Have the user find the publication via query that sorts on<br>
> time and<br>
> > filters only for a specific publisher. This could be fragile because<br>
> > with a multi-user system and no hard references between publications<br>
> > and tasks, answering the question "which is the publication for<br>
> me" is<br>
> > hard because another user could have submitted a publish too. While<br>
> > not totally perfect, this could work.<br>
> ><br>
> ><br>
> > In theory if a user queried for a publication from a specific publisher<br>
> > that was created between the start and end times of the task, that<br>
> should<br>
> > unambiguously identify the correct publication. But depending on<br>
> > timestamps is not a particularly robust nor confidence-inspiring way to<br>
> > reference a resource.<br>
> ><br>
> > Agreed and Agreed<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > 3) Have the user create a publication directly like any other REST<br>
> > resource, and help the user understand the state of that<br>
> resource over<br>
> > time. I believe the proposal at the start of this thread is<br>
> > recommending this solution. I'm also +1 on this solution.<br>
> ><br>
> ><br>
> > I think the problem with this is that a user cannot create a<br>
> publication.<br>
> > A user can only ask a plugin to create a publication. Until the plugin<br>
> > creates the publication, there is no publication.<br>
> ><br>
> ><br>
> > Note a publication is an object, but really we mean a publication and it's<br>
> > related PublishedArtifact, PublishedMetadat, etc objects. It would be<br>
> > straightforward for a user to create a publication using the viewset and<br>
> have<br>
> > the task associated with it call the publisher to build out the associated<br>
> > PublishedArtifact, PublishedContent, PublishedMetadata, etc. We should<br>
> explore<br>
> > if this is good or not, but it is possible.<br>
> ><br>
> > As an aside, this is related to a problem everyone should be aware of: the<br>
> > existence of a publication does not guarantee that publication is finished<br>
> > publishing. Even with option 1, where the task creates the publisher and<br>
> links<br>
> > to it in the task status, while the publisher is running it must save the<br>
> > Publication so that the PublishedArtifact, etc can link to it. So for any<br>
> > given publication, in order to know if it's "fully finished and consistent"<br>
> > you must be able to check the status of the associated task that<br>
> produced it.<br>
> ><br>
> ><br>
> ><br>
> > As an aside, I don't think considering versioned repos as a possible<br>
> > solution is helping us with this problem. The scope of the current<br>
> > problem is relatively small and the scope of planning for versioned<br>
> > repos is large.<br>
> ><br>
> ><br>
> > Versioned repos is a potential solution. In that scenario, a user would<br>
> > request publication of a specific repo version (perhaps defaulting<br>
> to the<br>
> > latest), the publication would be linked to that version, and that is an<br>
> > easy mechanism for the user to find the publication they want.<br>
> Ultimately<br>
> > the user is interested in working with a specific content set<br>
> anyway. They<br>
> > get a repo to a state where it has the content they want, and then they<br>
> > publish that content set. No matter what we do with publications, users<br>
> > will think of them in terms of related content sets. A repo version is<br>
> > that immutable content set they can work with confidently.<br>
> ><br>
> ><br>
> > It's neat to me that that versions are snapshots of content and publications<br>
> > are snapshots of content. Publications already create much of the value<br>
> > propostion of versioned repos with publications. They allow you to work with<br>
> > specific content sets like you describe. Also they allow for rollback.<br>
> So that<br>
> > is all great for our users. For this thread, I want to bring the<br>
> conversation<br>
> > back to where it started, solving a small problem about linking two<br>
> resources<br>
> > that already exist.<br>
> ><br>
> ><br>
> > It helps the rollback scenario a lot as well. Versioning repos allows a<br>
> > user to see what the differences are between two content sets, and thus<br>
> > two different publications, which informs them about when and how<br>
> far back<br>
> > they should roll back a distribution.<br>
> ><br>
> ><br>
> > - user discovers a horrible flaw in a piece of content<br>
> > - user queries for which version of the repo introduced that piece<br>
> of content<br>
> > - user updates the distribution to serve the publication that came<br>
> before<br>
> > the one which introduced the piece of content, optionally re-publishing<br>
> > that version in case its publication was deleted or had never been<br>
> made in<br>
> > the first place.<br>
> ><br>
> > --<br>
> ><br>
> > Michael Hrivnak<br>
> ><br>
> > Principal Software Engineer, RHCE<br>
> ><br>
> > Red Hat<br>
> ><br>
> ><br>
> ><br>
> > _____________________________<wbr>__________________<br>
> > Pulp-dev mailing list<br>
> > <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>><br>
</div></div>> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>>><br>
<span>> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a><br>
> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailm<wbr>an/listinfo/pulp-dev</a>><br>
> > <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailm<wbr>an/listinfo/pulp-dev</a> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a>>><br>
> ><br>
> ><br>
> ><br>
> > _____________________________<wbr>__________________<br>
> > Pulp-dev mailing list<br>
</span>> > <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<div class="m_-3342564301073969609m_2058415817846505051HOEnZb"><div class="m_-3342564301073969609m_2058415817846505051h5">> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>>><br>
> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a><br>
> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailm<wbr>an/listinfo/pulp-dev</a>><br>
> > <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailm<wbr>an/listinfo/pulp-dev</a><br>
> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailm<wbr>an/listinfo/pulp-dev</a>>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > Pulp-dev mailing list<br>
> > <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>><br>
> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a>><br>
> ><br>
><br>
><br>
> _____________________________<wbr>__________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailma<wbr>n/listinfo/pulp-dev</a>><br>
><br>
><br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div>