product-definition-center / product-definition-center

Repository and API for storing and querying product metadata

Product Definition Center

Documentation

See also:

• PDC Client – CLI utility for accessing PDC

product-definition-center's Issues

Put documentation on rtfd.org

It looks like you have a nice docs/ directory.

It could be nice if you have it automatically rebuilt and displayed on readthedocs.org

Allow to reset SLA EOL dates to their default value

In Fedora we allow maintainers to retire branches of packages. This means that the EOL date for the branches is set to the current date. It might happen that the branch needs to be unretired at a later point when a new maintainer arrives. Currently the tools to do this need to keep a list of the standard EOLs for all branches and reset the respective SLAs. When #459 is implemented, it would be great to just have an API method in PDC to reset the SLAs to their respective default values so the code is only at a central place instead of different clients.

package in what image

Hello,

• is there a way to find out what images contain a specific package without the need to manually examine the content of images?
• does pdc even keep track of that?

For example:

• latest docker image for fc24 is Fedora-Cloud-Base-24_Beta-1.6.x86_64.raw.xz
• this tells me something about the image
  • itself: https://pdc.fedoraproject.org/rest_api/v1/images/?file_name=Fedora-Cloud-Base-24_Beta-1.6.x86_64.raw.xz
  • I found out it is based on compose Fedora-24-20160504.0
• then this endpoint tells me what all images were created from this compose:
  • https://pdc.fedoraproject.org/rest_api/v1/compose-images/Fedora-24-20160504.0/
• then I though that I might get somehow what packages are in this compose:
  • https://pdc.fedoraproject.org/rest_api/v1/compose-rpms/Fedora-24-20160504.0/

The endpoint compose-rpms still does not tell me if an rpm is bundled in the docker image or not. I suppose that docker image contains just a subset of rpms than that are in the compose.

Is there any better than compose-rpms?

Thanks

UUID? where name? should go when logged in

When I logged in to pdc, I get, what looks like, a UUID in the top right corner where I would expect something like my username or real name.

Document how to configure when behind a reverse proxy

We have pdc now deployed in our production environment.. and it is set up behind a reverse proxy (with haproxy inbetween). We had to do some ugly stuff to get mod_auth_mellon to sign its requests correctly (with ServerName and UseCanonicalName).. and somewhere along the way we confused the PDC django app so that the links in its documentation point to the haproxy address, not the X headers that come from the reverseproxy. See the links on this page for an example.

• https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/pdc/frontend/templates/pdc.conf
• https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/pdc/frontend/templates/settings_local.py

Low priority, I think.

Link to PDC documentation doesn't work

On PDC page here, there is a link to PDC documentation which points to https://pdc.fedoraproject.org/docs/, but this URL gives me 404.

400 error when trying to import compose

This is one of two separate, but perhaps related tickets.

When trying to import some of our recent Fedora composes, I get the following error:

[2016-02-29 15:01:30][pdcupdater.handlers.compose   ERROR]
    Failed to import
    u'http://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160226.n.0'
    u'https://pdc.fedoraproject.org/rest_api/v1/compose-images/'
    u'{"detail":["This field cannot be null."]}'
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/pdcupdater/handlers/compose.py", line 76, in initialize
    self._import_compose(pdc, compose_id, url)
  File "/usr/lib/python2.7/site-packages/pdcupdater/handlers/compose.py", line 128, in _import_compose
    image_manifest=images,
  File "<string>", line 1, in <lambda>
  File "/usr/lib/python2.7/site-packages/beanbag/namespace.py", line 131, in fn
    *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/beanbag/url_v1.py", line 102, in call
    return self.make_request(path, verb, kwargs, body)
  File "/usr/lib/python2.7/site-packages/beanbag/url_v1.py", line 155, in make_request
    "Bad response code: %d" % (r.status_code,))
BeanBagException: Bad response code: 400

You can see the URLs there for the compose metadata. Is there something wrong with the metadata of http://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160226.n.0 itself? Or is there something wrong with PDC's handling of that?

The error message is not very helpful. "This field cannot be null" Which field should not be null?

Please let me know if I can provide any other info.

Long queries to GET endpoints?

Hi, in fedora-infra/pdc-updater#15 we end up making very long GET requests to the release-component-relationships endpoint. So long that we end up getting a HTTP 414 error error in response.

This is because we want to find all of the relationships from many components in one query, so we specify from_component_name=foo1&from_component_name=foo2&from_component_name=foo3&from_component_name=foo4&...

We have a workaround, but it is hacky.

• Do you have a recommended way of making long queries like this?
• If we could do a POST instead of a GET, we could encode our query differently and get around the URI length limit. But POST means something different from GET. Is there a different http verb we could use?

Unable to delete a compose

I'm trying to delete a compose that was imported improperly (and then I'll re-import it aftewards).

I tried:

curl -X DELETE -H "Content-Type: application/json" https://pdc.fedoraproject.org/rest_api/v1/composes/299/  -H "Authorization: Token $TOKEN"

but I get back

{"detail":"Not found."}

So... something is not found, but it is not clear what is not found. Is it the compose? That definitely exists. Is it some association? Which one?

Query for components by component group?

I'm looking for a way to query for all of the components in a component group, but I haven't been able to find it.

• The component groups list returns all of the groups (or just one), but it doesn't include the list of components in each group. Just the group name. https://pdc.fedorainfracloud.org/rest_api/v1/component-groups/
• Looking at individual release components doesn't seem to return information about what groups they're a part of: https://pdc.fedorainfracloud.org/rest_api/v1/release-components/

Related - how do you add/remove release components (or global components) to a group?

API 404s if trailing slash is omitted from URL

Try this:

https://pdc.fedoraproject.org/rest_api/v1/compose-images/Fedora-26-20170705.0

Then try this:

https://pdc.fedoraproject.org/rest_api/v1/compose-images/Fedora-26-20170705.0/

That's pretty unhelpful! Also, I'm pretty sure it changed at some point, and PDC used to gracefully handle URLs with the trailing / omitted, because the code I wrote that's running into this issue has not changed since I wrote it (and thus never should have worked, if URLs without the trailing / had never worked).

Allow to store default SLA EOL dates

In Fedora we have default or standard EOL dates for SLAs for standard branches. Currently they are hardcoded in a python tool:
https://pagure.io/fedrepo_req/blob/master/f/fedrepo_req/__init__.py#_28

Since they are configuration related to the products it would be better to configure them at a central place such as PDC. Therefore please consider adding the abbility to manage default EOL dates for SLAs.

404 error when trying to import compose

This is related to #289 (I think). When trying to import some composes, we get a 404 error, like this:

[2016-02-29 15:00:23][pdcupdater.handlers.compose   ERROR] Failed to import
    u'http://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160228.n.0'
    u'https://pdc.fedoraproject.org/rest_api/v1/compose-images/'
    u'{"detail":"Not found"}'
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/pdcupdater/handlers/compose.py", line 76, in initialize
    self._import_compose(pdc, compose_id, url)
  File "/usr/lib/python2.7/site-packages/pdcupdater/handlers/compose.py", line 128, in _import_compose
    image_manifest=images,
  File "<string>", line 1, in <lambda>
  File "/usr/lib/python2.7/site-packages/beanbag/namespace.py", line 131, in fn
    *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/beanbag/url_v1.py", line 102, in call
    return self.make_request(path, verb, kwargs, body)
  File "/usr/lib/python2.7/site-packages/beanbag/url_v1.py", line 155, in make_request
    "Bad response code: %d" % (r.status_code,))
BeanBagException: Bad response code: 404

Is there something wrong with the metadata in http://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160228.n.0 ? Or is there something wrong with the way PDC is handling it. Similar to #289, the error message "Not found" is kind of cryptic. What field or entity is it unable to find?

Product versions are set to read-only

curl -u : --negotiate -H 'content-type: application/json' -X PATCH -d '{"active":"true"}' https://pdc.fedoraproject.org/rest_api/v1/product-versions/fedora-25/
{"detail":"Can not update read only fields: "active"."}

When I tried to change the state of a product version, it gave me the above error.

Can it be fixed or is there a reason why its set to read-only?

Include `subvariant` in images endpoint

Using the images API endpoint - https://pdc.fedoraproject.org/rest_api/v1/images/ - would be easier and more useful if one could query on the recently-added subvariant property. That would make it possible to quite easily do, for instance, 'find me the most recent KDE live image for Fedora 24', or whatever.

Review modularity changes

Hello!

As discussed, please take a look at the changes we are working on for modularity. We've queued them up here: https://github.com/fedora-modularity/product-definition-center/tree/modularity

Our branch is currently a little behind your master branch, because (as I mentioned) git rebase --preserve-merges doesn't really cope well with preserving feature-"bracket"-merge commits in a sensible way.

no documentation for paging

Hello, on https://pdc.fedoraproject.org/rest_api/v1/ I see no documentation for paging. I'd like to configure a different number of items returned per request and also know the upper limit if any. Retrieving some information with only the default 20 results per request is extremely slow and inefficient.

Put messaging plugins under the control of a transaction manager

OK, first I'll describe the symptom we see in Fedora:

• pungi4 finishes a compose and publishes a fedmsg message about it.
• our pdc-updater listener notices the message and pulls down the compose info and imports it into PDC
• as the compose is imported, PDC emits an org.fedoraproject.prod.pdc.compose fedmsg message, saying that it has imported a compose.
• some fedora-qa listener listens for that message, and goes to query PDC for more info about that compose.. but it fails the compose is not there! When the developers go to check later.. the compose is there. It must be a race condition.

My theory is that PDC publishes the message to its notification plugins before the DB backend has issued its COMMIT; statement.

We've noticed that this kind of failure is a pattern across many of our webapps, and we developed (what we think is) a good solution for it in Bodhi2 -- using a transaction manager. See the code, it's pretty neat!

The gist is that whenever your notification plugins are called, they should queue the message instead of sending it immediately. Only later when the DB transaction is complete, then the notification plugins should be instructed to empty their queues and send all the messages. If (for some reason) the DB transaction fails, then all the messages in the queues should be dropped (you don't want to publish a message saying "new compose is imported" when the compose was not actually imported due to some late-to-the-party exception near the end of request).

How do tokens expire?

Can you explain how this works?

If a user requests a new token every day.. do those tokens stick around forever? Are they valid forever?

Do they get automatically expired somehow? How often? Can a user request that their token have a shorter expiry?

Create copr repository for PDC

Create something that can be on http://copr.fedoraproject.org/

fedora pdc - wrong url in API list

Hello,

today I was looking at https://pdc.fedoraproject.org/rest_api/v1/ and found out that there are wrong urls to API endpoints containing localhost like this:

"arches": "http://localhost:10045/rest_api/v1/arches/",
"auth/current-user": "http://localhost:10045/rest_api/v1/auth/current-user/",
"auth/groups": "http://localhost:10045/rest_api/v1/auth/groups/",

Not sure if this issue should be reported here or not.

component dependency viewer

I think it would be great to have component dependency viewer in pdc.

Users could view dependencies graphically and quickly see what component (rpm) depends on what.

I think the following JBoss dependency viewer could be used as example: https://github.com/jasinner/jboss-dependency-viewer

Allow to query changesets by resource ID

To debug issues/changes in PDC it would be nice to be able to get a list of all changesets regarding a certain ressource. The API at
https://pdc.fedoraproject.org/rest_api/v1/changesets/

currently only allows to query by ressource name but not by ID. Therefore the only way to get all changes for a certain branch would be to get all changesets for all branches and then filter on the client by ID. It would be more efficient to just do the filtering on the server side.

virtualenv - not working "out of the box"

How to reproduce:

• create virtualenv and install dependencies

$ virtualenv env
$ source env/bin/activate
$ pip install requirements/devel.txt

• run django tests and many of them will fail because of some missing imports

$ make test

• I get failure like this:

(env)➜  product-definition-center git:(master) ✗ make test
python manage.py test --settings pdc.settings_test pdc contrib
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line
    utility.execute()
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 328, in execute
    django.setup()
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/__init__.py", line 18, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/apps/registry.py", line 108, in populate
    app_config.import_models(all_models)
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/apps/config.py", line 198, in import_models
    self.models_module = import_module(models_module_name)
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/user/Projects/product-definition-center/pdc/apps/package/models.py", line 18, in <module>
    from kobo.rpmlib import parse_nvra
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/kobo/rpmlib.py", line 15, in <module>
    import koji
ImportError: No module named koji
Makefile:21: recipe for target 'test' failed
make: *** [test] Error 1

Other notes:

• when using the option --system-site-packages I get this output::

======================================================================
ERROR: test_update_sigkey (pdc.apps.common.tests.SigKeyRESTTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/user/Projects/product-definition-center/pdc/apps/common/tests.py", line 347, in test_update_sigkey
    url = reverse('sigkey-detail', kwargs={'key_id': '1234adbf'})
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/urlresolvers.py", line 578, in reverse
    return force_text(iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args, **kwargs)))
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/urlresolvers.py", line 432, in _reverse_with_prefix
    self._populate()
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/urlresolvers.py", line 284, in _populate
    for pattern in reversed(self.url_patterns):
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/urlresolvers.py", line 401, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "/home/user/Projects/product-definition-center/env/lib/python2.7/site-packages/django/core/urlresolvers.py", line 395, in urlconf_module
    self._urlconf_module = import_module(self.urlconf_name)
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/user/Projects/product-definition-center/pdc/urls.py", line 13, in <module>
    from pdc.apps.release.views import ReleaseListView, ReleaseDetailView
  File "/home/user/Projects/product-definition-center/pdc/apps/release/views.py", line 10, in <module>
    from kobo.django.views.generic import DetailView, SearchView
ImportError: No module named django.views.generic

----------------------------------------------------------------------
Ran 1065 tests in 4.824s

FAILED (errors=978)
Destroying test database for alias 'default'...
Makefile:21: recipe for target 'test' failed
make: *** [test] Error 1

In this second case it looks like the system-wide python library kobo can't see django from virtualenv. Workaround for me was to install another copy of kobo into virtualenv. After that all django tests passed.

$ pip install --upgrade https://git.fedorahosted.org/cgit/kobo.git/snapshot/kobo-0.4.3.tar.gz#egg=kobo

Add PDC development activity to Fedora's fedmsg bus

It could be nice and it is very easy to set up.

Someone with admin rights on these github repositories simply needs to visit https://apps.fedoraproject.org/github2fedmsg and click to enable the integration there.

RFE: Unauthenticated read-only API access

It would be nice if we could access the API for read-only data without having to authenticate.

This is primarily for JS-based frontend UIs that we'd like to have query PDC for release status.

FWIW, it would also be nice for our backend services which could authenticate.. but if they're accessing PDC read-only, it would just be simpler if we didn't have to supply them some credentials.

Adding ContentFormat support to compose-tree-locations

This can be treated as a subtask to #320

Allow retrieving component-group-types by name

See https://pdc.stg.fedoraproject.org/rest_api/v1/component-group-types/#tab_retrieve

You have to specify the instance_pk to check to see if a component-group-type exists... but if you don't have that, you're out of luck. ;)

The name has to be unique anyways, so it should be possible to allow querying by it.

Improve error messages when validating compose on import

This RFE stems from the experience I had when encountering #289 and #290.

The error messages indicating that some value is not well defined.. but they do not tell you which value. It would be very helpful for debugging if they could tell you more.

details about release status

Current information about releases does not provide enough information to distinguish released releases from future and EOL releases.

In the https://pdc.fedoraproject.org/rest_api/v1/releases/*/ there could be new fields:

• status (one of "development", "released", "eol")
• release_date
• eol_date

The dates would be tentative until the event happens, and could be change over time, and should be set to the real date when the event happens.

This could be used in dnf-plugin-system-upgrade and LiveUsb Creator and similar. LUC currently gets the data from https://dl.fedoraproject.org/pub/fedora/linux/releases/ but it's rather slow (has to fetch and parse a lot of small files) and seems brittle.

@lmacken ?

automatically ingest new image types and format from productmd

productmd defines what kinds of image types and image formats there are:

https://github.com/release-engineering/productmd/blob/master/productmd/images.py

pdc also has a db table that lists what kinds of image types and image formats there are. You have to access the admin panel to add new ones. I've had to periodically go in and add new ones for our fedora instance.

It would be sweet if I didn't have to do that. Could pdc (on startup) look at the possible types and formats provided by productmd, and automatically add those to its tables?

Deps for latest copr build

The latest copr build (link) is missing some dependencies for el7 at install time, making it as yet uninstallable for fedora infrastructure:

msg: Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)
           Requires: django-mptt >= 0.7.1                                               
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: Django >= 1.8.1                                                    
           Available: python-django-1.6.11-4.el7.noarch (epel)                          
               Django = 1.6.11-4.el7                                                    
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: django-rest-framework >= 3.1                                       
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: python-django-cors-headers                                         
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: productmd                                                          
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: Django >= 1.8.1                                                    
           Installing: python-django-1.6.11-4.el7.noarch (epel)                         
               Django = 1.6.11-4.el7                                                    
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: django-rest-framework < 3.2                                        
Error: Package: python-pdc-0.3-2.23.g43e23db.el7.centos.noarch (group_pdc-pdc-test)     
           Requires: python-django-filter >= 0.9.2                                      

Some of these just need to be rebuilt from rawhide in el7. A few of them need minor spec file changes, but at least one of them (the cors-headers one) isn't in Fedora or EPEL at all.

Please avoid "SLA" in apis and elsewhere

I notice that the component branches api uses the term sla and slas. I'd like to avoid this, because as a community distribution, Fedora does not generally have SLAs in the formal sense. (See some related stuff at https://pagure.io/fedora-infrastructure/issue/6140.) Cornell University has a thing called Service Level Expectations which likely fits us better.

What about using servicelevel and servicelevels? This can represent actual SLAs where that is appropriate, and SLEs where we have that.

regexp search for global-components/

The API seems to provide no way to search for components directly.
(I mean the global-components/ endpoint does only listing (no regexps) or can retrieve a known component by name: so it can confirm a component exists and give its id effectively.)

A partial workaround is regexp search for rpms/ to find out component, and list component-branches say, etc. Searching through rpms is obviously slower and more expensive than searching components directly. I don't see any other way at least for Fedora PDC.

Invalid data for release id when trying to update a component group with PUT

At https://pdc.stg.fedoraproject.org/, I'm trying to update an existing component group with a PUT call, but am failing with this traceback:

[2016-01-25 15:35:11][pdcupdater.commands   ERROR] {"invalid_data":"fedora-24-fedora-NEXT","detail":"Not found.","id_of_invalid_data":"release"}
Traceback (most recent call last):
  File "/home/threebean/devel/pdc-updater/pdcupdater/commands.py", line 56, in initialize
    handler.initialize(pdc)
  File "/home/threebean/devel/pdc-updater/pdcupdater/handlers/atomic.py", line 84, in initialize
    self._update_atomic_component_group(pdc, component_group)
  File "/home/threebean/devel/pdc-updater/pdcupdater/handlers/atomic.py", line 94, in _update_atomic_component_group
    pdc['component-groups']._ = component_group
  File "<string>", line 1, in <lambda>
  File "/home/threebean/.virtualenvs/pdc-updater/lib/python2.7/site-packages/beanbag/namespace.py", line 149, in fn
    return basefn(getattr(self, ".base"), getattr(self, ".path"), attr, *args, **kwargs)
  File "/home/threebean/.virtualenvs/pdc-updater/lib/python2.7/site-packages/beanbag/namespace.py", line 305, in setattr
    return self._set(self._get(path, self.attr(attr)), val)
  File "/home/threebean/.virtualenvs/pdc-updater/lib/python2.7/site-packages/beanbag/namespace.py", line 301, in _set
    return self.set(path, val)
  File "/home/threebean/.virtualenvs/pdc-updater/lib/python2.7/site-packages/beanbag/url_v1.py", line 114, in set
    return self.make_request(path, "PUT", {}, val)
  File "/home/threebean/.virtualenvs/pdc-updater/lib/python2.7/site-packages/beanbag/url_v1.py", line 155, in make_request
    "Bad response code: %d" % r.status_code)
BeanBagException: Bad response code: 404

If you check some of the other endpoints, you'll see that that release_id does exist:

{
    "count": 7,
    "next": null,
    "previous": null,
    "results": [
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora EPEL",
            "product_version": null,
            "release_id": "epel-5-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "epel",
            "version": "5"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora EPEL",
            "product_version": null,
            "release_id": "epel-6-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "epel",
            "version": "6"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora EPEL",
            "product_version": null,
            "release_id": "epel-7-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "epel",
            "version": "7"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora",
            "product_version": null,
            "release_id": "fedora-21-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "fedora",
            "version": "21"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora",
            "product_version": null,
            "release_id": "fedora-22-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "fedora",
            "version": "22"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora",
            "product_version": null,
            "release_id": "fedora-23-fedora-NEXT-updates",
            "release_type": "updates",
            "short": "fedora",
            "version": "23"
        },
        {
            "active": true,
            "base_product": "fedora-NEXT",
            "bugzilla": null,
            "compose_set": [],
            "dist_git": null,
            "integrated_with": null,
            "name": "Fedora",
            "product_version": null,
            "release_id": "fedora-24-fedora-NEXT",
            "release_type": "ga",
            "short": "fedora",
            "version": "24"
        }
    ]
}

and also that the component group exists, with the correct release_id:

{
    "count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "components": [],
            "description": "Deps for atomic-docker-host https://git.fedorahosted.org/cgit/fedora-atomic.git",
            "group_type": "atomic-docker-host",
            "id": 1,
            "release": "fedora-24-fedora-NEXT"
        },
        {
            "components": [],
            "description": "Deps for atomic-docker-host https://git.fedorahosted.org/cgit/fedora-atomic.git/plain/",
            "group_type": "atomic-docker-host",
            "id": 2,
            "release": "fedora-24-fedora-NEXT"
        }
    ]
}

Any ideas on what I'm missing here? Or, is it a bug in PDC?

Ordering doesn't seem to work

I've been using REST queries that contain ordering with pdc.fedoraproject.org but no matter what I set it to it doesn't seem to work.

Example query: https://pdc.fedoraproject.org/rest_api/v1/unreleasedvariants/?active=True&variant_id=base-runtime&variant_version=f26&fields=variant_release&fields=koji_tag&ordering=-variant_release

The first one I get is 20170404161234. I would expect 20170616125558. Ordering by koji_tag or any other key I randomly tried doesn't make any difference either, so it's not just about reverse ordering. Perhaps I'm doing something wrong?

Consider support for django-1.6

django-1.6 is the version in RHEL7. As far as I can tell, PDC requires django-1.8 which makes it difficult to ship on top of RHEL7. Any idea if making it run on django-1.6 would be easy or hard?

A question about flagging composes

This is an RFE coming from Fedora release engineering.

We will create a release in PDC for the fedora-25 release and then do a number of candidate composes for it. All of them are built for and linked to the release, which is good.

The problem is that when we finally decide on which compose is going to be the good, final gold compose.. we don't have a way to mark that compose as the one in PDC.

Maybe there is already a feature that allows us to do this, but we don't see it. Can you educate us? (or take this as an RFE). :)

Thanks!

/cc @ausil

Discussion: Model ostree repos?

Does anyone have any thoughts about how to model ostree repos?

They could probably be modeled with the current tables, but, does pdc has a special way to import them (like it does with composeinfo files from pungi4/distill)?

If not, do we know of anyone talking with the rpm-ostree devs to get it integrated into pungi? or to get rpm-ostree itself producing similar .json manifest files?

Filtering unreleasedvariants for component_branch doesn't seem to work correctly

Background: https://pagure.io/releng/pull-request/6970

It seems that filtering unreleasedvariants for component_branch doesn't return the desired results.

E.g.: If I query https://pdc.fedoraproject.org/rest_api/v1/unreleasedvariants/?component_branch=master&component_name=wayland I receive 4 modules currently which should contain the desired component with the corresponding branch.

If I then query rpms directly ( https://pdc.fedoraproject.org/rest_api/v1/rpms/?name=wayland&srpm_commit_branch=master ), I don't get any records. I also tried querying srpm_name param instead of name with no luck..

ComposeTree is not well designed

There's a VariantArch model that joins variant and arch.
It represents the same entity as ComposeTree model.

ComposeTree should be removed and VariantArch re-used.

ComposeTree location, scheme, url and synced_content should be ideally moved to a new module, because clearly it's a mirror manager data than actual compose metadata.

Also synced_content points to repository.ContentCategory, but that's not sufficient.
If the data should be usable, we need to track repository.ContentFormat as well.

Investigation of moving compose-tree-locations related models to separate module

This can be treated as a subtask to #320
ComposeTree's location, scheme, url and synced_content should be ideally moved to a new module

default view of composes should be reversed in order

if you go to https://pdc.fedoraproject.org/compose/ the composes are sorted oldest first, typically when you go to that page you are looking for a recent compose. so you have to go straight to the end and page back. the default view should be the most recent composes first

No API to create composes

I see API documentation here for retrieving a list of composes, but none for creating composes:

https://pdc.fedorainfracloud.org/rest_api/v1/composes/

• Is this expected?
• Am I looking in the wrong place?
• Do we have a version of PDC in place there that is too old?

Add compose_label as a new field in the payload to the messaging plugins

Having more info in there couldn't hurt, right? People report that it would make things easier for them.

DIST_GIT_WEB_ROOT_URL option by itself has no effect

If in settings_local you only define this one option, the value will be ignored. The reason is that DIST_GIT_REPO_FORMAT is the actual option that is read, and its value is constructed before the override comes into play.

Filed in Fedora Infra: https://pagure.io/fedora-infrastructure/issue/6538

Publish a message bus event for all database changes.

It would be nice if PDC were publishing to the bus (fedmsg and the UMB) for all incoming changes.

This could probably be done cleanly with some django db hook.

PDC doesn't run with Django 1.10

I tried to run PDC from clean git clone and ended up with:
...
File "/usr/lib/python2.7/site-packages/django/init.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python2.7/site-packages/django/apps/registry.py", line 115, in populate
app_config.ready()
File "git/product-definition-center/pdc/apps/bindings/apps.py", line 15, in ready
self._extend_filters()
File "git/product-definition-center/pdc/apps/bindings/apps.py", line 26, in _extend_filters
from . import filters
File "git/product-definition-center/pdc/apps/bindings/filters.py", line 8, in
from pdc.apps.common.filters import NullableCharFilter
File "git/product-definition-center/pdc/apps/common/filters.py", line 41, in
class MultiValueFilter(django_filters.MethodFilter):
AttributeError: 'module' object has no attribute 'MethodFilter'

Display all/active/inactive releases, release versions and products

There should be a drop-down next to search field that allows user to select between all/active/inactive releases, product versions and products.
Default should be: active

Add more details to compose-images API docs

In the compose-images API docs here:

https://pdc.fedorainfracloud.org/rest_api/v1/compose-images/

It mentions that the POST to create a new compose-image entry should contain information from the composeinfo.json and image-metadata.json files. Can the docs there be expanded slightly to mention what tools are expected to produce those files? Is it distill/pungi4?