#4863 Stand up PDC for releng
Closed: Fixed None Opened 8 years ago by ralph.

We'd like to stand up the product-definition-center for releng as part of a longer term project of enhancing the release tooling.

https://github.com/release-engineering/product-definition-center

In short, it's the thing that will know what all the artifacts are that we create, what goes in to them, what the definitions of the editions, and the layers are, what rings are, etc..

The team that wrote it is working on a copr build.

We should stand it up in the cloud as soon as we can to test it how and see how it works.

Longer term, if all seems good, we should look at standing it up in staging and then production.

This is a tracking ticket to leave comments and discussion about the general progress there.


Fwiw the github repo contains dockerfile. For the convenience I built it as sochotni/pdc. Dockerfile contains instructions for running it but there's certainly improvements that could be done - such as exposing the ports in the dockerfile itself perhaps.

edit: xchu created a copr repo as well: https://copr.fedoraproject.org/coprs/xchu/pdc-test/
It probably needs some ansibling to be usable though :-)

The question of automatically triggering Docker image rebuilds on RPM updates came up in this week's Env & Stacks meeting, and having at least a demonstration instance of PDC available would be helpful for that.

Is there an ETA on having an instance up and running in the Fedora cloud?

ETA is October 2nd. A hurdle in the way will be replacing the kerberos RemoteUser middleware with something that can talk to our ipsilon openid provider, but that should be manageable.

Bad news bears -- I've got to push the ETA date back a week to Oct 9th.

I need to work instead on completing the deployment for #4896, since a number of other releng initiatives are blocking on it and others who would do it are unavailable this week.

Notes to self (still busy with autocloud stuff). On '''the deployment side'''

I started a pdc role in our repo: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/pdc

And there's the start of a playbook here: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/hosts/pdc-devnode.yml

...but it's for a transient cloud node. That needs to be scrapped and re-done as a persistent cloud node.

On '''the code side''', there's a kerberose-based RemoteUser middleware thing in place in pdc by default. We can't use that since we don't use kerberos, but there '''is''' a SAML plugin.. and we have ipsilon, and ipsilon can talk SAML. puiterwijk says this should "just work". https://gist.github.com/sochotnicky/ba25960a16d85e04da4a

There's also already a fedmsg publication plugin ''in'' the pdc code. We should just have to turn it on to get stuff working there.

Replying to [comment:7 ralph]:

There's also already a fedmsg publication plugin ''in'' the pdc code. We should just have to turn it on to get stuff working there.

Just a note here: while messaging should generally work the only place where we actually send messages are compose additions/changes. We are planning to have a look at either a more generic way to send messages about everything happening or perhaps a bit better - manually pepper the code with sensible messages to be sent at appropriate times.

edit: And if RCM has specific requirements wrt messages being sent we can look at prioritizing their implementation

Thanks to hard work from pingou and puiterwijk, this is now up and running at https://pdc.fedorainfracloud.org with saml login working.

Next we'll need to populate it with data and start playing with it.

@sochotni, we don't have any specific requirements w.r.t. messages being sent at this point, but, the more the merrier. A nice generic way to do messaging internally in a django app is "django signals" https://docs.djangoproject.com/en/1.8/topics/signals/ if that helps.

Login to comment on this ticket.

Metadata