Bug 1116954 - Failed repository creation is not easily corrected
Summary: Failed repository creation is not easily corrected
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Management
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Justin Sherrill
QA Contact: Kedar Bidarkar
URL: http://projects.theforeman.org/issues...
Whiteboard:
: 1019458 1083126 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-07 16:57 UTC by Partha Aji
Modified: 2019-09-26 14:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-11 12:26:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
as seen from screenshot repo creation error are now stopped (116.55 KB, image/png)
2014-08-13 13:35 UTC, Kedar Bidarkar
no flags Details


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 5096 None None None 2016-04-22 15:15:23 UTC

Description Partha Aji 2014-07-07 16:57:26 UTC
When trying to create a repository, if an error occurs due to some user error the dynflow process cannot be corrected. 

For example:

Create a puppet repo with a feed url starting with 'https'


The repository creation process will start but the dynflow task will fail when it tries to create it in pulp.  Since the user cannot re-submit the task and update the feed url, he is forced to go into the rails console and delete the repository.

Comment 1 Partha Aji 2014-07-07 16:57:27 UTC
Created from redmine issue http://projects.theforeman.org/issues/5096

Comment 2 Partha Aji 2014-07-07 16:57:28 UTC
Upstream bug assigned to jsherril@redhat.com

Comment 4 Eric Helms 2014-07-07 19:31:36 UTC
Workaround:

yum install ruby193-rubygem-minitest -y
foreman-rake console
User.current = User.first
repo = Katello::Repository.where(:name => <name of repo that broke things>).first
repo.destroy!

Comment 5 Corey Welton 2014-07-22 18:20:59 UTC
Test notes: see example in initial report.

Perhaps we can get some more examples of what might trigger this?

Comment 6 Justin Sherrill 2014-07-22 18:32:20 UTC
The initial report actually no longer triggers the issue.  New reproducer:

try to create a puppet repo with feed of:

  ftp://hostname.com/path



Try to create a yum repo with path of:

   file://path/to/somewhere

Comment 7 Bryan Kearney 2014-07-23 16:03:49 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/5096 has been closed
-------------
Justin Sherrill
Applied in changeset commit:katello|8c67ff5324b9713e34cb09ef46b011a6b34c9f39.

Comment 9 Mike McCune 2014-08-07 01:03:20 UTC
*** Bug 1019458 has been marked as a duplicate of this bug. ***

Comment 10 Justin Sherrill 2014-08-07 14:54:01 UTC
*** Bug 1083126 has been marked as a duplicate of this bug. ***

Comment 11 Kedar Bidarkar 2014-08-13 11:36:33 UTC
tested with the below procedure.

1) file://root/repos1
repo_type: yum

repo creation was successful and no dynflow tasks visible.

2) http://<hostnam>/rhel65
repo_type: puppet

repo creation was successful and no dynflow tasks visible.

3) ftp://<hostname>/rhel65
repo_type: puppet

UI clearly says link as invalid as I have no ftp servername with that and I was using a dummy name.

no dynflow tasks are visible.

I feel I am unable to reproduce this, can some suggest other ways?

Comment 12 Kedar Bidarkar 2014-08-13 13:35:27 UTC
Created attachment 926440 [details]
as seen from screenshot repo creation error are now stopped

Comment 13 Kedar Bidarkar 2014-08-13 13:41:03 UTC
<jsherrill> kbidarka: how are you checking?  the dynflow tasks will be failed but will no longer 'hang around' and block you from trying again
<jsherrill> kbidarka: i think the fact that you can't reproduce means its fixed :)
<kbidarka> I accessed foreman_tasks/dynflow , but don't see any failed dynflow tasks 
<kbidarka> jsherrill, ok, in that case will mark it as VERIFIED then 

<jsherrill> kbidarka: in foreman_tasks/dynflow  tick the 'stopped' button at the top
<jsherrill> and click filter
<jsherrill> you'll see them there
<jsherrill> kbidarka: the fact that they were not 'stopped' was a problem :)

I was able to reproduce this but it difficult to interpret, until followed as explained above.

a) I selected stopped and then filter 
b) I see the repo creation error , but which went in stopped state automatically, as seen from the screenshot.

Tested with: sat6-GA-snap4


Installed Packages

    candlepin-0.9.19-1.el6_5.noarch
    candlepin-scl-1-5.el6_4.noarch
    candlepin-scl-quartz-2.1.5-5.el6_4.noarch
    candlepin-scl-rhino-1.7R3-1.el6_4.noarch
    candlepin-scl-runtime-1-5.el6_4.noarch
    candlepin-selinux-0.9.19-1.el6_5.noarch
    candlepin-tomcat6-0.9.19-1.el6_5.noarch
    createrepo-0.9.9-21.2.pulp.el6sat.noarch
    elasticsearch-0.90.10-4.el6sat.noarch
    katello-1.5.0-28.el6sat.noarch
    katello-ca-1.0-1.noarch
    katello-certs-tools-1.5.6-1.el6sat.noarch
    katello-installer-0.0.57-1.el6sat.noarch
    m2crypto-0.21.1.pulp-10.el6sat.x86_64
    mod_wsgi-3.4-1.pulp.el6sat.x86_64
    pulp-katello-0.3-3.el6sat.noarch
    pulp-nodes-common-2.4.0-0.30.beta.el6sat.noarch
    pulp-nodes-parent-2.4.0-0.30.beta.el6sat.noarch
    pulp-puppet-plugins-2.4.0-0.30.beta.el6sat.noarch
    pulp-puppet-tools-2.4.0-0.30.beta.el6sat.noarch
    pulp-rpm-plugins-2.4.0-0.30.beta.el6sat.noarch
    pulp-selinux-2.4.0-0.30.beta.el6sat.noarch
    pulp-server-2.4.0-0.30.beta.el6sat.noarch
    python-gofer-qpid-1.3.0-1.el6sat.noarch
    python-isodate-0.5.0-1.pulp.el6sat.noarch
    python-kombu-3.0.15-12.pulp.el6sat.noarch
    python-pulp-bindings-2.4.0-0.30.beta.el6sat.noarch
    python-pulp-common-2.4.0-0.30.beta.el6sat.noarch
    python-pulp-puppet-common-2.4.0-0.30.beta.el6sat.noarch
    python-pulp-rpm-common-2.4.0-0.30.beta.el6sat.noarch
    python-qpid-0.22-14.el6sat.noarch
    python-qpid-qmf-0.22-33.el6.x86_64
    qpid-cpp-client-0.22-42.el6.x86_64
    qpid-cpp-server-0.22-42.el6.x86_64
    qpid-cpp-server-linearstore-0.22-42.el6.x86_64
    qpid-java-client-0.22-6.el6.noarch
    qpid-java-common-0.22-6.el6.noarch
    qpid-proton-c-0.7-1.el6.x86_64
    qpid-qmf-0.22-33.el6.x86_64
    qpid-tools-0.22-12.el6.noarch
    ruby193-rubygem-katello-1.5.0-78.el6sat.noarch
    rubygem-hammer_cli_katello-0.0.4-10.el6sat.noarch

Comment 14 Bryan Kearney 2014-09-11 12:26:35 UTC
This was delivered with Satellite 6.0 which was released on 10 September 2014.


Note You need to log in before you can comment on or make changes to this bug.