Bug #7755: Creating repos with same label in different products fails during synchronization - Katello - Foreman

Actions

Copy link

Bug #7755

closed

Creating repos with same label in different products fails during synchronization

Added by Tony Coffman about 10 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Eric Helms

Category:

Hosts

Target version:

Katello 2.1

Difficulty:

medium

Triaged:

Yes

Bugzilla link:

Pull request:

https://github.com/Katello/katello/pull/4929

Fixed in Releases:

Found in Releases:

Red Hat JIRA:

Description

Creating two repositories with the same label but under different products results in an error when the second repository is synchronized.

Exception:
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken

Actions

Copy link

Updated by Justin Sherrill about 10 years ago

Category set to 83
Translation missing: en.field_release set to 14
Difficulty set to medium
Triaged changed from No to Yes

The error actually occurs during install media creation, as install media creation does not take into account the product

Exception:
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken
Backtrace:
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:56:in `save!'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_methods/dirty.rb:33:in `save!'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `block in save!'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:295:in `block in with_transaction_returning_status'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in `transaction'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:293:in `with_transaction_returning_status'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `save!'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:41:in `create!'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.0.0/app/models/katello/concerns/medium_extensions.rb:53:in `find_or_create_medium'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.0.0/app/models/katello/concerns/medium_extensions.rb:35:in `update_media'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.0.0/app/lib/actions/katello/repository/update_media.rb:24:in `finalize'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/action.rb:465:in `block (2 levels) in execute_finalize'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware/stack.rb:26:in `call'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware/stack.rb:26:in `pass'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware.rb:16:in `pass'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/action/progress.rb:30:in `with_progress_calculation'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/action/progress.rb:22:in `finalize'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware/stack.rb:22:in `call'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware/stack.rb:26:in `pass'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.3/lib/dynflow/middleware.rb:16:in `pass'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.0.0/app/lib/actions/middleware/keep_locale.rb:28:in `block

Actions

Copy link

Updated by Eric Helms almost 10 years ago

Translation missing: en.field_release changed from 14 to 23

Actions

Copy link

Updated by Eric Helms almost 10 years ago

Translation missing: en.field_release changed from 23 to 14

Actions

Copy link

Updated by Ashton Davis almost 10 years ago

This issue specifically has to do with the automatic creation of installation media. There's no issue replication instruction. Here's mine.

Create two products: CentOS 5 and CentOS 6

Sync OS on both, with repo discovery (so it should create 'os x86_64' under each product)

Whichever completes sync first gets the database entry, because for installation media, product isn't factored into the database entry. The second one will fail because 'os x86_64' is already extant.

Actions

Copy link

Updated by Ashton Davis almost 10 years ago

Product: CentOS 5.11
Repo: os x86_64
URL: https://mirrors.kernel.org/centos/5.11/os/x86_64/

Product: CentOS 6.6
Repo: os x86_64
URL: http://mirrors.kernel.org/centos/6.6/os/x86_64/

Specifically, I created CentOS 6.6 first and synchronized it, then created CentOS 5.11

Actions

Copy link

Updated by Ashton Davis almost 10 years ago

Workaround:
I recreated the 'os x86_64' repo with the name 'os x86_64' but the key of '5_x86_64'. I then went to make sure the installation media worked. It did. But now the installation media list is a bit confusing, and the more OSes I add, the more confusing it will become.

So, along the same lines as the fix for the sync issue, the name the process assigns to the installation media object should reflect at least the name of the product.

Name Path Operating system family Operating Systems
SEARCH/Library/5_os_x86_64 http://lifecycle.lv.ntent.com/pulp/repos/SEARCH/Library/custom/CentOS_5_11/5_os_x86_64/ Red Hat CentOS 5.11 Delete
SEARCH/Library/os_x86_64 http://lifecycle.lv.ntent.com/pulp/repos/SEARCH/Library/custom/CentOS_6/os_x86_64/ Red Hat CentOS 6.6 Delete

Actions

Copy link