Deprecating PDF Certificates

[Sandy Student]

Hello open edX users and contributors,

As you may have encountered while running or working with Open edX, our platform historically has offered learners certificates of course completion that are either web-based (rendered in the browser as HTML) or PDF-based. If you've ever used the "Certificate Web/HTML View Enabled" setting, you are likely familiar with this. If you have not, note that this setting defaults to 'true' and your instance is likely to be using web certificates.

We are looking at the possibility of deprecating PDF certificates as part of the next Open edX release and possibly even deleting the code entirely. edX.org no longer supports PDF certificates, and as we move away from using RabbitMQ, we are also moving away from supporting PDF certs because they are integrated directly with RabbitMQ–that is, they are not managed by Celery like other asynchronous tasks. I am reaching out to get a sense of how extensively PDF certificates are used by other Open edX instances and how much of a burden it would be for those instances to move to web certificates.

Thank you!

Sandy

Software Engineer, edX Educator team

[Pierre Mailhot]

We are still using PDF certificates and I have no intention of moving to HTML certificates.

We were looking for the integration of the Stanford code into Open edX.

[Régis Behmo]

Hi Sandy,

> as we move away from using RabbitMQ

Could you give a bit more background on this? How do you intend to replace RabbitMQ for running asynchronous celery tasks?

Régis

[Sandy Student]

Hi everyone,

To Régis's question, we will be moving to Redis instead of RabbitMQ as our messaging queue to Celery.

After some very helpful responses from this thread and from Giulio at Stanford on Slack, it's becoming clear that while we will still deprecate PDF certs on edx.org, we should leave the code intact for use in other Open instances. This should mean no significant changes for you beyond possibly a configuration change that will be detailed in a future Open release. Feel free to continue providing input! 

Best,

Sandy

--
You received this message because you are subscribed to a topic in the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/14bd2c49-f8fa-48ef-b225-f530c772568d%40googlegroups.com.

[David Ormsbee]

Hi Régis,

I'm on a different team at edX, but I can give a little more context on RabbitMQ. We've had a lot of operational issues with RabbitMQ under load and have found Redis to be better behaved. The fact that AWS offers a managed version of it is also very appealing. From a code point of view though, we're still committed to using interface libraries like Celery and Kombu to abstract the specific broker away, so Open edX installs should have the flexibility to continue with RabbitMQ if that works well for them.

Take care.

Dave

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.

[stv stnfrd]

Hi Sandy,

> I am reaching out to get a sense of how extensively PDF certificates
> are used by other Open edX instances

As disccussed in Slack, Stanford uses these extensively.

> and how much of a burden it would be for those instances to move to
> web certificates.

Too much. We have no plans to do so.
Besides the effort involved, we prefer the UX and product workflow of PDF certs.

> edX.org no longer supports PDF certificates

Stanford has maintained our fork of the codebase since late 2014 [1].
Before we forked, we were the active maintainers of the core repository;
we used to have commit access and our developers have authored 78/136 of
the commits to-date [6].

Since forking, we have continued to improve the codebase, including the
introduction of a YAML-based templating system which significantly
increases speed and ease of certificate design and development [2].

> as we move away from using RabbitMQ, we are also moving away from
> supporting PDF certs because they are integrated directly with
> RabbitMQ

This isn't quite right; certs integrate via XQueue, not RabbitMQ [3].

> they are not managed by Celery like other asynchronous tasks.

There's some truth here. The certificate "agent" [3] is a
supervisor-managed service that polls an XQueue endpoint and
pops/processes jobs from there. We've previously expressed interest in
decoupling certs/xqueue for varying reasons, namely that we have a few
deployments that otherwise don't need XQueue and it would be nice to
remove that dependency from the infrastructure.

I did a proof-of-concept of this waaay back at the 2015 OpenEdX
Conference Hackathon, but never had the time/motivation to make it
production-ready [4][5].  We'd be interested in finding a path forward
in revisiting this.  That said, unless edX has plans to deprecate XQueue
(do you?), this seems to be a less pressing concern.

> We are looking at the possibility of deprecating PDF certificates as
> part of the next Open edX release and possibly even deleting the code
> entirely.

We would not like to see this happen and hope to find a path forward for
preserving this functionality. We'd like to explore options for assuming
stewardship of this codebase, so let us know how we can help.

Thanks for reaching out and hope to discuss further,
Steven at Stanford

[1] https://github.com/Stanford-Online/openedx-certificates
[2] https://github.com/Stanford-Online/openedx-certificates/blob/master/cert-data.yml
[3] https://github.com/Stanford-Online/openedx-certificates/blob/master/certificate_agent.py#L26-L32
[4] https://github.com/stvstnfrd/edx-certificates/pull/1
[5] https://github.com/stvstnfrd/edx-platform/pull/12
[6] https://github.com/edx/edx-certificates/commits/master

[Sandy Student]

Hi Steven / all,

To be clear, given Giulio's input on Slack and the responses on this thread, I am not planning on changing anything related to PDF certs aside from hiding the option to use them on edX's own sites. From an edx.org course author standpoint, PDF certificates will be deprecated in that it will no longer be possible to run a course on edx.org that uses PDF certificates, but all of the other code to generate/use them will remain intact (and if Stanford can contribute its improvements back to the main codebase, all the better!).

Other Open instances, as Dave said, should still be able to run with a message queue other than Redis, so the change that we are making locally will have no major consequences for other Open instances. Stanford and others will absolutely be able to continue using PDF certs.

Thanks everyone for your input–it's been very helpful in clarifying how we should go about this change. 

Best,

Sandy

--
You received this message because you are subscribed to a topic in the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/b8005fa2-e5e6-4053-8709-791b34fbf8ff%40googlegroups.com.