brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mikezaccardo <...@git.apache.org>
Subject [GitHub] brooklyn-docs pull request #98: Improve location docs
Date Tue, 02 Aug 2016 21:19:53 GMT
Github user mikezaccardo commented on a diff in the pull request:

    https://github.com/apache/brooklyn-docs/pull/98#discussion_r73239894
  
    --- Diff: guide/ops/locations/_cloudstack.md ---
    @@ -0,0 +1,138 @@
    +---
    +section: Openstack
    +title: Openstack
    +section_type: inline
    +section_position: 6
    +---
    +
    +## CloudStack
    +
    +### Connection Details
    +
    +The endpoint URI will normally have the suffix `/client/api/`.
    +
    +The identity is the "api key" and the credential is the "secret key". These can be generated
in 
    +the cloudstack gui: under accounts, select "view users", then "generate key".
    +
    +    location:
    +      jclouds:cloudstack:
    +        endpoint: https://cloud.acme.com/client/api
    +        identity: abcdefghijklmnopqrstuvwxyz01234567890-abcdefghijklmnopqrstuvwxyz01234567890-abcdefghij
    +        credential: mycred-abcdefghijklmnopqrstuvwxyz01234567890-abcdefghijklmnopqrstuvwxyz01234567890-abc
    +
    +
    +### Common Configuration Options
    +
    +Below are examples of configuration options that use values specific to CloudStack environments:
    +
    +* The `imageId` is the template id. For example,
    +  `imageId: db0bcce3-9e9e-4a87-a953-2f46b603498f`.
    +
    +* The `region` is CloudStack zone id.
    +  For example `region: 84539b9c-078e-458a-ae26-c3ffc5bb1ec9`..
    +
    +* `networkName` is the network id (within the given zone) to be used. For example, 
    +  `networkName: 961c03d4-9828-4037-9f4d-3dd597f60c4f`.
    +
    +For further configuration options, consult 
    +[jclouds CloudStack template options](https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptions.html).
    +These can be used with the **[templateOptions](#custom-template-options)** configuration
option.
    +
    +
    +### Using a Pre-existing Key Pair
    +
    +The configuration below uses a pre-existing key pair:
    +
    +    location:
    +      jclouds:cloudstack:
    +        ...
    +        jclouds.openstack-nova.auto-generate-keypairs: false
    +        loginUser: root
    +        loginUser.privateKeyFile: /path/to/keypair.pem
    +        keyPair: my-keypair
    +
    +
    +### Using Pre-existing Security Groups
    +
    +To specify existing security groups, their ids must be used rather than their names (note
this
    +differs from the configuration on other clouds!).
    + 
    +The configuration below uses a pre-existing security group:
    +
    +    location:
    +      jclouds:cloudstack:
    +        ...
    +        templateOptions:
    +          generateSecurityGroup: false
    +          securityGroupIds:
    +          - 12345678-90ab-def0-1234-567890abcdef
    +
    +
    +### Using Static NAT
    +
    +Assigning a public IP to a VM at provision-time is referred to as "static NAT" in CloudStack
    +parlance. To give some consistency across different clouds, the configuration option
is named
    +`autoAssignFloatingIp`. For example, `autoAssignFloatingIp: false`.
    +
    +
    +### Cloudmonkey CLI
    +
    +The [CloudStack Cloudmonkey CLI](https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI)
    +is a very useful tool for validating that credentials are correct, and for querying the
API to find the correct
    +zone ids etc.
    +
    +Useful commands include:
    +
    +    # for finding the ids of the zones:
    +    cloudmonkey api listZones
    +
    +    # for finding the ids of the networks.
    +    cloudmonkey api listNetworks | grep -E "id =|name =|========="
    +
    +### CloudStack Troubleshooting
    +
    +These troubleshooting tips are more geared towards problems encountered in old test/dev

    +CloudPlatform environment.
    +
    +#### Resource Garbage Collection Issues
    +
    +The environment may run out of resources, due to GC issues, preventing the user from
creating new 
    +VMs or allocating IP addresses (May respond with this error message: 
    +`errorCode=INTERNAL_ERROR, errorText=Job failed due to exception Unable to create a deployment
for VM`). 
    +There are two options worth checking it to enforce clearing up the zombie resources:
    +
    +* Goto the Accounts tab in the webconsole and tap on the Update Resource Count button.
    +* Restart the VPC in question from the Network tab.
    +
    +
    +#### Releasing Allocated Public IP Addresses
    +
    +Releasing allocated Public IP from the web console did not free up the resources. Instead

    +Cloudmonkey can be used to dissociate IPs and expunge VMs.
    +
    +Here is a cloudmonkey script to dissociate any zombie IPs:
    +
    +    cloudmonkey set display json;
    +    cloudmonkey api listPublicIpAddresses | grep '"id":' > ips.txt; 
    +    sed -i -e s/'      "id": "'/''/g ips.txt;
    +    sed -i -e s/'",'/''/g ips.txt
    +    for line in $(cat ips.txt); do cloudmonkey api disassociateIpAddress id="$line";
done
    +    rm ips.txt;
    +    cloudmonkey set display default;
    +
    +
    +#### Restarting VPCs
    +
    +Errors have been encountered when a zone failed to provision new VMs, giving errors like:
    --- End diff --
    
    "giving errors like" -> "with messages like"


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message