Bug #7755
closed
Creating repos with same label in different products fails during synchronization
Added by Tony Coffman almost 10 years ago. Updated about 6 years ago.
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
Updated by Justin Sherrill almost 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
Updated by Eric Helms over 9 years ago
- Translation missing: en.field_release changed from 14 to 23
Updated by Eric Helms over 9 years ago
- Translation missing: en.field_release changed from 23 to 14
Updated by Ashton Davis over 9 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.
Updated by Ashton Davis over 9 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
Updated by Ashton Davis over 9 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
Updated by Eric Helms over 9 years ago
- Assignee set to Eric Helms
- Target version set to 63
Updated by The Foreman Bot over 9 years ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/Katello/katello/pull/4929 added
- Pull request deleted (
)
Updated by Eric Helms over 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset katello|05c49d0577cc9fd4c4ddc54387060d897977a938.