Re: Can't juju deploy p2.xlarge in aws/us-east-1

On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh < tim.van.steenbu...@canonical.com> wrote: > 2.1.1 juju client and controller, controller bootstrapped in aws/us-east-1: > > juju deploy ./kubernetes-worker --constraints "instance-type=p2.xlarge" > kubernetes-worker-gpu > Deploying charm "local:

Re: Can't juju deploy p2.xlarge in aws/us-east-1

I am using the default settings, no change as far as I know to what Juju would do by default. -- Samuel Cozannet Cloud, Big Data and IoT Strategy Team Business Development - Cloud and ISV Ecosystem Changing the Future of Cloud Ubuntu / Canonical UK LTD

Re: Can't juju deploy p2.xlarge in aws/us-east-1

On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet < samuel.cozan...@canonical.com> wrote: > I am using the default settings, no change as far as I know to what Juju > would do by default. > What Juju will do depends on what is available in your EC2 account. Not all EC2 accounts were born alike. If

Re: Can't juju deploy p2.xlarge in aws/us-east-1

Aaah whaow. I have a default VPC myself, so that may explain the problem Tim is having. Early adopters problem!! -- Samuel Cozannet Cloud, Big Data and IoT Strategy Team Business Development - Cloud and ISV Ecosystem Changing the Future of Cloud Ubuntu / Canonical UK LTD

Re: Can't juju deploy p2.xlarge in aws/us-east-1

A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to `juju bootstrap`, I can now deploy p2 instance types. Thanks Andrew! On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet < samuel.cozan...@canonical.com> wrote: > Aaah whaow. I have a default VPC myself, so that may explain the prob

Juju 2.2-alpha and conjure-up, are here!

A new release of Juju, 2.2-alpha1, and conjure-up, are here! ## What's new in 2.2-alpha1 - juju login ### juju login Juju login command now accepts the name of the public controller as a parameter. juju login jaas This would add the jaas public controller to the list of the controllers

Re: Juju 2.2-alpha and conjure-up, are here!

Please note, that the experience with "juju login jaas" in 2.2-Alpha1 is still quite broken. The login command will add jaas controller to the controllers.yaml, so the next time you'd like to use it, you'll have to do "juju switch jaas" instead of "juju login jaas". We'll improve the experience by

Constraints for Additional Units

Currently, if I scale the units of my application, the new units do not have the same constraints as the previously deployed units. Moreover, it doesn't seem there is anyway to specify constraints for additional units. I'm thinking the 'add-unit' command needs to be able to accept constraints, or c

Re: Constraints for Additional Units

On 17/03/17 14:23, James Beedy wrote: Currently, if I scale the units of my application, the new units do not have the same constraints as the previously deployed units. Well, I certainly think they should be carrying over the constraints as the constraints are set on the application, not the

Re: Constraints for Additional Units

I think I see *my* issue here. I have placed the constraints on the machines (to which the charms are mapped) in my bundle, and not on the actual applications themselves. I guess I shouldn't expect the constraints to be associated with the charms in that case. Does this sound correct? On Thu, Mar

Re: Constraints for Additional Units

Correct. Putting the constraints on the machines is equivalent to doing: juju add-machine --constraints mem=4gb juju deploy mysql --to $MACHINE Rather than doing: juju deploy mysql --constraints mem=4gb Constraints on an Application will affect all new units of an application, but constraint