Comment 0 for bug 1568848

e.g.:

Usage: juju bootstrap [options] <controller name> <cloud name>[/region]

Summary:
Initializes a cloud environment.

Options:

--agent-version (= "")
    Version of tools to use for Juju agents
--auto-upgrade (= false)
    Upgrade to the latest patch release tools on first bootstrap
--bootstrap-constraints (= )
    Specify bootstrap machine constraints
--bootstrap-series (= "")
    Specify the series of the bootstrap machine
--config (= )
    Specify a controller configuration file, or one or more configuration options
    (--config config.yaml [--config key=value ...])
--constraints (= )
    Set model constraints
--credential (= "")
    Credentials to use when bootstrapping
--keep-broken (= false)
    Do not destroy the model if bootstrap fails
--metadata-source (= "")
    Local path to use as tools and/or metadata source
--to (= "")
    Placement directive indicating an instance to bootstrap
--upload-tools (= false)
    Upload local version of tools before bootstrapping

Details:
Initialization consists of creating an 'admin' model and provisioning a machine to act as controller.
Credentials are set beforehand and are distinct from any other configuration (see `juju add-credential`).
The 'admin' model typically does not run workloads. It should remain pristine to run and manage Juju's own infrastructure for the corresponding cloud. Additional (hosted) models should be created with `juju create-model` for workload purposes.
Note that a 'default' model is also created and becomes the current model of the environment once the command completes. It can be discarded if other models are created.
If '--bootstrap-constraints' is used, its values will also apply to any future controllers provisioned for high availability (HA).
If '--constraints' is used, its values will be set as the default constraints
for all future workload machines in the model, exactly as if the constraints were set with `juju set-model-constraints`.
It is possible to override constraints and the automatic machine selection
algorithm by assigning a "placement directive" via the '--to' option. This dictates what machine to use for the controller. This would typically be used with the MAAS provider ('--to <host>.mass').
You can change the default timeout and retry delays used during the bootstrap by changing the following settings in your configuration file (all values represent number of seconds):
    # How long to wait for a connection to the controller
    bootstrap-timeout: 600 # default: 10 minutes
    # How long to wait between connection attempts to a controller address.
    bootstrap-retry-delay: 5 # default: 5 seconds
    # How often to refresh controller addresses from the API server.
    bootstrap-addresses-delay: 10 # default: 10 seconds
Private clouds may need to specify their own custom image metadata and tools/agent. Use '--metadata-source' whose value is a local directory.
The value of '--agent-version' will become the default tools version to use in all models for this controller. The full binary version is accepted (e.g.: 2.0.1-xenial-amd64) but only the numeric version (e.g.: 2.0.1) is used. Otherwise, by default, the version used is that of the client.

Examples:

    juju bootstrap mycontroller google
    juju bootstrap --config=~/config-rs.yaml mycontroller rackspace
    juju bootstrap --config agent-version=1.25.3 mycontroller aws
    juju bootstrap --config bootstrap-timeout=1200 mycontroller azure

See also: add-credentials
          create-model
          set-constraints