"Fossies" - the Fresh Open Source Software Archive

Member "masakari-9.0.0/api-ref/source/failover-segments.inc" (13 May 2020, 7446 Bytes) of package /linux/misc/openstack/masakari-9.0.0.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) fasm source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. For more information about "failover-segments.inc" see the Fossies "Dox" file reference documentation and the latest Fossies "Diffs" side-by-side code changes report: 8.0.0_vs_9.0.0.

    1 .. -*- rst -*-
    2 
    3 ============================
    4  FailoverSegments (segments)
    5 ============================
    6 
    7 **Segments**
    8 
    9 System can be zoned from top to down levels, into Regions, Availability Zones
   10 and Host Aggregates (or Cells). Within those zones, one or more
   11 pacemaker/pacemaker-remote clusters may exist. In addition to those boundaries,
   12 shared storage boundary is also important to decide the optimal host for
   13 fail-over. Openstack zoned boundaries (such as Regions, AZ, Host Aggregates,
   14 etc..) can be managed by the nova scheduler. However, shared storage
   15 boundaries are difficult to manage. Moreover, the operator may want to use
   16 other types of boundary such as rack layout and powering. Therefore, operator
   17 may want to define the segment of hypervisor hosts and assign the failover
   18 host/hosts for each of them. Those segment can be define based on the shared
   19 storage boundaries or any other limitations may critical for selection of the
   20 failover host.
   21 
   22 Lists, creates, shows details for, updates, and deletes segments.
   23 
   24 List FailoverSegments
   25 =====================
   26 
   27 .. rest_method:: GET /segments
   28 
   29 Lists IDs, names, description, recovery_method, service_type for all segments.
   30 
   31 Segments contains `service_type` and `recovery_method` attributes.
   32 `service_type` attribute indicates for which service (e.g. compute, cinder
   33 etc) this segment belongs to. `recovery_method` attribute indicates the
   34 recovery action to be followed when any host in a segment goes down. The
   35 possible `recovery_method` values are:
   36 
   37 - ``AUTO``. Auto recovery action.
   38 - ``RESERVED_HOST``. Reserved host recovery action.
   39 - ``AUTO_PRIORITY``. First executes auto and if auto fails then retried with
   40   reserved host recover action.
   41 - ``RH_PRIORITY``. First executes reserved host and if it fails then retried
   42   with reserved host recover action.
   43 
   44 You can filter on the `service_type` and `recovery_method` when you complete a
   45 list segments request.
   46 
   47 Response Codes
   48 --------------
   49 
   50 .. rest_status_code:: success status.yaml
   51 
   52    - 200
   53 
   54 .. rest_status_code:: error status.yaml
   55 
   56    - 400
   57    - 401
   58    - 403
   59    - 404
   60 
   61 Request
   62 -------
   63 
   64 .. rest_parameters:: parameters.yaml
   65 
   66   - limit: limit
   67   - marker: marker
   68   - recovery_method: recovery_method_query_segment
   69   - service_type: service_type_query_segment
   70   - sort_dir: sort_dir
   71   - sort_key: sort_key_segment
   72 
   73 Response
   74 --------
   75 
   76 .. rest_parameters:: parameters.yaml
   77 
   78   - segments: segments
   79   - name: segment_name
   80   - uuid: segment_uuid
   81 
   82 **Example List Segments**
   83 
   84 .. literalinclude:: ../../doc/api_samples/segments/segments-list-resp.json
   85    :language: javascript
   86 
   87 
   88 Create Segment
   89 ==============
   90 
   91 .. rest_method:: POST /segments
   92 
   93 Creates a segment.
   94 
   95 Creates a FailoverSegment with name, description, service_type and
   96 recovery_method. For `service_type` user can mention the name of service for
   97 which this segment is created. As of now user can mention `COMPUTE` as
   98 `service_type`. For `recovery_method` user can mention either `AUTO`,
   99 `RESERVED_HOST`, `AUTO_PRIORITY` or `RH_PRIORITY`. Segment name should be
  100 unique.
  101 
  102 Response Codes
  103 --------------
  104 
  105 .. rest_status_code:: success status.yaml
  106 
  107    - 202
  108 
  109 .. rest_status_code:: error status.yaml
  110 
  111    - 400
  112    - 401
  113    - 403
  114    - 409
  115 
  116 ..
  117 
  118   A conflict(409) is returned if segment with same name is already present.
  119 
  120 Request
  121 -------
  122 
  123 .. rest_parameters:: parameters.yaml
  124 
  125 
  126   - sgement: segment
  127   - description: segment_description
  128   - name: segment_name
  129   - recovery_method: segment_recovery_method
  130   - service_type: segment_service_type
  131 
  132 **Example Create Segment**
  133 
  134 .. literalinclude:: ../../doc/api_samples/segments/segment-create-req.json
  135    :language: javascript
  136 
  137 Response
  138 --------
  139 
  140 .. rest_parameters:: parameters.yaml
  141 
  142   - segment: segment
  143   - created: created
  144   - description: segment_description
  145   - id: segment_id
  146   - name: segment_name
  147   - recovery_method: segment_recovery_method
  148   - service_type: segment_service_type
  149   - updated: updated
  150   - uuid: segment_uuid
  151 
  152 **Example Create Segment**
  153 
  154 .. literalinclude:: ../../doc/api_samples/segments/segment-create-resp.json
  155    :language: javascript
  156 
  157 
  158 Show Segment Details
  159 ====================
  160 
  161 .. rest_method:: GET /segments/{segment_id}
  162 
  163 Shows details for a segment.
  164 
  165 **Preconditions**
  166 
  167 The segment must exist.
  168 
  169 Response Codes
  170 --------------
  171 
  172 .. rest_status_code:: success status.yaml
  173 
  174    - 200
  175 
  176 .. rest_status_code:: error status.yaml
  177 
  178    - 401
  179    - 403
  180    - 404
  181 
  182 Request
  183 -------
  184 
  185 .. rest_parameters:: parameters.yaml
  186 
  187   - segment_id: segment_id_path
  188 
  189 Response
  190 --------
  191 
  192 .. rest_parameters:: parameters.yaml
  193 
  194   - segment: segment
  195   - created: created
  196   - description: segment_description
  197   - id: segment_id
  198   - name: segment_name
  199   - recovery_method: segment_recovery_method
  200   - service_type: segment_service_type
  201   - updated: updated
  202   - uuid: segment_uuid
  203 
  204 **Example Show Segment Details**
  205 
  206 .. literalinclude:: ../../doc/api_samples/segments/segment-get-resp.json
  207    :language: javascript
  208 
  209 
  210 Update Segment
  211 ==============
  212 
  213 .. rest_method:: PUT /segments/{segment_id}
  214 
  215 Updates the editable attributes of an existing segment.
  216 
  217 **Preconditions**
  218 
  219 - The segment must exist.
  220 - User can not update segment if any host from the segment has any usage in
  221   the notification table i.e. any host from the failover segment has
  222   notification status as new/error/running.
  223 
  224 Response Codes
  225 --------------
  226 
  227 .. rest_status_code:: success status.yaml
  228 
  229    - 200
  230 
  231 .. rest_status_code:: error status.yaml
  232 
  233    - 400
  234    - 401
  235    - 403
  236    - 404
  237    - 409
  238 
  239 ..
  240 
  241   A conflict(409) is returned if user tries to update segment name which is
  242   already assigned to segment or if any host from the segment has any usage in
  243   the notification table i.e. any host from the failover segment has
  244   notification status as new/error/running.
  245 
  246 
  247 Request
  248 -------
  249 
  250 .. rest_parameters:: parameters.yaml
  251 
  252   - segment_id: segment_id_path
  253   - description: segment_description
  254   - name: segment_name
  255   - recovery_method: segment_recovery_method
  256   - service_type: segment_service_type
  257 
  258 **Example Update segment name**
  259 
  260 .. literalinclude:: ../../doc/api_samples/segments/segment-update-req.json
  261    :language: javascript
  262 
  263 Response
  264 --------
  265 
  266 .. rest_parameters:: parameters.yaml
  267 
  268   - segment: segment
  269   - created: created
  270   - description: segment_description
  271   - id: segment_id
  272   - name: segment_name
  273   - recovery_method: segment_recovery_method
  274   - service_type: segment_service_type
  275   - updated: updated
  276   - uuid: segment_uuid
  277 
  278 **Example Update Segment name**
  279 
  280 .. literalinclude:: ../../doc/api_samples/segments/segment-update-resp.json
  281    :language: javascript
  282 
  283 
  284 Delete Segment
  285 ==============
  286 
  287 .. rest_method:: DELETE /segments/{segment_id}
  288 
  289 Deletes a segment.
  290 
  291 **Preconditions**
  292 
  293 - The segment must exist.
  294 - User can not delete segment if any host from the segment has any usage in
  295   the notification table i.e. any host from the failover segment has
  296   notification status as new/error/running.
  297 
  298 Response Codes
  299 --------------
  300 
  301 .. rest_status_code:: success status.yaml
  302 
  303    - 204
  304 
  305 .. rest_status_code:: error status.yaml
  306 
  307    - 400
  308    - 401
  309    - 403
  310    - 404
  311    - 409
  312 
  313 ..
  314 
  315   A conflict(409) is returned if user tries to delete the segment if any host
  316   from the segment has any usage in the notification table i.e. any host from
  317   the failover segment has notification status as new/error/running.
  318 
  319 Request
  320 -------
  321 
  322 .. rest_parameters:: parameters.yaml
  323 
  324   - segment_id: segment_id_path
  325 
  326 Response
  327 --------
  328 
  329 There is no body content for the response of a successful DELETE query.