Rgw new multisite configuration » History » Version 7
Orit Wasserman, 07/01/2015 10:23 AM
1 | 1 | Yehuda Sadeh | +*RGW NEW MULTISITE CONFIG*+ |
---|---|---|---|
2 | 1 | Yehuda Sadeh | |
3 | 1 | Yehuda Sadeh | *Summary* |
4 | 1 | Yehuda Sadeh | As part of the new multi site scheme, we change the way the system is configured. |
5 | 1 | Yehuda Sadeh | |
6 | 1 | Yehuda Sadeh | *Owners* |
7 | 1 | Yehuda Sadeh | Orit Wasserman (Red Hat) |
8 | 1 | Yehuda Sadeh | Yehuda Sadeh (Red Hat) |
9 | 1 | Yehuda Sadeh | Name |
10 | 1 | Yehuda Sadeh | |
11 | 1 | Yehuda Sadeh | *Interested Parties* |
12 | 1 | Yehuda Sadeh | If you are interested in contributing to this blueprint, or want to be a "speaker" during the Summit session, list your name here. |
13 | 1 | Yehuda Sadeh | Name (Affiliation) |
14 | 1 | Yehuda Sadeh | Name (Affiliation) |
15 | 1 | Yehuda Sadeh | Name |
16 | 1 | Yehuda Sadeh | |
17 | 1 | Yehuda Sadeh | *Current Status* |
18 | 1 | Yehuda Sadeh | Worked on the design, initial implementation work. |
19 | 1 | Yehuda Sadeh | |
20 | 1 | Yehuda Sadeh | *Detailed Description* |
21 | 1 | Yehuda Sadeh | |
22 | 1 | Yehuda Sadeh | h2. Definitions |
23 | 1 | Yehuda Sadeh | |
24 | 1 | Yehuda Sadeh | A zone is a collection of pools and radosgw’s in the same cluster that serve the same data. |
25 | 1 | Yehuda Sadeh | |
26 | 1 | Yehuda Sadeh | A zone group is a collection of zones that replicate to or from each other. The zones may (or may not) span different clusters. |
27 | 1 | Yehuda Sadeh | |
28 | 1 | Yehuda Sadeh | A zone realm is a collection of zonegroups that share the same user and bucket namespace. |
29 | 1 | Yehuda Sadeh | A period is a period of time during which a given zonegroup configuration is in effect. Each period references the previous period that preceded it and will record basic metadata like the start time. During each period there may be changes to the zone and zonegroup maps; each of these changes will increment the period epoch. |
30 | 1 | Yehuda Sadeh | |
31 | 1 | Yehuda Sadeh | h2. 1. Configuration Changes |
32 | 1 | Yehuda Sadeh | |
33 | 1 | Yehuda Sadeh | h3. 1.1 Zonegroup map |
34 | 1 | Yehuda Sadeh | |
35 | 1 | Yehuda Sadeh | The zonegroup map holds a map of the entire system, and certain configurables for the different realms, zonegroups and zones. It holds the relationships between the different zonegroups and other configuration: |
36 | 1 | Yehuda Sadeh | |
37 | 1 | Yehuda Sadeh | For the period |
38 | 5 | Orit Wasserman | - uuid |
39 | 7 | Orit Wasserman | - epoch |
40 | 1 | Yehuda Sadeh | - which period preceded it |
41 | 1 | Yehuda Sadeh | - the version vector for the previous period’s metadata log |
42 | 1 | Yehuda Sadeh | - list of zonegroups |
43 | 1 | Yehuda Sadeh | - which zonegroup is the new metadata master |
44 | 1 | Yehuda Sadeh | - which zones belong to each zonegroup |
45 | 1 | Yehuda Sadeh | - which zone is master for each zonegroup |
46 | 1 | Yehuda Sadeh | |
47 | 1 | Yehuda Sadeh | For the realm |
48 | 5 | Orit Wasserman | - id, name |
49 | 1 | Yehuda Sadeh | - which zonegroup is the master for user/bucket metadata |
50 | 1 | Yehuda Sadeh | - list of zonegroups in the realm |
51 | 1 | Yehuda Sadeh | - current period |
52 | 1 | Yehuda Sadeh | |
53 | 1 | Yehuda Sadeh | For each zonegroup |
54 | 5 | Orit Wasserman | - id, name |
55 | 1 | Yehuda Sadeh | - access url[s] (for control/replication API) |
56 | 1 | Yehuda Sadeh | - existing storage policies |
57 | 1 | Yehuda Sadeh | - which zone is master for metadata |
58 | 1 | Yehuda Sadeh | - which zone(s) are master or slave for data |
59 | 1 | Yehuda Sadeh | - list of zones |
60 | 1 | Yehuda Sadeh | |
61 | 1 | Yehuda Sadeh | For each zone |
62 | 1 | Yehuda Sadeh | - id, name |
63 | 1 | Yehuda Sadeh | - access url[s] |
64 | 1 | Yehuda Sadeh | - peers |
65 | 1 | Yehuda Sadeh | |
66 | 1 | Yehuda Sadeh | There will be one zone that will be designated as the master in the master zonegroup, and will manage all user and bucket creation (metadata) and control of the zonegroup map. In order to make a change to the system configuration, a command will be sent to the url of this master and the new configuration will propagate to the rest of the system. |
67 | 1 | Yehuda Sadeh | rgw will be able to handle dynamic changes to the zonegroup and zone configuration. |
68 | 1 | Yehuda Sadeh | |
69 | 1 | Yehuda Sadeh | zonegroup map will have a version epoch that will increment after every change. |
70 | 1 | Yehuda Sadeh | |
71 | 1 | Yehuda Sadeh | <pre> |
72 | 1 | Yehuda Sadeh | .rgw.root |
73 | 1 | Yehuda Sadeh | default_realm -> $realm |
74 | 1 | Yehuda Sadeh | realm.$realm -> current period |
75 | 1 | Yehuda Sadeh | period.$realm.$uuid.$epoch -> period object |
76 | 1 | Yehuda Sadeh | period.$realm.$uuid -> latest $epoch |
77 | 1 | Yehuda Sadeh | zone.$zone -> $realm |
78 | 1 | Yehuda Sadeh | </pre> |
79 | 1 | Yehuda Sadeh | |
80 | 1 | Yehuda Sadeh | h4. multi site todo |
81 | 1 | Yehuda Sadeh | |
82 | 1 | Yehuda Sadeh | period and realm data structures |
83 | 1 | Yehuda Sadeh | APIs for pushing and pulling zone metadata |
84 | 1 | Yehuda Sadeh | rgw needs to do watch/notify or poll on the realm.$realm object, restart as needed |
85 | 1 | Yehuda Sadeh | gracefully drain requests on old backend instance; startup new one on epoch or period change |
86 | 1 | Yehuda Sadeh | |
87 | 1 | Yehuda Sadeh | h4. metadata sync todo |
88 | 1 | Yehuda Sadeh | |
89 | 1 | Yehuda Sadeh | user instance |
90 | 1 | Yehuda Sadeh | save version for every metadata object |
91 | 1 | Yehuda Sadeh | log versions for every metadata object |
92 | 1 | Yehuda Sadeh | log metadata about which period we are on, which objects are dirty/stale, rollback/rollforward state |
93 | 1 | Yehuda Sadeh | |
94 | 1 | Yehuda Sadeh | h3. 1.2 Defining a new zonegroup |
95 | 1 | Yehuda Sadeh | |
96 | 1 | Yehuda Sadeh | Currently, in order to define a new zonegroup, we need to inject a json that holds the zonegroup configuration, then we need to update the zonegroupmap, and then we need to distribute that zonegroupmap into all existing zonegroups and restart all rgws for that to take effect. I don't think this is a good scheme. |
97 | 1 | Yehuda Sadeh | |
98 | 1 | Yehuda Sadeh | A zonegroup will have a zonegroup id, and a zonegroup name. For backward compatibility, older zonegroups will have their zonegroup_id equal to their name. |
99 | 1 | Yehuda Sadeh | |
100 | 1 | Yehuda Sadeh | When setting up a new zonegroup, we'll need to specify an entry point for the 'master' zonegroup. That zonegroup will be in control of the zonegroupmap, and it will distribute the zonegroupmap updates to all zones. |
101 | 1 | Yehuda Sadeh | |
102 | 1 | Yehuda Sadeh | If the zonegroup that we set up is the first zonegroup, we'll need to specify it in the command line. We won't be able to set up a secondary zonegroups if the master has not been specified. |
103 | 1 | Yehuda Sadeh | |
104 | 1 | Yehuda Sadeh | h3. 1.3. Defining a new zone |
105 | 1 | Yehuda Sadeh | |
106 | 1 | Yehuda Sadeh | Currently, when running an rgw it does the following: |
107 | 1 | Yehuda Sadeh | |
108 | 1 | Yehuda Sadeh | Read the rgw_zone configurable, check the root pool for the configuration of this zone. If rgw_zone is not defined it will read the default zone name out of the |
109 | 1 | Yehuda Sadeh | it will create the 'default' zone, and assign it as the default. |
110 | 1 | Yehuda Sadeh | |
111 | 1 | Yehuda Sadeh | Once a zone name has been set, it cannot really be changed. The zone names are embedded in the rados object names that are created to hold the actual rgw objects. |
112 | 1 | Yehuda Sadeh | |
113 | 1 | Yehuda Sadeh | In order to support zone renaming, and more dynamic configuration we should create a logical 'zone id' that the zone name will point at. The zone id will be a string. When creating a new zone it will be auto generated, and will not be modified. For backward compatibility, older zones will have a zone_id that will match their zone name. |
114 | 1 | Yehuda Sadeh | |
115 | 1 | Yehuda Sadeh | To set up a new zone, the rgw command will include the url to the master zonegroup, and keys to access it. It will also include the name of the zonegroup this zone should reside in. If this zonegroup does not exist, it will be created (if appropriate param was passed in). The master zonegroup will create a new system user for this specific zone, and will send it back. |
116 | 1 | Yehuda Sadeh | |
117 | 1 | Yehuda Sadeh | When a new zone starts up, we'll auto-create all the rados pools that it will use. It will first need to determine whether pools already exist, and are already assigned to a different zone. The naming scheme for the pools would be something like: |
118 | 1 | Yehuda Sadeh | |
119 | 1 | Yehuda Sadeh | <pre> |
120 | 1 | Yehuda Sadeh | .{zone_id}-x-{pool-name} |
121 | 1 | Yehuda Sadeh | rgw.$zoneid.$pool |
122 | 1 | Yehuda Sadeh | .rgw - bucket -> bucketid metadata |
123 | 1 | Yehuda Sadeh | .users - user index |
124 | 1 | Yehuda Sadeh | .users.swift |
125 | 1 | Yehuda Sadeh | .users.uid |
126 | 1 | Yehuda Sadeh | .control - contains notify object |
127 | 1 | Yehuda Sadeh | .log - metadata log, which-buckets-have-changed log |
128 | 1 | Yehuda Sadeh | .gc - garbage collection |
129 | 1 | Yehuda Sadeh | .usage - sharded usage stats |
130 | 1 | Yehuda Sadeh | .bucket-index |
131 | 1 | Yehuda Sadeh | .bucket-data - bucket data |
132 | 1 | Yehuda Sadeh | .bucket-data-nonec - non-ec bucket data |
133 | 1 | Yehuda Sadeh | </pre> |
134 | 1 | Yehuda Sadeh | |
135 | 1 | Yehuda Sadeh | We want to allow the same gateway to be part of multiple zones, this will give us much more flexibility. Different zones will have different ports. |
136 | 1 | Yehuda Sadeh | |
137 | 1 | Yehuda Sadeh | h2. 1.4. Dynamic zonegroup and zone changes |
138 | 1 | Yehuda Sadeh | |
139 | 1 | Yehuda Sadeh | rgw will be able to identify changes to the zonegroupmap, and to the zone configuration. This will be done by the following: |
140 | 1 | Yehuda Sadeh | |
141 | 1 | Yehuda Sadeh | rgw will be able to restart itself with a new rados backend handler (RGWRados) after detecting that a configuration change has been made. It will finish handling existing requests, but restart all the frontend handlers with the new RGWRados config. |
142 | 1 | Yehuda Sadeh | rgw will set a specific watch/notify handler that will be used to getting updates about the zonegroupmap configuration. |
143 | 1 | Yehuda Sadeh | Upon receiving a change, the master zonegroup zone will send a message to all the different zonegroups about the new configuration change. |
144 | 1 | Yehuda Sadeh | |
145 | 1 | Yehuda Sadeh | Any synchronization activity will be dynamically re-set according to the new configuration. |
146 | 1 | Yehuda Sadeh | |
147 | 1 | Yehuda Sadeh | h2. 1.5. New RESTful apis |
148 | 1 | Yehuda Sadeh | |
149 | 1 | Yehuda Sadeh | h3. Get period information |
150 | 1 | Yehuda Sadeh | |
151 | 1 | Yehuda Sadeh | <pre> |
152 | 1 | Yehuda Sadeh | GET /admin/realm/period?[period-id=<period-id>][&epoch=<epoch>] |
153 | 1 | Yehuda Sadeh | </pre> |
154 | 1 | Yehuda Sadeh | |
155 | 1 | Yehuda Sadeh | period-id: optional |
156 | 1 | Yehuda Sadeh | epoch: optional |
157 | 1 | Yehuda Sadeh | |
158 | 1 | Yehuda Sadeh | Output: |
159 | 1 | Yehuda Sadeh | |
160 | 1 | Yehuda Sadeh | A JSON representation of the current period, or the specified period |
161 | 1 | Yehuda Sadeh | |
162 | 1 | Yehuda Sadeh | h3. 1.5.2 Request children to fetch period: |
163 | 1 | Yehuda Sadeh | |
164 | 1 | Yehuda Sadeh | <pre> |
165 | 1 | Yehuda Sadeh | POST /admin/realm/period?[period-id=<period-id>][&epoch=<epoch>] |
166 | 1 | Yehuda Sadeh | </pre> |
167 | 1 | Yehuda Sadeh | |
168 | 1 | Yehuda Sadeh | Input: |
169 | 1 | Yehuda Sadeh | |
170 | 1 | Yehuda Sadeh | period-id: optional |
171 | 1 | Yehuda Sadeh | epoch: optional |
172 | 1 | Yehuda Sadeh | |
173 | 1 | Yehuda Sadeh | A JSON representation of the current period, or the specified period |
174 | 1 | Yehuda Sadeh | |
175 | 1 | Yehuda Sadeh | h3. 1.5.3. Initialize new zone |
176 | 1 | Yehuda Sadeh | |
177 | 1 | Yehuda Sadeh | Will be sent by the config utility (probably radosgw-admin) to the master zonegroup. |
178 | 1 | Yehuda Sadeh | |
179 | 1 | Yehuda Sadeh | <pre> |
180 | 1 | Yehuda Sadeh | POST /admin/zonegroup?init-zone |
181 | 1 | Yehuda Sadeh | </pre> |
182 | 1 | Yehuda Sadeh | |
183 | 1 | Yehuda Sadeh | Input: |
184 | 1 | Yehuda Sadeh | |
185 | 1 | Yehuda Sadeh | a JSON representation of the following: |
186 | 1 | Yehuda Sadeh | |
187 | 1 | Yehuda Sadeh | * zonegroup name |
188 | 1 | Yehuda Sadeh | * zone name |
189 | 1 | Yehuda Sadeh | * list of peers (zone ids) |
190 | 1 | Yehuda Sadeh | |
191 | 1 | Yehuda Sadeh | Output: |
192 | 1 | Yehuda Sadeh | |
193 | 1 | Yehuda Sadeh | a JSON representation of the following: |
194 | 1 | Yehuda Sadeh | * metadata of user to be used by zone |
195 | 1 | Yehuda Sadeh | * new zonegroup map |
196 | 1 | Yehuda Sadeh | |
197 | 1 | Yehuda Sadeh | 1.5.4. Notify of zonegroup map change |
198 | 1 | Yehuda Sadeh | |
199 | 1 | Yehuda Sadeh | <pre> |
200 | 1 | Yehuda Sadeh | POST /admin/zonegroup?reconfigure |
201 | 1 | Yehuda Sadeh | </pre> |
202 | 1 | Yehuda Sadeh | |
203 | 1 | Yehuda Sadeh | Input: |
204 | 1 | Yehuda Sadeh | |
205 | 1 | Yehuda Sadeh | - new zonegroup map |
206 | 1 | Yehuda Sadeh | h2. 1.6. New radosgw-admin, radosgw interfaces: |
207 | 1 | Yehuda Sadeh | |
208 | 1 | Yehuda Sadeh | h3. 1.6.1 period |
209 | 1 | Yehuda Sadeh | |
210 | 1 | Yehuda Sadeh | <pre> |
211 | 4 | Orit Wasserman | $ radosgw-admin period prepare --parent=<parent> [--realm-id=<realm> --realm=<realm name>] |
212 | 1 | Yehuda Sadeh | </pre> |
213 | 1 | Yehuda Sadeh | Creating a new period object in .rgw.root pool. |
214 | 1 | Yehuda Sadeh | |
215 | 1 | Yehuda Sadeh | <pre> |
216 | 1 | Yehuda Sadeh | $ radosgw-admin period activate <uuid> |
217 | 1 | Yehuda Sadeh | </pre> |
218 | 1 | Yehuda Sadeh | Switch to a new period. |
219 | 1 | Yehuda Sadeh | must be a child of the current period |
220 | 1 | Yehuda Sadeh | The admin need to reconfigure all the gateways, at first the gateway will need to be restarted to use the new period. In the future they support dynamic configuration. |
221 | 1 | Yehuda Sadeh | |
222 | 1 | Yehuda Sadeh | <pre> |
223 | 1 | Yehuda Sadeh | $ radosgw-admin period pull |
224 | 1 | Yehuda Sadeh | </pre> |
225 | 1 | Yehuda Sadeh | pull latest period map from current period master |
226 | 1 | Yehuda Sadeh | requires that radosgw-admin uses RESTful api |
227 | 1 | Yehuda Sadeh | |
228 | 1 | Yehuda Sadeh | <pre> |
229 | 1 | Yehuda Sadeh | $ radosgw-admin period pull <remote> <uuid> [--url=<url>] |
230 | 1 | Yehuda Sadeh | </pre> |
231 | 1 | Yehuda Sadeh | url: optionally provide remote entry point |
232 | 1 | Yehuda Sadeh | Fetch info about a specific remote period |
233 | 1 | Yehuda Sadeh | |
234 | 1 | Yehuda Sadeh | <pre> |
235 | 1 | Yehuda Sadeh | $ radosgw-admin period push |
236 | 1 | Yehuda Sadeh | </pre> |
237 | 1 | Yehuda Sadeh | Ask all children to pull latest epoch |
238 | 1 | Yehuda Sadeh | |
239 | 1 | Yehuda Sadeh | We need to create a mechanism to allow the admin to communicate with other gateways. |
240 | 1 | Yehuda Sadeh | |
241 | 1 | Yehuda Sadeh | 1.6.2 zone realm |
242 | 1 | Yehuda Sadeh | |
243 | 1 | Yehuda Sadeh | <pre> |
244 | 1 | Yehuda Sadeh | $ radosgw-admin realm create --realm=<name> |
245 | 1 | Yehuda Sadeh | </pre> |
246 | 1 | Yehuda Sadeh | Create a new zone realm, implicitly creates the first period |
247 | 1 | Yehuda Sadeh | |
248 | 1 | Yehuda Sadeh | <pre> |
249 | 1 | Yehuda Sadeh | $ radosgw-admin realm remove --realm=<name> [--realm-id=<id>] --zonegroup=<name> |
250 | 1 | Yehuda Sadeh | </pre> |
251 | 1 | Yehuda Sadeh | Remove a zonegroup from a realm |
252 | 1 | Yehuda Sadeh | |
253 | 1 | Yehuda Sadeh | <pre> |
254 | 1 | Yehuda Sadeh | $ radosgw-admin realm delete --realm=<name> |
255 | 1 | Yehuda Sadeh | </pre> |
256 | 1 | Yehuda Sadeh | Delete a realm, needs to be empty |
257 | 1 | Yehuda Sadeh | |
258 | 1 | Yehuda Sadeh | <pre> |
259 | 1 | Yehuda Sadeh | $ radosgw-admin realm rename --realm=<old name> --new-realm-name =<new name> [--realm_id=<id>] |
260 | 1 | Yehuda Sadeh | </pre> |
261 | 1 | Yehuda Sadeh | rename a realm. |
262 | 1 | Yehuda Sadeh | |
263 | 1 | Yehuda Sadeh | <pre> |
264 | 1 | Yehuda Sadeh | $ radosgw-admin realm set-default --realm=dho |
265 | 1 | Yehuda Sadeh | </pre> |
266 | 1 | Yehuda Sadeh | set realm as the default realm |
267 | 1 | Yehuda Sadeh | |
268 | 1 | Yehuda Sadeh | <pre> |
269 | 1 | Yehuda Sadeh | $ radosgw-admin realm get --realm=<name> | --realm-id=<id> |
270 | 1 | Yehuda Sadeh | </pre> |
271 | 1 | Yehuda Sadeh | Get realm information |
272 | 1 | Yehuda Sadeh | |
273 | 1 | Yehuda Sadeh | h3. 1.6.3 zonegroup |
274 | 1 | Yehuda Sadeh | |
275 | 1 | Yehuda Sadeh | <pre> |
276 | 1 | Yehuda Sadeh | $ radosgw-admin zonegroup create --zonegroup=<name> [ --zonegroup-id=<id>] [--master | --master-url=<url> | --realm=<name>] |
277 | 1 | Yehuda Sadeh | </pre> |
278 | 1 | Yehuda Sadeh | |
279 | 1 | Yehuda Sadeh | When doing a remote command that contacts the master zonegroup, we'll also need to provide a uid, and access key. This can be done by specifying --uid and --access-key on the command line (which is a bit of a security problem), or by setting it in ceph.conf (which is a bit of a pain). |
280 | 1 | Yehuda Sadeh | |
281 | 1 | Yehuda Sadeh | <pre> |
282 | 1 | Yehuda Sadeh | $ radosgw-admin zonegroup delete --zonegroup=<name> [ --zonegroup-id=<id>] [--master-url=<url>] |
283 | 1 | Yehuda Sadeh | </pre> |
284 | 1 | Yehuda Sadeh | Remove a zonegroup, the zonegroup needs to be empty. |
285 | 1 | Yehuda Sadeh | |
286 | 1 | Yehuda Sadeh | <pre> |
287 | 1 | Yehuda Sadeh | $ radosgw-admin zonegroup rename --zonegroup=<old name> [ --zonegroup-id=<id>] [--master-url=<url>] --zonegroup-new-name=<new name> |
288 | 1 | Yehuda Sadeh | </pre> |
289 | 1 | Yehuda Sadeh | Rename a zonegroup. |
290 | 1 | Yehuda Sadeh | |
291 | 1 | Yehuda Sadeh | h3. 1.6.4 creating a new zone |
292 | 1 | Yehuda Sadeh | |
293 | 1 | Yehuda Sadeh | <pre> |
294 | 1 | Yehuda Sadeh | $ radosgw-admin zone create --rgw-zone=<zone_name> --zonegroup=<zonegroup_name> --url=<zone url> [--master | --master-url=<url>] |
295 | 1 | Yehuda Sadeh | </pre> |
296 | 1 | Yehuda Sadeh | |
297 | 1 | Yehuda Sadeh | This command will either set the initial master zone for the system, or will create a new zone. It will generate a new random zoneid (uuid). |
298 | 1 | Yehuda Sadeh | |
299 | 1 | Yehuda Sadeh | radosgw will no longer create pools automagically when it starts up. Zone creation will always be an explicit step by the admin. |
300 | 1 | Yehuda Sadeh | |
301 | 1 | Yehuda Sadeh | h3. 1.6.5 Modifying zone configuration: |
302 | 1 | Yehuda Sadeh | |
303 | 1 | Yehuda Sadeh | - Connect zone to another peer (meaning these two zones will sync to/from each other) |
304 | 1 | Yehuda Sadeh | |
305 | 1 | Yehuda Sadeh | <pre> |
306 | 1 | Yehuda Sadeh | $ radosgw-admin zone connect [--rgw-zone=<zone name>] [--zone-id=<zone id>] --peer-zone-id=<peer id> | --peer-zone=<peer name> |
307 | 1 | Yehuda Sadeh | </pre> |
308 | 1 | Yehuda Sadeh | |
309 | 1 | Yehuda Sadeh | - Disconnect zone from another peer |
310 | 1 | Yehuda Sadeh | |
311 | 1 | Yehuda Sadeh | <pre> |
312 | 1 | Yehuda Sadeh | $ radosgw-admin zone disconnect [--rgw-zone=<zone name>] [--zone-id=<zone id>] --peer-zone-id=<peer id> --peer-zone=<peer name> |
313 | 1 | Yehuda Sadeh | </pre> |
314 | 1 | Yehuda Sadeh | |
315 | 1 | Yehuda Sadeh | - Configure a zone placement target (storage policy) |
316 | 1 | Yehuda Sadeh | |
317 | 1 | Yehuda Sadeh | <pre> |
318 | 1 | Yehuda Sadeh | $ radosgw-admin placement modify --placement-target=<name> --zone-id=<id> ... (TBD what exactly) |
319 | 1 | Yehuda Sadeh | </pre> |
320 | 1 | Yehuda Sadeh | |
321 | 1 | Yehuda Sadeh | - Check zone sync status: |
322 | 1 | Yehuda Sadeh | |
323 | 1 | Yehuda Sadeh | <pre> |
324 | 1 | Yehuda Sadeh | $ radosgw-admin zone sync status [--rgw-zone=<zone name>] |
325 | 1 | Yehuda Sadeh | </pre> |
326 | 1 | Yehuda Sadeh | |
327 | 1 | Yehuda Sadeh | Will provide current markers and timestamps for specified zone. |
328 | 1 | Yehuda Sadeh | |
329 | 1 | Yehuda Sadeh | h3. 1.6.6 removing a zone from a zonegroup |
330 | 1 | Yehuda Sadeh | |
331 | 1 | Yehuda Sadeh | <pre> |
332 | 1 | Yehuda Sadeh | $ radosgw-admin zone remove --rgw-zone=<zone_name> [--zone-id=<zone id>] --zonegroup=<zonegroup_name> |
333 | 1 | Yehuda Sadeh | </pre> |
334 | 1 | Yehuda Sadeh | |
335 | 1 | Yehuda Sadeh | h3. 1.6.6 delete a zone |
336 | 1 | Yehuda Sadeh | |
337 | 1 | Yehuda Sadeh | <pre> |
338 | 1 | Yehuda Sadeh | $ radosgw-admin zone delete--rgw-zone=<zone_name> [--zone-id=<zone id>] |
339 | 1 | Yehuda Sadeh | </pre> |
340 | 1 | Yehuda Sadeh | Remove the zone from the system, the zone will be removed from all the zonegroups |
341 | 1 | Yehuda Sadeh | |
342 | 1 | Yehuda Sadeh | h3. 1.6.6 rename a zone |
343 | 1 | Yehuda Sadeh | |
344 | 1 | Yehuda Sadeh | <pre> |
345 | 1 | Yehuda Sadeh | $ radosgw-admin zone rename--rgw-zone=<zone_name> [--zone-id=<zone id>] --zone-new-name=<new name> |
346 | 1 | Yehuda Sadeh | </pre> |
347 | 1 | Yehuda Sadeh | |
348 | 1 | Yehuda Sadeh | *Work items* |
349 | 1 | Yehuda Sadeh | |
350 | 1 | Yehuda Sadeh | *Coding tasks* |
351 | 1 | Yehuda Sadeh | Task 1 |
352 | 1 | Yehuda Sadeh | Task 2 |
353 | 1 | Yehuda Sadeh | Task 3 |
354 | 1 | Yehuda Sadeh | |
355 | 1 | Yehuda Sadeh | *Build / release tasks* |
356 | 1 | Yehuda Sadeh | Task 1 |
357 | 1 | Yehuda Sadeh | Task 2 |
358 | 1 | Yehuda Sadeh | Task 3 |
359 | 1 | Yehuda Sadeh | |
360 | 1 | Yehuda Sadeh | *Documentation tasks* |
361 | 1 | Yehuda Sadeh | Task 1 |
362 | 1 | Yehuda Sadeh | Task 2 |
363 | 1 | Yehuda Sadeh | Task 3 |
364 | 1 | Yehuda Sadeh | |
365 | 1 | Yehuda Sadeh | *Deprecation tasks* |
366 | 1 | Yehuda Sadeh | Task 1 |
367 | 1 | Yehuda Sadeh | Task 2 |
368 | 1 | Yehuda Sadeh | Task 3 |