Fixes #23928 - Migrate Pulp Sync Plans #7479
Conversation
|
Issues: #23928 |
sjha4
changed the title
There was a problem hiding this comment.
@jlsherrill :
How do I add the has_one association on the foreman_tasks_recurring_logic without changing the model in Foreman task repo..If I add an activesupport concern, will it be included in the recurring logic model like other foreman related concerns in katello?
|
@sjha4 yep, exactly, just like all of these: https://github.com/Katello/katello/blob/master/lib/katello/engine.rb#L144-L161 I imagine recurring_logic would 'has_one' sync plan, and a sync plan would 'belong_to' a recurring_logic |
Right..Also, do you see any reason to add/remove products via dynflow task if we are not updating the pulp schedule anymore..I can think of bulk processing as one..If that's not the case we can move all of it to the sync_plan controller to simplify the code. |
|
@sjha4 exactly, we can simplify it quite a bit! |
sjha4
force-pushed
the
pulpSyncPlan
branch
2 times, most recently
from
2fdc289
to
afe9153
Compare
sjha4
force-pushed
the
pulpSyncPlan
branch
2 times, most recently
from
1b4fc51
to
159251e
Compare
sjha4
force-pushed
the
pulpSyncPlan
branch
2 times, most recently
from
20aba45
to
7019427
Compare
sjha4
changed the title
sjha4
force-pushed
the
pulpSyncPlan
branch
2 times, most recently
from
8707fb9
to
c0eb7f7
Compare
|
[test katello] |
sjha4
force-pushed
the
pulpSyncPlan
branch
4 times, most recently
from
7ba5e68
to
e8b62d7
Compare
|
[test katello] |
1 similar comment
|
[test katello] |
|
looks like the tests are failing because of: |
|
Aah..I looked at the webpack issue and assumed that was it..Thanks @jlsherrill 👍 |
|
Also some rubocop errors. Not sure why you're seeing webpack issues.... Maybe repushing will cause those to go away. |
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
| sync_plan.products.each do |product| | ||
| product.repos(product.library).each do |repo_k| | ||
| repo = ::Katello::Repository.find(repo_k.id) | ||
| repo.sync_schedule(nil) |
There was a problem hiding this comment.
We can't rely on this method to exist (In fact you should probably delete it). Instead i would call into runcible directly with something like:
Katello.pulp_server.extensions.repository.remove_schedules(repo.pulp_id)
There was a problem hiding this comment.
Ok..I'll go ahead and test with this:
Katello.pulp_server.extensions.repository.remove_schedules(repo.pulp_id, repo.importer_type)
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
|
Closing this and moving commits to #7625. |
|
Whenever we update the recurring logic the new recurring logic will be created (new resource) and older one cancelled (not sure it is an intended behaviour, why not update the same resource ?) If not we can delete the cancelled recurring logic on the update itself. Any thoughts? |
To do: