Creating repos with same label in different products fails during synchronization
Creating two repositories with the same label but under different products results in an error when the second repository is synchronized.
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken
Fixes #7755: Use product label to make media unique.
Prior to, if two repositories within the same organization had the same
label (since repository labels are unique within a product) then the
subsequent repositories would fail to sync. This failure to sync resulted
in trying to create installation media with the same name which used only
the repository label. This change uses the products label as well since that
should be unique within an organization.
#1 Updated by Justin Sherrill over 5 years ago
- Category set to 83
- Legacy Backlogs Release (now unused) 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
#4 Updated by Ashton Davis about 5 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.
#5 Updated by Ashton Davis about 5 years ago
#6 Updated by Ashton Davis about 5 years ago
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