See also:
- PDC Client – CLI utility for accessing PDC
Repository and API for storing and querying product metadata
License: MIT License
See also:
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?
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?
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.
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..
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
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.
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.
Related - how do you add/remove release components (or global components) to a group?
I see API documentation here for retrieving a list of composes, but none for creating composes:
https://pdc.fedorainfracloud.org/rest_api/v1/composes/
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.
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
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.
Low priority, I think.
OK, first I'll describe the symptom we see in Fedora:
org.fedoraproject.prod.pdc.compose
fedmsg message, saying that it has imported a compose.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).
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.
How to reproduce:
$ virtualenv env
$ source env/bin/activate
$ pip install requirements/devel.txt
$ make test
(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:
--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
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.
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.
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
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?
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?
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?
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.
Hello,
For example:
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
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.
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.
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.
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?
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.
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.
This can be treated as a subtask to #320
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.
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?
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.
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
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?
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?
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).
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.
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
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:
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 ?
Having more info in there couldn't hurt, right? People report that it would make things easier for them.
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?
It looks like you have a nice docs/ directory.
It could be nice if you have it automatically rebuilt and displayed on readthedocs.org
Create something that can be on http://copr.fedoraproject.org/
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.
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
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.
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.
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.
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'
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.