Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Modify the fedmsgs to handle multiple content types #1326

Closed
bowlofeggs opened this issue Mar 3, 2017 · 1 comment
Closed

Modify the fedmsgs to handle multiple content types #1326

bowlofeggs opened this issue Mar 3, 2017 · 1 comment
Assignees
@jeremycline
Labels
API Issues related to Bodhi's REST API Refactor Issues that are a refactor to improve maintainability for Bodhi RFE Requests for Enhancement
Milestone
Modularity support

Comments

@bowlofeggs
Copy link
Contributor

We need to redesign our fedmsgs so they can handle multiple content types.
@bowlofeggs bowlofeggs added API Issues related to Bodhi's REST API Gibson Refactor Issues that are a refactor to improve maintainability for Bodhi RFE Requests for Enhancement labels Mar 3, 2017
@bowlofeggs bowlofeggs added this to the Multi-type support (Bodhi 3.0.0?) milestone Mar 3, 2017
@lmacken lmacken mentioned this issue Mar 3, 2017
Closed
10 tasks
@jeremycline jeremycline self-assigned this May 5, 2017
ralphbean added a commit to ralphbean/bodhi that referenced this issue May 24, 2017
@ralphbean
Support non-rpm content (modules) in the API.
e7e4c29 
This should fix fedora-infra#1325 and fedora-infra#1326.

As mentioned in fedora-infra#1325, this:

- Expands the GET api to return the `content_type` of a given update.
- Expands the search api to allow filtering on the `content_type` of updates.
- Enhances the submission api to *infer* the content_type from the given NVR,
  which should have minimal impact on users.

To this last point, we have to add an additional call to koji during module
submission to get the `extra` info back from the `koji.getBuild()` API.
Certain markers live in that block that can help us figure out what kind of
build this is.  Containers built in OSBS and Modules from the MBS will have
identifying keys there.

The code should have full coverage.  I introduced some unit tests of new
functions and methods I added and I also tested full request/reply paths
through the affected cornice services.
@ralphbean ralphbean mentioned this issue May 24, 2017
Merged
ralphbean added a commit to ralphbean/bodhi that referenced this issue May 30, 2017
@ralphbean
Support non-rpm content (modules) in the API.
ec9539f 
This should fix fedora-infra#1325 and fedora-infra#1326.

As mentioned in fedora-infra#1325, this:

- Expands the GET api to return the `content_type` of a given update.
- Expands the search api to allow filtering on the `content_type` of updates.
- Enhances the submission api to *infer* the content_type from the given NVR,
  which should have minimal impact on users.

To this last point, we have to add an additional call to koji during module
submission to get the `extra` info back from the `koji.getBuild()` API.
Certain markers live in that block that can help us figure out what kind of
build this is.  Containers built in OSBS and Modules from the MBS will have
identifying keys there.

The code should have full coverage.  I introduced some unit tests of new
functions and methods I added and I also tested full request/reply paths
through the affected cornice services.
ralphbean added a commit to ralphbean/bodhi that referenced this issue May 30, 2017
@ralphbean
Support non-rpm content (modules) in the API.
4efdad5 
This should fix fedora-infra#1325 and fedora-infra#1326.

As mentioned in fedora-infra#1325, this:

- Expands the GET api to return the `content_type` of a given update.
- Expands the search api to allow filtering on the `content_type` of updates.
- Enhances the submission api to *infer* the content_type from the given NVR,
  which should have minimal impact on users.

To this last point, we have to add an additional call to koji during module
submission to get the `extra` info back from the `koji.getBuild()` API.
Certain markers live in that block that can help us figure out what kind of
build this is.  Containers built in OSBS and Modules from the MBS will have
identifying keys there.

The code should have full coverage.  I introduced some unit tests of new
functions and methods I added and I also tested full request/reply paths
through the affected cornice services.
@ralphbean
Copy link
Contributor

I think this is fixed by #1543.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jeremycline jeremycline

Labels
API Issues related to Bodhi's REST API Refactor Issues that are a refactor to improve maintainability for Bodhi RFE Requests for Enhancement
Projects
None yet
Milestone
Modularity support
Development

No branches or pull requests
3 participants
@ralphbean @bowlofeggs @jeremycline