Packaging

re: Fedora issue tracker, sure, I will do that

FYI, I found a currently-open bz to get these versions of these packages into EPEL

https://bugzilla.redhat.com/show_bug.cgi?id=1492699

I would assume that gives us two courses of action, either go ahead and do the work ourselves, but let upstream know so that they can piggyback off of it, or the reverse, we help get it sorted out upstream and then pull in those packages to distribute ourselves for non-users of EPEL.

(Either way, I think getting it done would require our involvement, so I'm not sure the distinction matters much, and choice #1 is my preference)

dalley thank you for breaking out the Fedora stuff into those other tickets, that looks resolved. What about removing the 3.0 codepaths altogether? I added two checklist items assuming the answer is yes.

I'm +1 to grooming this after the build team acks it.

pcreech, @ehelms: Can you upgrade the stack as described here for 2.16? Also would you want to get it into EPEL (see comment 3) or self-distribute via fedorapeople in the long term? In the near tearm I think we have to self-distribute because upgrading EPEL would take a long time at least.

Given current workload, I think it's more prudent to get this into pulp-packaging than pursuing the epel route ourselves. If at such time it is added in to epel we can stop shipping it. But there have been many times where we needed to update the version or backport a fix ourselves in the past anyways, which also leans me towards the upstream route instead of epel.

There's mentioning of patching the builds here as well... Do we need to makes sure the changes get propogated, or are we going to update to a newer celery version with the fix for the builds we control?

Well, unfortunately there isn't an official celery release yet which includes that fix. The most current release is 4.1.0, which was released prior to our patch being merged. However, they have offered Brian the opportunity to create a 4.1.1 release, so it remains an option.

edit: I asked the Celery developers if they have a timeline for a new release - apparently 4.2 is being released fairly soon, only one blocker left.

My thought was that it's probably better to stick with what is in Fedora for now, since that has been tested the most thoroughly. I'm not sure where using a very new release would fall in terms of risk management for downstream. I'm open to the idea of using a newer release mostly because it looks like there are almost no new features in 4.1 and 4.2 and a lot of bugfixes, some of which at a glance might be relevant.

@Brian, what are your thoughts?

Let's say Celery 4.2 gets released within the next month. I think we would want to minimize downstream risk as much as possible by making sure Pulp 2.16 would be using this code. What is Fedora's policy on updating packages like that within a release? Would their guidelines prohibit upgrading those packages significantly in a released version? If yes, we would have to vendor those packages ourselves for Fedora on top of EL7. I'm not sure how we feel about that.

I will sit down at some point and take a look through the bugfixes in the changelog to try to figure out how worthwhile such an upgrade would be

I'm on board with taking the spec in the latest fedora, and building that and applying patches. Just wanted to make sure I knew what would be needed by releng

+1 to self-distributing EL7 and not pursuing the EPEL route. ty pcreech for the comment.

For the risk reasons dalley mentions, I'm +1 on using the existing versions in Fedora + the patch from https://pulp.plan.io/issues/2927

dalley, Fedora can put any version in Rawhide prior to the branch point. I suspect we should just let Rawhide upgrade naturally after upstream Kombu 4.2 is released. For risk reasons, EL7 should lag relatively far behind so I don't think we should upgrade from celery/kombu 4.z+patches to celery/kombu 4.2 for a few months after 4.2 is out at least.

All of that sounds good to me.