May need to remove note at end of Configure environment variables (Note is true for Cloud Queues, but I don't think it's true for Cloud LBs.)

The 400 and 401 explanations don't seem spaced correctly. Needs a minor text shifting.

Report an issue with the documentation

Describe your documentation issue in the relevant section.

Link to documentation with issue:
https://docs.rackspace.com/docs/cloud-load-balancers/v1/api-reference/ciphers/
https://github.com/rackerlabs/docs-cloud-load-balancers/blame/master/api-docs/cloud-load-balancers-v1/api-reference/ciphers.rst#L44-L62

Report editorial or format problem:

Report incorrect information:

Report missing information:
Table bullets are missing in FireFox and Chrome.

Documentation feedback:

It should normally be on the left side of the screen right after the submit an issue link.
See https://developer.rackspace.com/docs/cloud-servers/v2/developer-guide/#document-index for an example

In Authentication section, above the Example: Authentication response add the following:

.. note::
For detailed information about the authentication response, see the
:rax-devdocs:annotated authentication request and response<cloud-identity/v2/developer-guide/#document-authentication-info/sample-auth-req-response> in the Rackspace Cloud API documentation.

Internal docs files are now in https://github.rackspace.com/IX/internal-docs-cloud-load-balancers-1

Refactor API Guide checklist

Use the following checklist to guide and track the refactoring work for
each Developer Guide. If you have questions, open a docs-common issue.

When you build the refactored Sphinx project, use the make clean html command to build chunked content. Before you begin refactoring, review the restructured text fixes.

Important: If the project contains additional source files or content significantly
different than the template, add a link to the source in Issue #62 in the docs-common repo.

RST coding syntax fixes

Refactoring the API guides gives us a chance to make our RST source files comply with coding best practices. You can make the following changes when you are refactoring, or make the updates in a separate effort.

• Wrap all lines to 79 characters.
• Ensure that heading separator lines are the same length as the title

    ====
    Test
    ====

• Use the following symbols for heading separators:
  • H1: over and underline =
  • H2: ~
  • H3: -
  • H4: ^

In the same file, the header levels must be in sequential order. If they aren't, you get the following error when you run the Sphinx build: SEVERE/4) Title level inconsistent.

Tip: If you are using the Atom editor, you can configure the soft wrap feature to reflow text
to 79 characters with a keybinding:

• Set the line length:
  • Click Atom > Preferences > Settings.
  • Change the Preferred Line Length to 79.
  • Make sure that Soft wrap at Preferred Line length is selected.
  • Do not select the Soft wrap selection.
• Reflow text that exceeds 79 characters.
  • Select the line or paragraph.
  • Click alt+cmd+q to reflow the text. If text is indented or has special formatting,
    you have to adjust the text manually.

Note: Don't worry about the line length in code samples or tables for now.

Configuration updates (conf.py)

• Replace everything above the ## -- General configuration line with the first 32 lines from
  the conf.py in the API Guide template.
• Change deconst builder configuration to deconst-serial to build chunked html.
  builder = 'deconst-serial'
#builder = 'deconst-single
• Add the spelling checker extension after the extension modules configuration.
• Ensure that extlinks library matches the one in conf.py template.
• Add sphinx-rtd-template to improve template for local builds.
• Add requirements.txt to the root directory to support local builds
• Update titles to remove "Developer Guide". Follow title pattern in conf.py template.
• Verify that configuration settings match those in the conf.py for the API Guide template.
• Check conf.py syntax with pep8. Fix errors.

Tip: To catch errors inline, configure Atom for Python.

After you complete the conf.py updates, run the Sphinx build (make clean html) to test that the build still works: make clean html. Resolve any errors.

Note: If the Sphinx build doesn't run, follow the build from source instructions to install the required dependencies.

Overview updates

When you refactor the content in the overview source files, you relocate the content and delete the overview folder and files.

• Move the following files to the root directory of the Sphinx project: additional-resources.rst,service-updates.rst
• Copy the About API description from overview/index.rst to the beginning of the main index.rst file so that the API description is the first information in the API Guide.
• Move any other files in the overview folder to the root directory, and either integrate the content into another topic, or add the file in the index.rst toctree where it makes sense.
• Delete the overview folder.
• Update the index.rst toctree directive:
  • Delete overview/index.rst.
  • Add additional-resources and service-updates after the release-notes file
    and before the copyright as shown in the index.rst template.

After you complete the overview updates, run the local Sphinx build. Resolve any errors. Then, run the following command to review the local build output to verify that the API description, Additional resources and Service updates content renders correctly: open _build/html/index.html

Getting started updates

For the Getting Started section, use the following instructions to refactor the common content and the product-specific Getting Started content.

Update common gs-section

• Copy the common-gs folder with the [API Guide template files].(https://github.com/rackerlabs/docs-common/tree/master/api-guide-template/common-gs)

• View the diff of the new content against your existing content.

  If you have any content that's not included in the common content, determine whether it
  needs to be added to the template. If not, then put the content in a different location so
  that the common content is the same across all API Guides. If necessary, open a
  docs-common issue issue
  to update the template or determine how to handle the custom content. All common-gs
  content must be the same.

The changes made to the common-gs content include the following:

• Adjust heading levels in auth-using-curl.rst to move everything up one level.
• Update get-credentials to move heading up a level and remove Cloud Control Panel login info.
• How-to-use-curl minor edits and add Windows cURL info.
• Wrap all lines at 79 characters and remove trailing spaces.
• Miscellaneous editorial improvements.

Update Getting Started section

• Add the get-credentials-include.rst file to the getting-started folder. This file embeds the common get-credentials.rst topic at the H2 level.
• Move concepts.rst file from the root directory to the getting-started folder.
• Update authentication.rst to append Identity endpoint information at end of last paragraph. See authentication template.
• Update send-request-ovw.rst to change intro sentence to refer to section and
  remove link definition for Cloud Control panel. See Send API request template.
• Update index.rst (See template.)
  • Copy the heading and opening paragraph from getting-started.rst to the
    top of getting-started/index.rst.
  • Remove bold format from heading.
  • Add the prerequisite information after the opening paragraph following the getting-started topic template
  • Update toctree specification:
    * Add get-credentials-include file at the top of the list.
    * Remove prerequisites topic.
    * Add concepts.rst after authentication.rst topic.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correcctly and that it matches the Getting started template.

Developer Guide updates

The Developer Guide refactoring moves the content from the Developer Guide introduction to the main index.rst file.

• index.rst updates:
  • Copy Developer Guide intro about audience and prerequisite knowledge to root index.rst intro before the paragraph with links to the sections of the API documentation. See root index.rst template.
    #- [x] Remove the link to the Developer Guide section.
  • Update the toctree specification to remove developer-guide
• Delete the developer-guide.rst file from the root directory

After you complete the Developer Guide updates, rebuild the Sphinx project. Resolve any errors. Then, preview the local build output to verify that the Developer Guide section was removed.

General API info updates

When you refactor the General API section, the main changes are removing the authentication
topic and adjusting the heading levels. You'll also need to change some common file names and content to match the common content in the API Guide template. Some of these changes are included in the instructions, but there are too many to document in detail. Be careful when you make these changes, some projects have custom information that differs from other projects.

Important: If you have common files in your source that are not in the template directory or significantly deviate from the template source file, add a link to the Github source for that file to the General API info source file issue. This list will help us review and improve the General API Info content and determine whether it needs to be included in the API template.

• Change index.rst heading level to

=======================
General API information
=======================

• Update general-api-info/index.rstto append a reference to the Getting Started authentication section. (See General API info index.rst #template.)
• Update the toctree directive to remove the filename for the authentication topic.
• Delete the authentication source file from the general-api-info directory.
• Change headings in sub-topics to H1 and H2 (~~~~~) per template.
• Rename service-access-endpoints.rst to service-access.rst and match content to template version.
• Compare General API Information source files to the source in the API template directory, and update to match common content where possible.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors, Then, review the local build output to verify that the content renders correctly and that it matches the General API information template.

API Reference updates

When you refactor the API reference section, the main changes are relocating the api-reference heading to api-reference/index.rst topic and adjusting the heading levels in the methods section.

• Rename api-operations folder to api-reference
• Update the exclude_pattern configuration in conf.py with the new name.
• Update api-reference/index.rst to follow template
• Check api-reference.rst in the root directory to make sure it doesn't have any additional
  information not included in the updated api-reference/index.rst file. If no extra content, delete the file. If additional content is included and still needed, move it to the index.rst file.
• Update root index.rst with new path to api-reference/index.rst.
• Change api resource topic heading levels to h1 (====).
• Change api method heading levels to h2 (~~~~~~~~~).
• Change request and response heading levels to h3 (-------).

After you complete these updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Reference API reference template.

Release notes updates

When you refactor the API reference section, the main change is relocating the Release notes heading and introduction to release-notes/index.rst, moving the release note topics to a sub-folder, and including all release notes topic in index.rst. You also need to add the new release-notes folder to the exclude_patterns specification in the Sphinx configuration file, conf.py.

• Set up all release note content to render in a single topic.
  • Create a releases sub-folder in the release-notes directory.
  • Move individual release notes files into the releases folder.
  • Update release-notes/index.rst to include all release files.
    Use the .. include:: directive
• release-notes/index.rst updates: - [x] Change refid to.._release-notes-collection:. - [x] Updaterelease-notes/index.rstto include all release files using the.. include::`` directive. See template.
  • Remove bold format from title.
• Main index.rst updates
  • Update link to release note section to use new
    refid = release-notes-collection.
  • Update toctree specification with path to release-notes/index
• Update the exclude_patterns specification in the Sphinx configuration file conf.py to
  add the release-notes/releases pathr.

After you complete the updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Guide Release notes template.

Root index.rst updates

Many of the refactoring changes in the root index.rst file were completed when you refactored earlier section. These instructions provide a summary of the changes so you can verify them.

• Ensure the first paragraph provides information about audience and prerequisite knowledge like the root index.rst template.
• Update the links to API Guide sections
  • Remove Developer-Guide
  • Change release-notes ref ID to release-notes-collection
• Update files in toctree directive to follow this pattern:

   Product name v# <https://developer.rackspace.com/docs/cloud-load-balancers/v1/>
   getting-started/index
   general-api-info/index
   api-reference/index
   release-notes/index
   service-updates
   additional-resources
   copyright

Changes include:

• Add the following file names:
  • additional-resources.rst
  • service-updates.rst
• Delete the following file names:
  • getting-started.rst topic
  • prerequisites-for-using-api.rst
  • concepts.rst
  • developer-guide.rst
  • api-reference.rst

Note: If your project contains additional source files not included in this list, add them to Issue #62 in the docs-common repo. Include them in the content architecture where it makes sense. IA team can review.

Next steps

After you complete the refactoring work, complete the following steps to submit the changes for review:

1. To change the API documentation template for your project, update the routes.d file in the nexus-control repository to change the template from docs-singlepage.html to user-guide.html.
2. After the nexus-control PR has been merged, submit a PR with your refactoring changes against your upstream repository.
3. Follow the review instructions.

The attached Word doc has my suggested edits for the migrated release notes. Please let me know if you have any questions. Thanks!

Cloud Load Balancers Release Notes_editsKH.docx

From: Rackspace Hosting [email protected]
Date: Thursday, August 18, 2016 at 4:56 PM
To: Cody Somerville [email protected], Jens Jorritsma [email protected]
Cc: Carlos Garza [email protected], Adam Harwell [email protected], Peter Lubbs [email protected], Jorge Miramontes [email protected], Rackspace Hosting [email protected]
Subject: Re: August release of CLB 1.0, v1.25.33

Thanks, Cody.

I’ll update the docs as you note below. Please let me know when the release happens and I’ll publish the doc update externally.

Catherine

From: Cody Somerville [email protected]
Date: Thursday, August 18, 2016 at 4:33 PM
To: Jens Jorritsma [email protected], Rackspace Hosting [email protected]
Cc: Carlos Garza [email protected], Adam Harwell [email protected], Peter Lubbs [email protected], Jorge Miramontes [email protected]
Subject: August release of CLB 1.0, v1.25.33

Hi Jens, and Catherine,

Heads up that we’re hoping to perform a CLB 1.0 release next week.

Jens: Can you file the necessary paperwork/tickets for fast track change deploy?

Catherine: Release is bug fix only so does not require documentation changes beyond updated changelog.

Here are the relevant details:

The version number for the August release is 1.25.33.

The changelog for the August release is as follows:

•      Fixed bug that caused incorrect status to be returned for nodes under certain circumstances when added in condition DRAINING.
  

Best regards,

Cody

@the2hill

Hello admins,

The Information Development Team is migrating all documentation repositories published using Deconst to a new publishing platform stack.

This change is to improve functionality, build times, and longevity of the platform.

Things that won't change:

• How you contribute to this repository
• No downtime
• No GitHub configuration changes

Changes to expect:

• Build checks are now produced by netlify
• Build previews can be accessed by clicking "Details" to the right of "netlify/path/deploy-preview"

The migration has already started and we are unable to provide the exact date that this repo is to be migrated.
If you have questions or concerns please reach out to myself or Robb Romans.

Thanks, William Loy

Update the content URL for refactored API documentation

• Fork and clone the nexus-control to your local system.
• Remove developer-guide from the route configured for the content.

  • Update the nexus-control configuration file as shown in the following example:

    Original: "/docs/cloud-load-balancers/v1/": "https://github.com/rackerlabs/docs-cloud-load-balancers/v1/developer-guide",

    Updated:``"/docs/cloud-load-balancers/v1/": "https://github.com/rackerlabs/docs-cloud-load-balancers/v1/",

    Notes:

    The value on the left is the path to deploy content. The value to the right of the : is the unique
    content ID for the Sphinx project. The content ID must match the "contentIDBase" value in the
    _deconst.json file in the documentation source directory. See Configure development and production builds for Sphinx projects.

• Update the deploy URL in the route configuration file to match the one in the nexus-control configuration file.
• Create a redirect rule for the original URL.

  • Edit the rewrites file to add a redirect rule for the original URL as shown in the following example:

      {
         "description": "Redirect load balancers developer-guide URL",
         "from": "^\\/docs\\/cloud-load-balancers\\/v1\\/developer-guide\\/(.*?)",
         "to": "/docs/cloud-load-balancers/v1/$1",
         "rewrite": false,
         "status": 301
     },
    

  • Use a json linter to verify that the JSON syntax is correct.

• Commit the changes, and push to your fork.
• Submit your updates as a PR against the upstream repository. Include a link to the PR containing the refactored documentation source.
• After the PR is merged, verify that the content is deployed to the new URL, for example https:\\developer.rackspace.com\docs\<updated-path>
• Verify that the redirect rule is working by clicking the Developer Guide link on the DRC docs landing page.

Note: Nexus-control changes take longer to deploy than content changes. You can check the nexus-control version information to determine whether the commit has been deployed.

Update the documentation landing page

Update the menu so that it matches the Load Balancers v1 example shown in the following figure:

Important: Don't commit the landing page updates until you have verified that the content has been deployed to the new URL.

Some menus might be slightly different if the product doesn't have an SDK Quickstart, or if it has additional documentation. If you have questions about the menu content or order, open an issue.

• Fork and clone the docs-quickstart repo to your local system.
• Find the menu for the API documentation you are updating.
• Update the title list and href link targets with the information for your documentation.
• Save the file.
• Commit the changes and push to your fork.
• Submit your updates as a PR against the upstream repository. Include a link to the PR containing the refactored documentation source.
  • Check the PR builder preview to make sure the landing page renders correctly with your updates.
  • Request someone to review and merge the PR.

We'd appreciate your review and feedback on the API Guide prototype to refactor the content architecture and navigation for the Public Cloud API documentation.

• Click through navigation
• Check chunking of information by using Prev and Next links
• Check H1 topics for local contents

Provide any feedback or suggestions for improvement in this issue by Friday, June 17

Thanks for your help!

This issue is a child of the IA - WS issue #58.
See that issue for additional information.

For the API Sphinx docs, we're standardizing on a folder structure like this:

├── api-docs
│   ├── Makefile
│   ├── _build
│   │   └── deconst-single
│   ├── _deconst.json
│   ├── api-operations
│   │   ├── access-lists.rst
│   │   ├── algorithms.rst
│   │   ├── allowed-domains.rst

Load balancers has the Sphinx source project three levels down:

├── rst
│   └── dev-guide
│   ├── common-gs
│   │   ├── auth-using-curl.rst
│   │   ├── get-credentials.rst
│   │   ├── how-to-use-curl.rst
│   │   ├── images
│   │   │   └── show-api-key-control-panel.png
│   │   ├── samples
│   │   │   ├── auth-req-curl.rst
│   │   │   ├── auth-resp-json.rst
│   │   │   ├── auth-token-object.rst
│   │   │   └── service-catalog-endpoint.rst
│   │   └── using-env-variables.rst
│   ├── getting-started
│   │   ├── authenticate.rst
│   │   ├── examples
│   │   │   ├── add-node.rst
│   │   │   ├── copy-paste-curl-terminal.rst
│   │   │   ├── create-cloud-servers-to-lb.rst
│   │   │   ├── create-load-balancer.r

This might be accounting for the fact that LB still has internal doc book content in the src directory.

When that content is converted, we should adjust the directory to match the other API doc source repos.

Use case H1 topics use imperative, H2 topics use gerund, for example:

Manage queues and process messages
Creating a queue
Posting messages
etc

To remove the link to the gsg on docs.rackspace.com

Report an issue with the documentation

Describe your documentation issue in the relevant section. Submit product operation or
performance issues to the Rackspace product team at https://feedback.rackspace.com/.

Link to documentation with issue:
https://developer.rackspace.com/docs/cloud-load-balancers/v1/api-reference/throttle-connections/

Report missing information:
Per https://one.rackspace.com/x/1Y5oGg , the Cloud Load Balancer will return a 503 Server Too Busy if it is throttling connections. However, we don't have that anywhere in the docs, and customers assume there's something wrong with the CLB when they see a 503 error.

If we could get the information in the one wiki article into the CLB docs, that would help clear things up for customers.

Per Jorge Miramontes, the v2 Admin Guide should be migrated but is a low priority item for the Cloud Load Balancer team.

From Margaret:
If migration is required, please update this issue to reflect required work:

• Convert DocBook content to RST.
• Create Sphinx project.
• Set up for internal publishing (details coming soon)

Build and deploy v2 docs.

• Enable build
  Update cibuild script to add v2 docs to Travis build. (Merge PR #93).
• Configure DRC deployment
  Update nexus control configuration to add content repo and routes (Submit PR or request help ).
• Add deliverables to landing page
  Update docs-landing page (Submit PR or request help)

Hi Mike --
I committed the index pages for the api-operation resource types. Those topics (protocols.rst, errorpages.rst) need table and note clean-up.

I am working on the Sphinx build issue and will do another check-in soon. The only files that this change will affect are:
conf.py
index.rst
api-operations/api-operations.rst

I am working on the Sphinx build errors and will check in updates shortly

• Add disclaimer to Developer Docs Trello card
• Update _deconst.json to add variables to enable Edit on GitHub feature Trello card
• Remove SLA and pricing topic from docs Trello card

When updating an SSL certificate on SSL Termination the private key field is named "privatekey" whereas when updating an SSL on Certificate Mapping it is instead "privateKey" ( note the capital K on key ). The API seems to be case sensitive and report a 400 error. Is it either possible to update the API to make is not case sensitive or update the documentation to make this clear?

Thanks

Adam

Below is Nick's email. I found several broken links in this common section.

From: Rackspace Hosting [email protected]
Date: Tuesday, July 5, 2016 at 11:55 AM
To: Nicholas Kuechler [email protected], Jesse Noller [email protected]
Cc: Laura Clymer [email protected], group-laura-clymer [email protected]
Subject: Re: bad link in developer docs

Thanks, Nick! I’ll check this out and get it fixed.

• Catherine

From: Nicholas Kuechler [email protected]
Date: Tuesday, July 5, 2016 at 11:09 AM
To: Jesse Noller [email protected]
Cc: Laura Clymer [email protected], group-laura-clymer [email protected]
Subject: Re: bad link in developer docs

Ah, didn't notice that link.

Thanks!

-Nick

On Jul 5, 2016, at 11:07 AM, Jesse Noller [email protected] wrote:

That would be Laura’s Info dev team under me! CC’ing them

Also note the ‘file an issue’ link in the upper left: https://github.com/rackerlabs/docs-cloud-load-balancers/issues - bugs go straight to the team

On Jul 5, 2016, at 11:03 AM, Nicholas Kuechler [email protected] wrote:

Hey Jesse,

A customer in freenode #rackspace channel noticed a bad link in this section:

https://developer.rackspace.com/docs/cloud-load-balancers/v1/getting-started/send-request-ovw/#send-api-requests

In the first blue box, the 'try using Rackspace SDKs' link is a dead link.

I'm not sure what team owns the developer docs page but I knew you're involved in a lot of the developer-related stuff, so I was hoping you could forward this to the docs folks.

Cheers,
Nick

Use text noted in getting-started-QE.md

Occurences in V1 and V2

See QE checklist first item - can use Cloud Queues as model.

Refactor API Guide: QE checklist

Use the following checklist to verify that API guide refactoring for each service. If you have questions, open a docs-common issue.

Do the QE check against the PR submitted to the master repo. Ask the person who did the refactoring to make you a collaborator on their fork in case you want to submit a PR to correct something.

When you build the refactored Sphinx project, use the make clean html command to build chunked content.

• Review the Strider build log for errors. Notify author about any issues.
• Check for broken links.
• Verify that navigation matches the API Guide template.
• Check the API reference section to verify that the methods for each resource are in a single topic.
• Check the General API information topics to make sure they match the common content where possible.
• Check the Authentication topic in the Getting started section to make sure it matches the common template.
• Check conf.py to make sure it has the updates from the
  template.
• Verify that you can build locally from source.

Kelly edited the contributor collateral, and we added a CONTRIBUTING.md so that users get the link to contributor instructions when working in the repo.

Using [Cloud Identity](https://github.com/rackerlabs/docs-cloud-identity] as a model, update the info for contributors:

• Revise README.md
• Add CONTRIBUTING.md
• Add GITHUBING.md

Update all links and naming to match product.

Also, to avoid merge conflicts and lots of new files checked in every time.

Update .gitignore specification:

_build/* >> api-docs/_build/*

Currently CLB is not entertaining a V2 API and the current documentation for V2 is outdated and should be removed.

We may at some point in the near future reinstate V2 work, but it's likely documentation will be a complete rework.

We should remove the current V2 spec from this repo to clean things up and remove confusion.

at https://pages.github.rackspace.com/IX/internal-docs-cloud-load-balancers-1/latest/

Report an issue with the documentation

For PRs, the preview link for v1 internal docs is opening the v2 EA external docs (that were never published externally)

From https://pages.github.rackspace.com/IX/internal-docs-landing-page/ the link for the CLB internal docs does open https://pages.github.rackspace.com/IX/internal-docs-cloud-load-balancers-1/latest/ but there is a v2.0 in the left side of at the top of the page that opens - text in the right does indicate it's v1.0 internal docs though.

Link to documentation with issue:
In PRs, links in preview for internal v1 docs

Report editorial or format problem:

Report incorrect information:

Report missing information:

Documentation feedback:

The "Building from source" link at the bottom of the Contributing doc does not work (404). I'm not sure which file in the tools directory of the docs-rackspace repo the link is supposed to point to.

(Getting Started Guide already edited).

per email from Jorge Miramontes on 7/27/2016.

Two Parts!

1. "modify nodes" vs "update node"
2. update-node request body

Link to Documentation with Issue

cloud-load-balancers#update-node

Editorial or Format Problem

This paragraph in the header uses different terminology than the rest of the doc.

At least one of the optional attributes is required for the Modify Nodes request. (emphasis mine)

"Modify Nodes" appears only once; Update Node appears 4 times. I propose changing the single instance of "modify nodes" to read "update node".

Missing Information

'update-node' does require a request body. The header mentions this, but the 'update-node' section states that the "operation does not accept a request body." This is similar to #152 (fixed with #155). Maybe we copy/paste the same table which lists optional and required attributes/parameters.

Report an issue with the documentation

Document with the issue: https://github.com/rackerlabs/docs-cloud-load-balancers/blob/master/api-docs/cloud-load-balancers-v1/api-reference/methods/post-add-node-v1.0-account-loadbalancers-loadbalancerid-nodes.rst

Report incorrect information:
This document states that to add a node to a load balancer,

this operation does not accept a request body.

This is incorrect; the operation requires a request body and the very next section in the docs have an example request body.

Refactor API Guide: QE checklist for v1

Use the following checklist to verify the API guide refactoring for Load Balancers, v1. If you have questions, open a docs-common issue.

When you build the refactored Sphinx project, use the make clean html command to build chunked content.

• Review the Strider build log for errors. Notify author about any issues.
• Check for broken links.
• Verify that navigation matches the API Guide template.
• Check the API reference section to verify that the methods for each resource are in a single topic.
• Check the General API information topics to make sure they match the common content where possible.
• Check the Authentication topic in the Getting started section to make sure it matches the common template.
• Check conf.py to make sure it has the updates from the
  template.
• Verify that you can build locally from source.

Report an issue with the documentation

Describe your documentation issue in the relevant section.
The table entitled "Table. Required and Optional Attributes for Monitor HTTP and HTTPS" is repeated twice, once with formatting and once without.

The content between the two repeating tables appears inconsistent as well.

The Attribute "bodyRegex" is OPTIONAL; please use the table that has bodyRegex's "Required" column set to "No""

Link to documentation with issue:
https://developer.rackspace.com/docs/cloud-load-balancers/v1/api-reference/monitors/