Project

General

Profile

Actions

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:
Category:
Hosts
Target version:
Difficulty:
medium
Triaged:
Yes
Fixed in Releases:
Found in Releases:

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 #1

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 #2

Updated by Eric Helms almost 10 years ago

  • Translation missing: en.field_release changed from 14 to 23
Actions #3

Updated by Eric Helms almost 10 years ago

  • Translation missing: en.field_release changed from 23 to 14
Actions #4

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 #5

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 #6

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

Updated by Eric Helms almost 10 years ago

  • Assignee set to Eric Helms
  • Target version set to 63
Actions #8

Updated by The Foreman Bot almost 10 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/Katello/katello/pull/4929 added
  • Pull request deleted ()
Actions #9

Updated by Eric Helms almost 10 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF