Project

Profile

Help

Issue #1785

closed

Repository applicability generation does not seem to generate applicability for bound clients

Added by jsherril@redhat.com about 8 years ago. Updated almost 4 years ago.

Status:
CLOSED - WONTFIX
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
2.8.0
Platform Release:
OS:
CentOS 7
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

Steps to reproduce:

1. Register a consumer
2. Create a repo with an upstream feed that contains errata that would be applicable to the consumer
3. Bind consumer to created repo
4. Sync repository
5. Generate applicability for repository using instructions:

'Generate Content Applicability for Updated Repositories' from http://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/consumer/applicability.html

We are using:

'criteria'  = {
  'parallel' => false,
  'repo_criteria' => { 'filters' => { 'id' => { '$in' => ['repo_id'] } } }
}

6. Once applicability generation is complete fetch applicability for consumer

I would expect that I would see applicable errata, but I do not. If i immediately issue an applicability regeneration for single consumer, that seems to work fine and I get the expected results. This tells me that something may be wrong with the repo applicability generation task.

Actions #1

Updated by jsherril@redhat.com about 8 years ago

  • Description updated (diff)
Actions #2

Updated by mhrivnak about 8 years ago

Maybe this is related to us changing the field name under the hood from "id" to "repo_id". We're supposed to be catching that and translating it at the API boundaries, but maybe we missed this spot.

As an experiment, you could try this and see if it works:

'criteria'  = {
          'parallel' => false,
          'repo_criteria' => { 'filters' => { 'repo_id' => { '$in' => ['myrepo'] } } }
        }
Actions #3

Updated by jsherril@redhat.com about 8 years ago

changing it to:

post https://robot.example.com/pulp/api/v2/repositories/actions/content/regenerate_applicability//, {"parallel":false,"repo_criteria":{"filters":{"repo_id":{"$in":["Default_Organization-need-needed2"]}}}}

didn't seem to have any change

Actions #4

Updated by jsherril@redhat.com about 8 years ago

The call i'm using to check errata applicability for my consumer:

post https://robot.example.com/pulp/api/v2/consumers/content/applicability/, {"criteria":{"filters":{"id":{"$in":["fba13782-66df-4c70-9c06-019760bceac8"]}}}

I think this call is fine, as the same call made after:

post https://robot.example.com/pulp/api/v2/consumers/actions/content/regenerate_applicability//, {"consumer_criteria":{"filters":{"id":{"$in":["fba13782-66df-4c70-9c06-019760bceac8"]}}}}

shows errata ids

Actions #5

Updated by dkliban@redhat.com about 8 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com
  • Platform Release set to 2.8.1
Actions #6

Updated by ttereshc about 8 years ago

I think it does not work because of the missing applicability for the consumer.
In the docs there is a note about it:

Only existing applicability data is regenerated for given repositories.
If applicability data for a consumer-repository combination does not already exist, it should be generated using the API Generate Content Applicability for Updated Consumers.

So instead of step 5 I suggest to do the following:
- generate applicability for the consumer
- change something in the repository which will be applicable to the consumer
- generate applicability for updated repository

Actions #7

Updated by jsherril@redhat.com about 8 years ago

I did not realize this was required, but yes we are indeed generating it for a consumer at:

  • Package profile upload time
  • Repo binding time

Here's a query prior to syncing the repo (consumer id has changed from previous comments):

Post "https://robot.example.com/pulp/api/v2/consumers/content/applicability/", {"criteria":{"filters":{"id":{"$in":["2ab153d1-3ae6-43bc-bbd6-57cb3b88e139"]}}}

 => [] 

So the profile exists, but is empty. I think that should be okay?

Actions #8

Updated by ttereshc about 8 years ago

It means that there is no applicability profile for the specified consumer.
If profile exists and there is nothing applicable for the consumer, you will see this:

[{"applicability": {"rpm": [], "erratum": []}, "consumers": ["your_consumer_id"]}]

I am not sure if the applicability profile will be created for the consumer if it is bound only to the empty repo...

Actions #9

Updated by dkliban@redhat.com about 8 years ago

Regenarating applicability for a consumer bound to an empty repository will not produce a repo_applicability_profile because there is nothing in the repository. The comments[0] in our code even hint at this.

[0] https://github.com/pulp/pulp/blob/master/server/pulp/server/managers/consumer/applicability.py#L238

Actions #10

Updated by semyers about 8 years ago

  • Platform Release changed from 2.8.1 to 2.8.2
Actions #11

Updated by mhrivnak about 8 years ago

  • Status changed from ASSIGNED to NEW
  • Assignee deleted (dkliban@redhat.com)
  • Platform Release deleted (2.8.2)
  • Triaged changed from No to Yes
Actions #12

Updated by mhrivnak almost 8 years ago

IRC discussion in #pulp-dev on May 25 2016.

<jsherrill> partha:  https://pulp.plan.io/issues/1785
<pulpbot> Title: Issue #1785: Repository applicability generation does not seem to generate applicability for bound clients - Pulp (at pulp.plan.io)
<partha> jsherrill: wow ..
<jsherrill> partha: yeah, basically applicability generation at the repo level only works if there is already applicability for the client
* mhrivnak looks at #1785
<mhrivnak> partha, jsherrill so is this a pulp bug? Or a miscommunication about how applicability is supposed to work?
<jsherrill> mhrivnak: well we've talked about #1785 before and agreed it was a pulp bug
<jsherrill> but isn't really blocking what partha is doing, i just forgot again about that bug
<mhrivnak> jsherrill, ok. The last comment doesn't make that clear, so we can clarify it now.
<jsherrill> and thought it was related to partha's task group work
<jsherrill> kk
<mhrivnak> What change do you think is required?
<jsherrill> mhrivnak: you mean for #1785?
<mhrivnak> jsherrill, yep
<mhrivnak> dkliban, any thoughts on 1785?
<jsherrill> mhrivnak: that applicability is calculated for all bound consumers regardless of if any applicability already exists
<mhrivnak> Ok. So is the problem that you 1) register a consumer 2) bind it to a repo 3) generate applicability for the repo
<mhrivnak> and the expectation is that pulp creates applicability for the consumer, but in reality pulp does not?
<jsherrill> mhrivnak: correct
<mhrivnak> gotcha, that makes sense.
<mhrivnak> I'm seeing reference in the bug to an "empty repo". Any idea how that factors in?
<mhrivnak> Or is that unrelated info?
<jsherrill> mhrivnak: in katello thats likely the only way we can reproduce
<jsherrill> as we generate an applicability generation event when we bind the repo to the consumer
<jsherrill> which adds the profile
<mhrivnak> jsherrill, gotcha. Have any guidance on prioritization?
<mhrivnak> Attaching a BZ to it might help.
<jsherrill> mhrivnak: yeah i didn't file a bz because no users/customers have complained
<jsherrill> its more confusing for developers and may inhibit us from making performance improvements on this in the future
<jsherrill> as right now we kickoff applicability generation all the time
<dkliban> jsherrill: so the issue is that the repository has not been synced when the applicability is being calculate
<dkliban> d
<jsherrill> dkliban: when it was calculated for teh consumer yes, but then we sync it and calculate it for the repo
<dkliban> jsherrill: the problem is that if the repo had not been synced there will  be no RepoProfileApplicability created for the consumer. so when you go to calculate it for the repo there will be nothing calculated because it doesn't think the consumer had anything relavent installed on it at all
<dkliban> jsherrill: are only devs hitting this?
<jsherrill> dkliban: right that was the problem ;)
<mhrivnak> dkliban, do you think pulp should just create an empty applicability record in that case?
<dkliban> mhrivnak: i guess.  but i think it's strange to bind a consumer to an empty repository
<mhrivnak> Well, if you're adding a repo to a system, it might make sense to create the repo, bind a bunch of consumers, initiate a sync, and go to lunch.
<mhrivnak> Although presumably you'd not want to generate applicability until after the sync I suppose.
<jsherrill> dkliban: it seems weirder to me to request applicability generation for a repo and not have its consumers get their applicability generated :)
<dkliban> mhrivnak: the change needs to happen here https://github.com/pulp/pulp/blob/master/server/pulp/server/managers/consumer/applicability.py#L238
<pulpbot> Title: pulp/applicability.py at master · pulp/pulp · GitHub (at github.com)
<bmbouter> jsherrill: I agree
<ttereshc> dkliban, mhrivnak, right now applicability is generated for the particular content types and if the repo is empty we do not know what kind of units it contains... just a thought
<mhrivnak> ttereshc, good point.
Actions #13

Updated by dkliban@redhat.com about 7 years ago

  • Sprint/Milestone set to 32

I discussed this issue with jsherrill from Katello and he said that there is not a specific work around for this problem. Katello just tries to regerate applicability very often and the profile is eventually generated. His concern is that if they try to reduce the number of times they calculate applicability in the future, this will become a much bigger problem. We should go ahead and fix this issue now.

Actions #14

Updated by mhrivnak about 7 years ago

  • Sprint/Milestone changed from 32 to 33
Actions #15

Updated by dkliban@redhat.com about 7 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com
Actions #16

Updated by mhrivnak about 7 years ago

  • Sprint/Milestone changed from 33 to 34
Actions #19

Updated by dkliban@redhat.com about 7 years ago

  • Status changed from ASSIGNED to NEW
  • Sprint/Milestone deleted (34)

This change is needed so that Katello can change their workflow. At this time Katello has no plan to change their workflow around this issue. We should consider doing this work once Katello has a plan in place.

Actions #20

Updated by dkliban@redhat.com about 7 years ago

  • Assignee deleted (dkliban@redhat.com)
Actions #21

Updated by bmbouter almost 5 years ago

  • Status changed from NEW to CLOSED - WONTFIX
Actions #22

Updated by bmbouter almost 5 years ago

Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.

Actions #23

Updated by bmbouter almost 5 years ago

  • Tags Pulp 2 added
Actions #24

Updated by bmbouter almost 4 years ago

  • Category deleted (14)

We are removing the 'API' category per open floor discussion June 16, 2020.

Also available in: Atom PDF