Bug 1162717
| Summary: | Document use of "hammer import all" | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | David O'Brien <daobrien> |
| Component: | Docs Transition Guide | Assignee: | David O'Brien <daobrien> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Peter Ondrejka <pondrejk> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0.4 | CC: | adahms, daobrien, ggainey, pondrejk, xdmoon |
| Target Milestone: | Unspecified | ||
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: |
Feature:
"hammer import all" imports all objects from an export file in one operation. Currently not documented, in favour of importing object groups in required order.
Reason:
Result:
Need concept, prerequisites, justification, process, and troubleshooting for this command. Info page is seriously lacking.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-28 00:05:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1115190 | ||
|
Description
David O'Brien
2014-11-11 14:33:53 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. Grant, Can we set up a time to review this? If you're not the best contact can you recommend someone? ta I'm not a *great* contact, because I don't think I have a Sat6 instance to test against - but yeah, I'm probably the "best" contact. Ping me if/when/as you have questions. Hi Grant
First stop would be this (see Doc Text field of BZ):
Need concept, prerequisites, justification, process, and troubleshooting for this command. Info page is seriously lacking.
Concept is not hard (import everything. Finished)
The others might need more elaboration, and perhaps comparison with importing by object type ("safety"/reliability vs ease vs speed etc).
sat-perf-* seems to be still broken, but my test machine in the office here is running 6.1.3. Not sure if there are beakers or other VMs we can test this on. I'll investigate and update here.
Bumped the list to help keep this moving. Peter, Is this another candidate for the Hammer Ref Guide? Can you have a look and let me know? thanks (In reply to Peter Ondrejka from comment #13) > David, > > I think this fits best in the Transition guide, see > https://bugzilla.redhat.com/show_bug.cgi?id=1139510#c10 In the scramble last night adahms said he'd have a look at these "need-info" bugs in the etherpad and make a decision. Andrew? I agree that this content is a good candidate for the Transition Guide, where users will be most likely to use these commands. Grant, wrt this: --macro_mapping FILE Mapping of Satellite-5 config-file-macros to puppet facts Any particular reason this uses and underscore where most (all?) of the others use dashes? Is the info page wrong or is that the actual parameter? The first I can fix; the second I can't (not easily). See # hammer import all --help thanks Setting release flags, and assigning Peter as the QA contact. It is (alas) the actual parameter, and clearly a typo - doesn't even match the parameter it's passing through to, "config-file --macro-mapping. (In reply to Grant Gainey from comment #18) > It is (alas) the actual parameter, and clearly a typo - doesn't even match > the parameter it's passing through to, "config-file --macro-mapping. Raised the following for this: https://bugzilla.redhat.com/show_bug.cgi?id=1306853 Setting back to assigned to implement tech review updates. I'm curious to know about the repeated use of "fresh install" and "new install" of Sat6 when talking about hammer import. Is this a prerequisite? Is importing to a semi-configured Sat6 supported, e.g., if it already has some orgs, users, etc? Are the conditions, best practices, or similar that we should be including? thanks (In reply to David O'Brien from comment #25) > I'm curious to know about the repeated use of "fresh install" and "new > install" of Sat6 when talking about hammer import. Is this a prerequisite? > Is importing to a semi-configured Sat6 supported, e.g., if it already has > some orgs, users, etc? Are the conditions, best practices, or similar that > we should be including? > > thanks The main purpose for hammer-import, is to get an initial setup of your brand-new Sat6 instance, with as much of your old-Sat5 data as makes sense. The longer your Sat6 instance is up and running, the less likely you are to want to do things "the Sat5 way", or to need any of the Sat5 data. 'all' is even less likely to be useful past initial install. However, you can run import whenever you want. The tool tries to handle collisions, and if it can't, it logs an error and keeps soldiering on. But honestly, once you're up and running in Sat6, you're less and less likely to want to move old-data into your new system. The two applications are *different*; the longer you're running Sat6, the less useful "old way" information is. Tech review and peer review implemented. Merged and pushed. This content is now live on the Customer Portal. Closing. |