Bug 1133846 - handling import config-file exceptions
Summary: handling import config-file exceptions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Transitions
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Grant Gainey
QA Contact: Lukas Pramuk
URL:
Whiteboard:
Depends On:
Blocks: stargate-GA-tracker
TreeView+ depends on / blocked
 
Reported: 2014-08-26 09:25 UTC by Tomas Lestach
Modified: 2019-09-26 14:45 UTC (History)
4 users (show)

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


Attachments (Terms of Use)

Description Tomas Lestach 2014-08-26 09:25:12 UTC
Description of problem:
Looking at 'error using "hammer import config-file"' from David O'Brien from Aug 26,2014:

# hammer import config-file --csv-file
/tmp/exports/config-files-latest.csv
Writing converted files
Building and uploading puppet modules
Caught RestClient::InternalServerError:500 Internal Server Error while
post_import
Summary
  Created 1 puppet file.
  Created 1 puppet module.

# cat /tmp/exports/config-files-latest.csv
org_id,channel_id,channel,channel_type,path,file_type,file_id,revision,is_binary,contents,delim_start,delim_end,username,groupname,filemode,symbolic_link,selinux_ctx
1,1,dobConfigChannel,normal,/tmp/test_file,file,1,1,N,"This is my
Hostname: {|rhn.system.hostname|}


Basically - importing one config file, getting one ISE 500, but reporting one puppet file (and module) was created.
This looks like we do not catch exceptions.
How many puppet files would be imported, if 10 config-files are in the csv and ISE happens when importing the 1st one?

Comment 2 Grant Gainey 2014-08-27 20:13:08 UTC
The summary message is correct - we *did* create a puppet module and a file - we just didn't *upload* them.

The config-file-to-puppet process works in two parts:

First - create (on the filesystem) a puppet-module-directory-tree per cfg-channel, and write into it one file per cfg-file, with sat5-macros suitably translated to puppet-facts. These are the 'created' numbers.

Then (assuming we don't specify --generate-only), compile the modules and (attempt to) upload them.  The exception here is happening at upload-time.

If the csv is bad, we'll create modules/files *on disk* until we get to The Bad One, at which point we will throw an ugly exception due to data not being in the shape we expected, and stop processing.

If the CSV is fine, but Sat6 doesn't like us (which is this case) - we will 'create' all the puppet modules and files, but we fail at the creation of a product or repository to put it into.

I'm not sure there's anything to fix here - what do you think?

Comment 3 Tomas Lestach 2014-08-28 15:23:43 UTC
The summary tells to the user how many entities were correctly transitioned.
I'd say, if part of the transition process fails and the entity transition isn't finished (upload failed), we shouldn't count the entity as being transitioned.

At least my understanding is, that if the puppet module upload failed, the module is not available and usable on Sat6.

Comment 4 Grant Gainey 2014-08-28 17:08:44 UTC
The config-channels/files have been turned into puppet-modules, but haven't been uploaded. They have been "created", in the puppet-context, and are sitting on the filesystem.  I'm not convinced that saying the subcommand did nothing, when it has in fact created puppet-module-structures and transitioned the files, is better than saying "Created N..."

(Note that one common (?) use-case is for customers to not *want* the puppet-modules to be auto-uploaded. The difference between sat5-cfg-file and puppet is large enough that "lay down the files and then let me finish up" is going to be common (?).  This is why "--generate-only" exists - getting as far as 'created' is as transitioned as one wants. Not sure if that impacts what we shoudl do when you asked for the modules to be uploaded, and Sat6 failed to do so, of course)

Comment 5 Tomas Lestach 2014-08-29 09:37:45 UTC
* What 'Created' within Summary is used for across all the sub-commands is to notify about number of objects created on Sat6 side. It would be good to re-use the same approach for config-file import as well.

* If I read only 'Summaries' as a user, I'll have the impression, everything went ok, when seeing the cmd output from the #Description. I think, we shall tell something about the failure in the summary (at least Uploaded: 0 puppet modeules)

* When a user runs the command without the upload, then the Summary as it's now, is ok but when the cmd is run with the upload option and the upload fails, then the cmd didn't do what was is supposed to do and the Summary should contain an information about the failure.

Comment 6 Grant Gainey 2014-08-29 19:33:05 UTC
Taught base.rb about :wrote and :failed
Taught config-file that "onto the filesystem" is :wrote, product/repo is create, and if a hammer-repo-upload invoke fails it's :failed

hammer-cli-import commits:
c1f6754f5963f824091f6304ccc2e10b65cf93d2
ac08e7286bd9aa435efc6a07bf1f54e5daf25ea5

Comment 9 Matej Kollar 2014-09-04 15:04:42 UTC
verified with rubygem-hammer_cli_import-0.10.4-1

Comment 10 Bryan Kearney 2014-09-11 12:27:45 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.