openstack/api-site
Code Issues Proposed changes

[firstapp] use meaningful filennames instead of sectionX.rst

Browse Source 
Change-Id: I33e506e3e26d7e55287cb48a348b1b9de5f32231
This commit is contained in:
Christian Berendt 2015-05-04 12:22:10 +02:00 committed by Andreas Jaeger
parent ae45109455
commit 61b94863ba
15 changed files with 125 additions and 125 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
firstapp/samples/fog/section1.rb → firstapp/samples/fog/getting_started.rb
View File

0
firstapp/samples/libcloud/section4.py → firstapp/samples/libcloud/durability.py
View File

0
firstapp/samples/libcloud/section1.py → firstapp/samples/libcloud/getting_started.py
View File

0
firstapp/samples/libcloud/section2.py → firstapp/samples/libcloud/introduction.py
View File

0
firstapp/samples/libcloud/section3.py → firstapp/samples/libcloud/scaling_out.py
View File

2
firstapp/source/section8.rst → firstapp/source/advice.rst
View File

@ -13,7 +13,7 @@ Monitoring is essential for cloud applications, especially if the
application is to be 'scalable'. You must know how many requests are
coming in, and what impact that has on the various services -- in
other words, enough information to determine whether you should start
another worker or API service as we did in :doc:`/section3`.
another worker or API service as we did in :doc:`/scaling_out`.
.. todo:: explain how to achieve this kind of monitoring. Ceilometer?
(STOP LAUGHING.)

10
firstapp/source/section5.rst → firstapp/source/block_storage.rst
View File

@ -30,7 +30,7 @@ create them.
Advanced users should consider how to remove the database from the
architecture altogether and replace it with metadata in the Object
Storage (then contribute these steps to :doc:`section9`). Others
Storage (then contribute these steps to :doc:`craziness`). Others
should read on to learn about how to work with block storage and move
the Fractal app database server to use it.
@ -129,7 +129,7 @@ Using Block Storage for the Fractal database server
Firstly, we're going to need a new server for our dedicated database.
Start a new instance called :code:`app-database` using the image, flavor
and keypair you have been using since :doc:`/section1`.
and keypair you have been using since :doc:`/getting_started`.
We will also need a new security group to allow access to the database server
(for mysql, port 3306) from the network:
@ -300,6 +300,6 @@ There are several calls we did not cover. To see these and more, refer
to the volume documentation of your SDK, or try a different step in
the tutorial, including:
* :doc:`/section6`: to automatically orchestrate the application
* :doc:`/section7`: to learn about more complex networking
* :doc:`/section8`: for advice for developers new to operations
* :doc:`/orchestration`: to automatically orchestrate the application
* :doc:`/networking`: to learn about more complex networking
* :doc:`/advice`: for advice for developers new to operations

0
firstapp/source/section9.rst → firstapp/source/craziness.rst
View File

38
firstapp/source/section4.rst → firstapp/source/durability.rst
View File

@ -57,7 +57,7 @@ a number of reasons.
Because the local filesystem is ephemeral storage, if the instance is
terminated, the fractal images will be lost along with the
instance. Block based storage, which we'll discuss in
:doc:`/section5`, avoids that problem, but like local filesystems, it
:doc:`/block_storage`, avoids that problem, but like local filesystems, it
requires administration to ensure that it does not fill up, and
immediate attention if disks fail.
@ -86,7 +86,7 @@ First, let's learn how to connect to the Object Storage endpoint:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-1
:end-before: step-2
@ -125,7 +125,7 @@ Call yours :code:`fractals`:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-2
:end-before: step-3
@ -140,7 +140,7 @@ all containers in your account:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-3
:end-before: step-4
@ -156,7 +156,7 @@ online, name it :code:`goat.jpg` and upload it to your container
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-4
:end-before: step-5
@ -166,7 +166,7 @@ same:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-5
:end-before: step-6
@ -175,7 +175,7 @@ same:
[<Object: name=an amazing goat, size=191874, hash=439884df9c1c15c59d2cf43008180048, provider=OpenStack Swift ...>]
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-6
:end-before: step-7
@ -183,7 +183,7 @@ same:
<Object: name=an amazing goat, size=954465, hash=7513986d3aeb22659079d1bf3dc2468b, provider=OpenStack Swift ...>
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-7
:end-before: step-8
@ -197,7 +197,7 @@ Finally, let's clean up by deleting our test object:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-8
:end-before: step-9
@ -205,7 +205,7 @@ Finally, let's clean up by deleting our test object:
Now there should be no more objects be available in the container :code:`fractals`.
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-9
:end-before: step-10
@ -224,7 +224,7 @@ Use the :code:`fractals`' container from above to put the images in:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-10
:end-before: step-11
@ -233,7 +233,7 @@ swift container. A simple for loop takes care of that:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-11
:end-before: step-12
@ -267,7 +267,7 @@ the container before running this, otherwise it will fail:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-12
:end-before: step-13
@ -286,7 +286,7 @@ This is more efficient, especially for larger files.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-13
:end-before: step-14
@ -308,7 +308,7 @@ For efficiency, most Object Storage installations treat large objects
:code:`chunk_size` parameter (in bytes) according to what your
cloud can accept.
.. literalinclude:: ../samples/libcloud/section4.py
.. literalinclude:: ../samples/libcloud/durability.py
:start-after: step-14
:end-before: step-15
@ -325,8 +325,8 @@ You can find more about the Object Storage SDK calls at:
Or try a different step in the tutorial, including:
* :doc:`/section5`: to migrate the database to block storage, or use
* :doc:`/block_storage`: to migrate the database to block storage, or use
the database-as-as-service component
* :doc:`/section6`: to automatically orchestrate the application
* :doc:`/section7`: to learn about more complex networking
* :doc:`/section8`: for advice for developers new to operations
* :doc:`/orchestration`: to automatically orchestrate the application
* :doc:`/networking`: to learn about more complex networking
* :doc:`/advice`: for advice for developers new to operations

76
firstapp/source/section1.rst → firstapp/source/getting_started.rst
View File

@ -178,7 +178,7 @@ initial version of the guide assume that you're using Libcloud.
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-1
:end-before: step-2
@ -187,7 +187,7 @@ initial version of the guide assume that you're using Libcloud.
To try it, add the following code to a Python script (or use an
interactive Python shell) by calling :code:`python -i`.
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-1
:end-before: step-2
@ -230,13 +230,13 @@ To list the images that are available in your cloud, run some API calls:
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-2
:end-before: step-3
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-2
:end-before: step-3
@ -251,13 +251,13 @@ You can also get information about available flavors:
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-3
:end-before: step-4
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-3
:end-before: step-4
@ -293,13 +293,13 @@ image that you picked in the previous section:
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-4
:end-before: step-5
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-4
:end-before: step-5
@ -313,13 +313,13 @@ Next, tell the script which flavor you want to use:
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-5
:end-before: step-6
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-5
:end-before: step-6
@ -351,13 +351,13 @@ Create the instance.
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-6
:end-before: step-7
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-6
:end-before: step-7
@ -382,13 +382,13 @@ If you list existing instances:
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-7
:end-before: step-8
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-7
:end-before: step-8
@ -418,13 +418,13 @@ money. Destroy cloud resources to avoid unexpected expenses.
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-8
:end-before: step-9
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-8
:end-before: step-9
@ -456,7 +456,7 @@ instance:
instance. Typically, your public key is written to :code:`.ssh/id_rsa.pub`. If
you do not have an SSH public key file, follow
`these instructions <https://help.github.com/articles/generating-ssh- keys/>`_ first.
We'll cover these instructions in depth in :doc:`/section2`.
We'll cover these instructions in depth in :doc:`/introduction`.
.. only:: fog
@ -467,7 +467,7 @@ instance:
In the following example, :code:`pub_key_file` should be set to
the location of your public SSH key file.
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-9
:end-before: step-10
@ -477,24 +477,24 @@ instance:
* Network access. By default, OpenStack filters all traffic. You must create
a security group and apply it to your instance. The security group allows HTTP
and SSH access. We'll go into more detail in :doc:`/section2`.
and SSH access. We'll go into more detail in :doc:`/introduction`.
.. only:: fog
.. literalinclude:: ../samples/fog/section1.rb
.. literalinclude:: ../samples/fog/getting_started.rb
:start-after: step-10
:end-before: step-11
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-10
:end-before: step-11
* Userdata. During instance creation, you can provide userdata to OpenStack to
configure instances after they boot. The cloud-init service applies the
userdata to an instance. You must pre-install the cloud-init service on your
chosen image. We'll go into more detail in :doc:`/section2`.
chosen image. We'll go into more detail in :doc:`/introduction`.
.. only:: fog
@ -502,7 +502,7 @@ instance:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-11
:end-before: step-12
@ -520,7 +520,7 @@ request the instance, wait for it to build.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-12
:end-before: step-13
@ -530,7 +530,7 @@ instance to deploy the Fractals application.
Associate a floating IP for external connectivity
-------------------------------------------------
We'll cover networking in detail in :doc:`/section7`.
We'll cover networking in detail in :doc:`/networking`.
To see the application running, you must know where to look for it. By
default, your instance has outbound network access. To make your instance
@ -550,7 +550,7 @@ address to your instance.
address pool. Allocate this pool to your project and attach it to your
instance.
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-13
:end-before: step-14
@ -564,7 +564,7 @@ address to your instance.
You can then attach it to the instance:
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-14
:end-before: step-15
@ -580,7 +580,7 @@ using your preferred browser.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:start-after: step-15
.. note:: If you do not use floating IPs, substitute another IP address as appropriate
@ -596,18 +596,18 @@ Next steps
~~~~~~~~~~
Don't worry if these concepts are not yet completely clear. In
:doc:`/section2`, we explore these concepts in more detail.
:doc:`/introduction`, we explore these concepts in more detail.
* :doc:`/section3`: Learn how to scale your application
* :doc:`/section4`: Learn how to use Object Storage to make your application durable
* :doc:`/section5`: Migrate the database to block storage, or use
* :doc:`/scaling_out`: Learn how to scale your application
* :doc:`/durability`: Learn how to use Object Storage to make your application durable
* :doc:`/block_storage`: Migrate the database to block storage, or use
the database-as-a-service component
* :doc:`/section6`: Automatically orchestrate your application
* :doc:`/section7`: Learn about complex networking
* :doc:`/section8`: Get advice about operations
* :doc:`/section9`: Learn some crazy things that you might not think to do ;)
* :doc:`/orchestration`: Automatically orchestrate your application
* :doc:`/networking`: Learn about complex networking
* :doc:`/advice`: Get advice about operations
* :doc:`/craziness`: Learn some crazy things that you might not think to do ;)
.. todo:: List the next sections here or simply reference section2.
.. todo:: List the next sections here or simply reference introduction.
Complete code sample
~~~~~~~~~~~~~~~~~~~~
@ -621,5 +621,5 @@ information, the flavor ID, and image ID.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section1.py
.. literalinclude:: ../samples/libcloud/getting_started.py
:language: python

18
firstapp/source/index.rst
View File

@ -8,15 +8,15 @@ Contents
.. toctree::
:maxdepth: 2
section1
section2
section3
section4
section5
section6
section7
section8
section9
getting_started
introduction
scaling_out
durability
block_storage
orchestration
networking
advice
craziness
appendix
Search in this guide

54
firstapp/source/section2.rst → firstapp/source/introduction.rst
View File

@ -130,7 +130,7 @@ Fractals application architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Fractals application was designed with the principles of the previous
subsection in mind. You'll note that in :doc:`section1`, we deployed the
subsection in mind. You'll note that in :doc:`getting_started`, we deployed the
application in an all-in-one style, on a single virtual machine. This isn't
good practice, but because the application uses micro-services to decouple
logical application functions, we can change this easily.
@ -176,8 +176,8 @@ and a simple command line interface.
There are also multiple storage back ends (to store the generated
fractal images) and a database component (to store the state of
tasks), but we'll talk about those in :doc:`/section4` and
:doc:`/section5` respectively.
tasks), but we'll talk about those in :doc:`/durability` and
:doc:`/block_storage` respectively.
How the Fractals application interacts with OpenStack
-----------------------------------------------------
@ -202,11 +202,11 @@ don't need to execute these commands again.)
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-1
:end-before: step-2
We explained image and flavor in :doc:`section1`, so in the following
We explained image and flavor in :doc:`getting_started`, so in the following
sections, we will explain the other parameters in detail, including
:code:`ex_userdata` (cloud-init) and :code:`ex_keyname` (key pairs).
@ -234,7 +234,7 @@ your cloud provider to confirm the user name.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-2
:end-before: step-3
@ -274,7 +274,7 @@ port 22):
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-3
:end-before: step-4
@ -287,7 +287,7 @@ You can list available security groups with:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-4
:end-before: step-5
@ -296,7 +296,7 @@ Once you've created a rule or group, you can also delete it:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-5
:end-before: step-6
@ -305,7 +305,7 @@ To see which security groups apply to an instance, you can:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-6
:end-before: step-7
@ -344,7 +344,7 @@ then associate it to your instance's network interface.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-7
:end-before: step-8
@ -356,7 +356,7 @@ that it has available IP addresses.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-8
:end-before: step-9
@ -364,7 +364,7 @@ Now request that an address from this pool be allocated to your project.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-9
:end-before: step-10
@ -373,12 +373,12 @@ project, attach it to an instance.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-10
:end-before: step-11
That brings us to where we ended up at the end of
:doc:`/section1`. But where do we go from here?
:doc:`/getting_started`. But where do we go from here?
Splitting services across multiple instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -412,7 +412,7 @@ Parameter Description Values
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-11
:end-before: step-12
@ -427,7 +427,7 @@ Next, start a second instance, which will be the worker instance:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-12
:end-before: step-13
@ -462,7 +462,7 @@ address of the worker:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:start-after: step-13
:end-before: step-14
@ -554,7 +554,7 @@ with :code:`faafo get --help`, :code:`faafo list --help`, and
here as an example only as an easy way to allow multiple
instances to have access to the data. For best practice, we
recommend storing objects in Object Storage, which is
covered in :doc:`section4`.
covered in :doc:`durability`.
Next steps
~~~~~~~~~~
@ -567,17 +567,17 @@ instances to run it. These are the basic steps for requesting and
using compute resources in order to run your application on an
OpenStack cloud.
From here, you should go to :doc:`/section3` to learn how to scale your
From here, you should go to :doc:`/scaling_out` to learn how to scale your
application further. Alternatively, you may jump to any of these
sections:
* :doc:`/section4`: Learn how to use Object Storage to make your application more durable
* :doc:`/section5`: Migrate the database to block storage, or use
* :doc:`/durability`: Learn how to use Object Storage to make your application more durable
* :doc:`/block_storage`: Migrate the database to block storage, or use
the database-as-a-service component
* :doc:`/section6`: Automatically orchestrate the application
* :doc:`/section7`: Learn about more complex networking
* :doc:`/section8`: Get advice about operations
* :doc:`/section9`: Learn some crazy things that you might not think to do ;)
* :doc:`/orchestration`: Automatically orchestrate the application
* :doc:`/networking`: Learn about more complex networking
* :doc:`/advice`: Get advice about operations
* :doc:`/craziness`: Learn some crazy things that you might not think to do ;)
Complete code sample
@ -591,5 +591,5 @@ information, the flavor ID, and image ID.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section2.py
.. literalinclude:: ../samples/libcloud/introduction.py
:language: python

6
firstapp/source/section7.rst → firstapp/source/networking.rst
View File

@ -477,7 +477,7 @@ Booting a worker
Now that you've prepared the networking infrastructure, you can go
ahead and boot an instance on it. Ensure you use appropriate flavor
and image values for your cloud - see :doc:`section1` if you've not
and image values for your cloud - see :doc:`getting_started` if you've not
already.
.. todo:: Show how to create an instance in libcloud using the network
@ -835,6 +835,6 @@ are several calls we did not cover. To see these and more, refer to
the volume documentation of your SDK, or try a different step in the
tutorial, including:
* :doc:`/section8`: for advice for developers new to operations
* :doc:`/section9`: to see all the crazy things we think ordinary
* :doc:`/advice`: for advice for developers new to operations
* :doc:`/craziness`: to see all the crazy things we think ordinary
folks won't want to do ;)

6
firstapp/source/section6.rst → firstapp/source/orchestration.rst
View File

@ -193,6 +193,6 @@ You should now be fairly confident working with the Orchestration service.
There are several calls we did not cover. To see these and more,
refer to the volume documentation of your SDK, or try a different step in the tutorial, including:
* :doc:`/section7` - to learn about more complex networking
* :doc:`/section8` - for advice for developers new to operations
* :doc:`/section9` - to see all the crazy things we think ordinary folks won't want to do ;)
* :doc:`/networking` - to learn about more complex networking
* :doc:`/advice` - for advice for developers new to operations
* :doc:`/craziness` - to see all the crazy things we think ordinary folks won't want to do ;)

40
firstapp/source/section3.rst → firstapp/source/scaling_out.rst
View File

@ -20,7 +20,7 @@ do two things:
.. todo:: nickchase needs to restate the second point
In section :doc:`/section2`, we talked about various aspects of the
In section :doc:`/introduction`, we talked about various aspects of the
application architecture, such as building in a modular fashion,
creating an API, and so on. Now you'll see why those are so
important. By creating a modular application with decoupled services,
@ -52,7 +52,7 @@ one worker, we can only produce one fractal at a time. Before long, it
will be clear that we need more resources.
.. note:: If you don't have a working application, follow the steps in
:doc:`section2` to create one.
:doc:`introduction` to create one.
.. todo:: Ensure we have the controller_ip even if this is a new
python session.
@ -157,7 +157,7 @@ are no longer working, remove them and re-create something new.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-1
:end-before: step-2
@ -171,7 +171,7 @@ required security groups.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-2
:end-before: step-3
@ -184,7 +184,7 @@ reaching your Floating IP quota too quickly.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-3
:end-before: step-4
@ -199,7 +199,7 @@ between the services.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-4
:end-before: step-5
@ -216,7 +216,7 @@ multiple API services:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-5
:end-before: step-6
@ -230,7 +230,7 @@ half the other, but that's certainly not a sustainable solution.
Instead, we can do that automatically using a `DNS round robin
<http://en.wikipedia.org/wiki/Round-robin_DNS>`_. However, OpenStack
networking can provide Load Balancing as a Service, which we'll
explain in :doc:`/section7`.
explain in :doc:`/networking`.
.. todo:: Add a note that we demonstrate this by using the first API
instance for the workers and the second API instance for the
@ -244,7 +244,7 @@ To increase the overall capacity, we will now add 3 workers:
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:start-after: step-6
:end-before: step-7
@ -261,7 +261,7 @@ system would do this itself. If your application has been built to
detect these situations, you can have it automatically request and
remove resources, but you don't actually need to do this work
yourself. Instead, the OpenStack Orchestration service can monitor
load and start instances as appropriate. See :doc:`section6` to find
load and start instances as appropriate. See :doc:`orchestration` to find
out how to set that up.
Verifying we've had an impact
@ -349,7 +349,7 @@ point.
If we had a load balancer, we could distribute this load between the
two different API services. As mentioned previously, there are several
options. We will show one in :doc:`section7`.
options. We will show one in :doc:`networking`.
You could in theory use a simple script to monitor the load on your
workers and API services and trigger the creation of new instances,
@ -357,7 +357,7 @@ which you already know how to do. If you can see how to do that -
congratulations, you're ready to create scalable cloud applications.
Of course, creating a monitoring system just for one application may
not always be the best way. We recommend you look at :doc:`section6`
not always be the best way. We recommend you look at :doc:`orchestration`
to find out about how you can use OpenStack Orchestration's monitoring
and autoscaling capabilities to do steps like this automatically.
@ -368,7 +368,7 @@ Next steps
You should be fairly confident now about starting new instances, and
distributing services from an application amongst the instances.
As mentioned in :doc:`/section2` the generated fractal images will be
As mentioned in :doc:`/introduction` the generated fractal images will be
saved on the local filesystem of the API service instances. Because we
now have multiple API instances up and running, the fractal
images will be spread across multiple API services. This results in a number of
@ -376,16 +376,16 @@ images will be spread across multiple API services. This results in a number of
fractal image from an API service instance not holding the fractal
image on its local filesystem.
From here, you should go to :doc:`/section4` to learn how to use
From here, you should go to :doc:`/durability` to learn how to use
Object Storage to solve this problem in a elegant way. Alternatively,
you may jump to any of these sections:
* :doc:`/section5`: Migrate the database to block storage, or use
* :doc:`/block_storage`: Migrate the database to block storage, or use
the database-as-a-service component
* :doc:`/section6`: Automatically orchestrate your application
* :doc:`/section7`: Learn about complex networking
* :doc:`/section8`: Get advice about operations
* :doc:`/section9`: Learn some crazy things that you might not think to do ;)
* :doc:`/orchestration`: Automatically orchestrate your application
* :doc:`/networking`: Learn about complex networking
* :doc:`/advice`: Get advice about operations
* :doc:`/craziness`: Learn some crazy things that you might not think to do ;)
Complete code sample
@ -400,5 +400,5 @@ information, the flavor ID, and image ID.
.. only:: libcloud
.. literalinclude:: ../samples/libcloud/section3.py
.. literalinclude:: ../samples/libcloud/scaling_out.py
:language: python