Pulp

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'] } } }
        }

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

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

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

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?

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...

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

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.

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.