Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document environment-specific placement directives #86

Closed
axw opened this issue Apr 24, 2014 · 7 comments
Closed

Document environment-specific placement directives #86

axw opened this issue Apr 24, 2014 · 7 comments
Assignees
Milestone

Comments

@axw
Copy link
Contributor

axw commented Apr 24, 2014

There's now support (on trunk) for juju bootstrap/add-machine to take an optional environment-specific placement directive. MAAS is the only provider that currently supports such directives; we use this to bootstrap/add machines based on specific nodes in MAAS.

e.g.
juju bootstrap
juju add-machine

@evilnick evilnick added this to the 1.20 milestone May 15, 2014
@evilnick evilnick added the 1.20 label May 15, 2014
@axw
Copy link
Contributor Author

axw commented Jun 9, 2014

We now also have support in the ec2 provider for availability zone placement. The syntax for this placement directive is zone=<zonename>, e.g. zone=us-east-1b.

This will also be in the openstack provider very soon.

@marcoceppi
Copy link
Contributor

Per juju/juju#37, this appears to be available for OpenStack too

@axw
Copy link
Contributor Author

axw commented Jun 11, 2014

Indeed it is. Exactly the same format for openstack as in ec2. Note that not all OpenStack instances are equal, and not all support availability zones. HP Cloud's US West region has a few AZs (az1, az2, az3).

@pmatulis pmatulis self-assigned this Jul 29, 2015
@pmatulis
Copy link
Contributor

@evilnick and others

we have some of this in charms-ha and in commands but there is nothing specific regarding what providers support this and no caveats (a provider may or may not support it depending on implementation).

is augmenting the above two documents good enough or should we:

  • start building out provider-specific docs (beyond installation)?
  • include this in a provider's install/config page? (my preference)

@pmatulis
Copy link
Contributor

@pmatulis
Copy link
Contributor

pmatulis commented Aug 7, 2015

Submitted PR #596

@pmatulis
Copy link
Contributor

PR merged. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants