Project

General

Profile

InterServerSync » History » Version 19

Chris Duryee, 10/29/2015 01:25 PM

1 1 Chris Duryee
h1. InterServerSync
2
3 2 Chris Duryee
h3. What is ISS?
4
5
Inter-Server Sync is a feature designed to help users in two scenarios:
6
7
 * users who have a connected Foreman/Katello instance and disconnected Foreman/Katello, who want to propogate data from the connected side of their network to the disconnected side.
8
 * users who have a "main" Foreman/Katello and want to propogate some data (but not all data) to other instances. One example is for users who have "blessed" content views that are validated by the IT department, and want to propogate those down elsewhere.
9
10 5 Chris Duryee
More info is available at https://fedorahosted.org/spacewalk/wiki/InterSpacewalkServerSync.
11
12 1 Chris Duryee
h3. Goals
13
14 7 Chris Duryee
Roughly, phase 1 is the minimal "get it working" phase where we have a demoable end-to-end scenario that works via hammer. After that, we will collect feedback and move on to phase 2 which moves some of the grunt work done by hammer to the server, and adds web UI support. Phase 3 enhances the "connected" scenario, and Phase 4 will be for support of additional content types and new types of foreman/katello data.
15 1 Chris Duryee
16 10 Chris Duryee
All code, test, doc and installer changes should be merged by the end of each phase in order to keep PR size down.
17
18 1 Chris Duryee
h4. Phase 1 "get it working" goals
19
20 15 Chris Duryee
 * allow exporting and importing of products (content will land in Library)
21
 * export/import can occur via hammer, but some filesystem-level access is needed for accessing yum repo exports (remote mount, scp, http, etc)
22 1 Chris Duryee
 * only yum is supported
23
 * incremental dumps are supported
24
25 14 Chris Duryee
Note: phase 1 replaces katello-disconnected script, and solves the same problem that Spacewalk solves with Inter-Spacewalk Sync in a minimal fashion (notably, without a web UI which comes in phase 2 or the disk space usage optimization which comes in phase 3).
26 1 Chris Duryee
27 3 Chris Duryee
h4. Phase 2 "web UI and optimization" goals
28 1 Chris Duryee
29 3 Chris Duryee
 * API clean up to allow for bulk export/import with only a few server calls - this is needed for web UI support since we can't rely on hammer
30 16 Chris Duryee
 * support for import/export of products and repos via web UI
31
 * entire export is written to disk (both CSVs and repo contents), allowing for a single tarball or iso to have all data.
32 1 Chris Duryee
33 16 Chris Duryee
h4. Phase 3 "do it online and with less disk space" goals
34 1 Chris Duryee
35 6 Chris Duryee
 * stream export/import data from one Foreman/katello to another without needing to write a full export to disk
36
 * streaming must be able to be initiated from either the source or destination foreman/katello
37 16 Chris Duryee
 * allow export and import without filesystem access to machine (hammer or web ui can provide download of export and upload of import)
38 6 Chris Duryee
39
h4. Phase 4+ "rinse and repeat" goals
40 1 Chris Duryee
41
 * allow exporting and importing of other data (environments, non-library content views, etc)
42
 * support for ostree, docker, puppet content
43
44
45
h3. Phase 1 Design
46
47
There are two areas that need to be updated for phase 1. We need to allow for exporting and importing of yum repo data (including incremental updates), and we need to allow for exporting and importing of product and library CV data. The former is largely provided by Pulp, and the latter is provided by hammer-cli-csv.
48
49 12 Chris Duryee
We will need to add the Pulp export distributor on newly created yum repos. Additionally, existing repos will need to have the export distributor added in via migration (this work is currently in progress).
50 1 Chris Duryee
51 3 Chris Duryee
Phase 1 allows for hammer-cli-csv doing a lot of "grunt" work in loading the CSV data. This will need to be done server-side in later phases.
52
53
h4. Hammer design
54 1 Chris Duryee
55 19 Chris Duryee
Phase 1 uses hammer to do some of the heavy lifting. This gets addressed in phase 2.
56 1 Chris Duryee
57 15 Chris Duryee
<pre>
58
59
# export a repository to disk on the Katello server (need to do this for each repo)
60
hammer repository export --id <id>
61
62
# export products to CSV
63
hammer csv products --csv-export --csv-file products.csv 
64
65
# replace URL with on-disk location for place to sync from on destination katello
66
sed -i 's#https://repos.fedorapeople.org/#file:///mnt/imports/#g' /tmp/foo.csv
67
68
# import steps
69
70
# ensure export is available, then run
71
hammer csv products --csv-import --csv-file products.csv 
72 1 Chris Duryee
73 19 Chris Duryee
# kick off syncs for imported products
74
hammer repository synchronize --id <id>
75 15 Chris Duryee
</pre>
76
77 13 Chris Duryee
h4. API modifications
78 1 Chris Duryee
79 17 Chris Duryee
A new API call will be added to perform exports and imports, which will trigger Pulp calls to the export distributor. The export distributor will need to be added to new yum repos, and added via migration to existing repos. We may need to add additional APIs for allowing imports of incremental updates as well.
80 13 Chris Duryee
81
h4. User Stories
82
83 18 Chris Duryee
 * as a katello hammer user, I would like to be able to export yum repositories to disk with a hammer command. This includes both "full" and "incremental" export. The demoable output would be exporting and showing that there is content that can be synced by another Katello.. On-disk export location can be set in katello.yml
84 13 Chris Duryee
85 18 Chris Duryee
 * as a katello hammer user, I would like to be able to export and import product information to a CSV file via hammer, including repository information. The demoable output would be exporting products from Katello A, then importing the product to Katello B. Katellos A and B should have the same products and repos in Library.  Note: this story is the one that replaces http://www.katello.org/docs/user_guide/disconnected/index.html with new functionality, and will require a docs update
86 15 Chris Duryee
87 18 Chris Duryee
 * as a katello hammer user, I would like to ensure that date-based incremental imports import successfully, using data generated from the product CSV.
88 11 Chris Duryee
89
h3. Phase 2 Design
90
91
The main user-facing output of Phase 2 is the ability to do import/export from the web UI. An additional important feature is that data processing does not occur on the hammer client anymore. This greatly improves resiliency of the import/export process.
92
93
94 1 Chris Duryee
h4. API modifications
95 11 Chris Duryee
96 1 Chris Duryee
(need to fill in)
97
98
h4. Web UI design/mockup
99
100 11 Chris Duryee
(need to fill in)
101
102 15 Chris Duryee
h4. User Stories
103 11 Chris Duryee
104 15 Chris Duryee
 * as a hammer user, I would like product CSV creation and processing to occur server-side. Ideally, I will be able to make a call that kicks off a dynflow task to create or import the CSV. The CSV can be uploaded/downloaded, or written to disk in the export directory
105
 * as a hammer user, I would like to run a single command that performs a CSV export and writes any needed repo data to disk
106
 * as a hammer user, I would like to run a single command that performs a CSV import and reads any needed repo data from disk via repo sync. I will be able to override the sync URL (perhaps using something defined in katello.yml)  in the call so I don't have to perform a sed statement.
107
 * as a web UI user, I would like to be able to perform the same two import/export actions as above, but without hammer.
108 11 Chris Duryee
109
h3. Phase 3 Design
110
111
This phase is further optimization, focusing on the "connected" scenario where the two foreman/katello instances can talk to each other. Previous phases treated the connected scenario as being solved by the disconnected scenario, which meant that all data was written to disk and optionally transferred via scp or http.
112
113
114
h3. Phase 4 Design
115
116
Phase 4 adds additional content types and data to ISS. Detailed design will be added here after phase 2 or phase 3 is complete.