Re: Juju 2.0-rc3 is here!

2016-10-06 Thread Andrew Wilkins 
On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical 
wrote:

> A new development release of Juju, 2.0-rc3, is here!
>
>
> ## What's new?
>
> * For an AWS VPC account juju will create a t2.medium for controller
>   instances by default now. Non-controller instances are unchanged for
>   now, and remain m3.medium by default. Controller instance root disk
>   now defaults to 32GiB, but can be overridden with constraints.
> * Shorten the hostnames we apply to instances created by the OpenStack
>   provider.
> Example old hostname:
> juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14
>
> Example new hostname:
> Juju-df7591-controller-0
> * Added support for LXD 2.3 apis
> * New update-credential command
> * Added --model-default option to the bootstrap
> * LXD containers now have proper hostnames set
>

Also, support for the aws/ap-south-1 region has been added.

Adam Stokes just found a bug related to this, which prevented him from
being able to destroy his rc2 controller with an rc3 client. I'll fix this
for 2.0, but in the mean time I recommend you destroy your controller
before upgrading the client.

If you do upgrade the client, then you will need to modify
~/.local/share/juju/bootstrap-config.yaml, fixing the endpoint cached in
there. You can find the correct value by running "juju show-cloud aws", and
picking out the value associated with the region you bootstrapped.

Cheers,
Andrew


> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
> sudo add-apt-repository ppa:juju/devel
> sudo apt-get update; sudo apt-get install juju-2.0
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0-rc3
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing the
> release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-rc3 is here!

2016-10-06 Thread Andrew Wilkins 
On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical 
wrote:

> A new development release of Juju, 2.0-rc3, is here!
>
>
> ## What's new?
>
> * For an AWS VPC account juju will create a t2.medium for controller
>   instances by default now. Non-controller instances are unchanged for
>   now, and remain m3.medium by default. Controller instance root disk
>   now defaults to 32GiB, but can be overridden with constraints.
> * Shorten the hostnames we apply to instances created by the OpenStack
>   provider.
> Example old hostname:
> juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14
>
> Example new hostname:
> Juju-df7591-controller-0
> * Added support for LXD 2.3 apis
> * New update-credential command
> * Added --model-default option to the bootstrap
> * LXD containers now have proper hostnames set
>

Also, support for the aws/ap-south-1 region has been added.

Adam Stokes just found a bug related to this, which prevented him from
being able to destroy his rc2 controller with an rc3 client. I'll fix this
for 2.0, but in the mean time I recommend you destroy your controller
before upgrading the client.

If you do upgrade the client, then you will need to modify
~/.local/share/juju/bootstrap-config.yaml, fixing the endpoint cached in
there. You can find the correct value by running "juju show-cloud aws", and
picking out the value associated with the region you bootstrapped.

Cheers,
Andrew


> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
> sudo add-apt-repository ppa:juju/devel
> sudo apt-get update; sudo apt-get install juju-2.0
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0-rc3
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing the
> release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Canonical Distribution of Kubernetes - Update Release Notes (16.10 cycle)

2016-10-06 Thread Adam Stokes 
Nice! One question though maybe I'm missing something but I didn't see
where the conjure-up instructions were shown on the jujucharms.com page?
https://jujucharms.com/canonical-kubernetes/ It is in the README though
https://github.com/juju-solutions/bundle-canonical-kubernetes/blob/master/README.md#interactive-deployment-using-conjure-up
so
I'm not sure if it's a caching issue or not?

On Thu, Oct 6, 2016 at 8:07 PM Charles Butler 
wrote:

> @mbruzek and I worked on the Canonical Distribution of Kubernetes this
> week. There are still quite a few work items in flight, but let’s focus on
> what made the early release today:
>
> Kubernetes Master
>
>
>-
>
>Normalized the end user messaging displayed during cluster operations
>(full stops, grammar).
>-
>
>Added more debug logging output making it clearer to trace problems as
>to the order of what was happening.
>
>
> Kubernetes Worker
>
>
>-
>
>Fixed status message so “Kubelet waiting to start” is not the last
>message.
>-
>
>Added debug logging output making it clearer to trace problems as to
>the order of what was happening.
>-
>
>Adjusted the kubelet systemd template to kill process-groups vs
>‘parent process’ which was orphaning inotify threads, exhausting the system
>of open files. (thanks @cynerva and @ryebot)
>-
>
>Removed the SDN Logic from the top most kubernetes-worker layer, into
>the layer-docker to ensure encapsulation.
>-
>
>Used ‘data_changed’ to prevent excessive restarts of the kubelet and
>kube-proxy processes.
>
>
>
> Flannel
>
>
>-
>
>Fixed a failing operation in flannel when it was attempting to remove
>files that had already been deleted.
>
>
>
> CDK Bundle
>
>
>-
>
>Updated the version the changed charms to their latest stable
>beta-releases.
>- Updated the Conjure-Up section in the README (thanks @mmc)
>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your application | www.jujucharms.com
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Canonical Distribution of Kubernetes - Update Release Notes (16.10 cycle)

2016-10-06 Thread Charles Butler 
@mbruzek and I worked on the Canonical Distribution of Kubernetes this
week. There are still quite a few work items in flight, but let’s focus on
what made the early release today:

Kubernetes Master


   -

   Normalized the end user messaging displayed during cluster operations
   (full stops, grammar).
   -

   Added more debug logging output making it clearer to trace problems as
   to the order of what was happening.


Kubernetes Worker


   -

   Fixed status message so “Kubelet waiting to start” is not the last
   message.
   -

   Added debug logging output making it clearer to trace problems as to the
   order of what was happening.
   -

   Adjusted the kubelet systemd template to kill process-groups vs ‘parent
   process’ which was orphaning inotify threads, exhausting the system of open
   files. (thanks @cynerva and @ryebot)
   -

   Removed the SDN Logic from the top most kubernetes-worker layer, into
   the layer-docker to ensure encapsulation.
   -

   Used ‘data_changed’ to prevent excessive restarts of the kubelet and
   kube-proxy processes.



Flannel


   -

   Fixed a failing operation in flannel when it was attempting to remove
   files that had already been deleted.



CDK Bundle


   -

   Updated the version the changed charms to their latest stable
   beta-releases.
   - Updated the Conjure-Up section in the README (thanks @mmc)

-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming changes for the ec2 provider

2016-10-06 Thread Mark Shuttleworth 
On 06/10/16 16:14, Andrew Wilkins wrote:
> On Thu, Oct 6, 2016 at 8:30 PM Rick Harding
> > wrote:
>
> Thanks Andrew, this is great to hear. Can I bug you about details
> as to how it works? Does this introduce their pricing API as a
> blocker to deploying with Juju? If they introduce a change to the
> API we miss or their API goes down is there any sort of cache of
> the info that users can continue with until service is restored?
>
>
> So I said API because that's what it's called by AWS, but IMO it's a
> bit of an overstatement. It's just a set of (very large) JSON files in
> a well defined location. Very large, as in 48M for the one file that
> we need.
>
> Because it's so big, pulling that down each time you go to bootstrap
> isn't really reasonable. So for now, we're doing that at build time,
> and the information is still hard coded into the client. The process
> can be automated, so there shouldn't be a great lag time between
> updates and bringing them into a Juju release.
>
> We intend to update Juju later to periodically pull down the JSON file
> server-side, asynchronously, so a running controller will get the
> updates without us having to release a new Juju or you having to upgrade.

Could we not process the file on our side regularly and publish a
(smaller) just-what-juju-needs bit of json at a well-known location
ourselves?

Mark
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 2.0-rc3 is here!

2016-10-06 Thread Curtis Hovey-Canonical 
A new development release of Juju, 2.0-rc3, is here!


## What's new?

* For an AWS VPC account juju will create a t2.medium for controller
  instances by default now. Non-controller instances are unchanged for
  now, and remain m3.medium by default. Controller instance root disk
  now defaults to 32GiB, but can be overridden with constraints.
* Shorten the hostnames we apply to instances created by the OpenStack
  provider.
Example old hostname:
juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14

Example new hostname:
Juju-df7591-controller-0
* Added support for LXD 2.3 apis
* New update-credential command
* Added --model-default option to the bootstrap
* LXD containers now have proper hostnames set


## How do I get it?

If you are running Ubuntu, you can get it from the juju devel ppa:

sudo add-apt-repository ppa:juju/devel
sudo apt-get update; sudo apt-get install juju-2.0

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0-rc3


## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
juju@lists.ubuntu.com and join us on #juju on freenode. We would love to hear
your feedback and usage of juju.


## Anything else?

You can read more information about what's in this release by viewing the
release notes here:

https://jujucharms.com/docs/devel/temp-release-notes


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: maas grub issue

2016-10-06 Thread Matt Rae 
Hi Daniel, if the HP servers have iLO, they are often able to use the IPMI
power setting with IPMI_2_0.

I've seen some older versions of iLO seem to require using the "HP Moonshot
iLO4 (IPMI)" power setting. But after updating those same servers to the
latest version of iLO, the normal IPMI power setting seems to be more
reliable.

For servers that don't support IPMI, you could use the MANUAL power
setting. In that case you would power the node on manually when
commissioning and deploying. Additionally MAAS 2.0 has support for several
smart PDUs. If you use a smart PDU, MAAS can connect to the PDU and power
on the particular plug the server is plugged into.

Matt


On Thu, Oct 6, 2016 at 8:39 AM, Daniel Bidwell  wrote:

> I forgot the cross-post to maas-devel until after I sent this one and
> sent it there also.
>
> I have some older servers in my test cluster that will only do
> wakeonlan and not ipmi.  I was told that wakeonlan was no longer
> available in maas 2.0 and was trying to keep my test cluster on the
> same software as my production cluster.  The old servers are HP DL-
> 180's and they only do wakeonlan and something that I have been lead to
> believe is proprietary.  I would love to be wrong about the wakeonlan
> and maas 2.0 though.
>
> On Thu, 2016-10-06 at 08:22 -0700, Mark Shuttleworth wrote:
> > 'scuse the cross-post but I think you'll get a faster answer from
> > maas-devel. I'll start by asking if you've tried MAAS 2.0?
> >
> > Mark
> >
> > On 06/10/16 08:18, Daniel Bidwell wrote:
> > >
> > > I have a maas-1.9.4 with servers with 4 2T disks for data storage
> > > and a
> > > 120GB disk on an onboard controller for the system disk.  Maas is
> > > deploying ubuntu 16.04 on the servers.  Ubuntu 16.04 labels the
> > > 120GB
> > > system disk as /dev/sde, not /dev/sda.  In maas I can define the
> > > /sdev/sde disk as the system disk.
> > >
> > > juju bootstrap deploys the system and installs the OS on /dev/sde1
> > > but
> > > fails to write the grub record to /dev/sde and leaves the disk
> > > unbootable.  The system fails over to booting from an ephemeral
> > > iscsi
> > > file system where I can examine the state of the machine.
> > >
> > > The disk is formated with a GPT partition table which grub will not
> > > write to unless I manually create a small partition as partition 1
> > > with
> > > blocks from 34-2047 and the system partition as partition 2.
> > >
> > > This manual step really not acceptable for deploying from juju and
> > > maas.
> > >
> > > How do I get maas to deploy the system in a way that it will boot
> > > without manual editing?
> >
> >
> --
> Daniel Bidwell 
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

RE: Juju state as code?

2016-10-06 Thread Greg Mason 
Patrik Karisch wrote:
> Hi there,
> 
> one thing which mocks my head, when evaluating Juju is, the state is only
> in the controller which gets deployed with commands. Which means I have
> IMHO no docs/history of how my current state of machines and charms was
> constructed?
> 
> As a side note: I'm used to Ansible and Puppet, which means I have all my
> infrastructe in a Git repository which describes my whole infrastructure
> and works always in a reproducable and idempotent way. How can I map this
> concept to Juju? I fear a little bit to loose this automation concept while
> using Juju.
> 
> Best regards,
> Patrik

Hi Patrik,

If you're looking for a repeatable way to deploy and test juju 
models/environments, you can also take a look at Mojo: 
https://mojo.canonical.com/

It allows you deploy specific versions of your code and charms, then run a 
specified set of tests after deployment. We use Mojo to deploy a large number 
of our juju environments. We test the deploy with Jenkins, and then (provided 
the CI deploy/test passes) deploy that commit/revision of the mojo spec to 
production. It's a good way to see how reproducible your environment is.

-Greg


--
Greg Mason
Cloud Reliability Engineer - Bootstack
Canonical, Ltd

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: maas grub issue

2016-10-06 Thread Daniel Bidwell 
I forgot the cross-post to maas-devel until after I sent this one and
sent it there also.

I have some older servers in my test cluster that will only do
wakeonlan and not ipmi.  I was told that wakeonlan was no longer
available in maas 2.0 and was trying to keep my test cluster on the
same software as my production cluster.  The old servers are HP DL-
180's and they only do wakeonlan and something that I have been lead to
believe is proprietary.  I would love to be wrong about the wakeonlan
and maas 2.0 though.

On Thu, 2016-10-06 at 08:22 -0700, Mark Shuttleworth wrote:
> 'scuse the cross-post but I think you'll get a faster answer from
> maas-devel. I'll start by asking if you've tried MAAS 2.0?
> 
> Mark
> 
> On 06/10/16 08:18, Daniel Bidwell wrote:
> > 
> > I have a maas-1.9.4 with servers with 4 2T disks for data storage
> > and a
> > 120GB disk on an onboard controller for the system disk.  Maas is
> > deploying ubuntu 16.04 on the servers.  Ubuntu 16.04 labels the
> > 120GB
> > system disk as /dev/sde, not /dev/sda.  In maas I can define the
> > /sdev/sde disk as the system disk.
> > 
> > juju bootstrap deploys the system and installs the OS on /dev/sde1
> > but
> > fails to write the grub record to /dev/sde and leaves the disk
> > unbootable.  The system fails over to booting from an ephemeral
> > iscsi
> > file system where I can examine the state of the machine.
> > 
> > The disk is formated with a GPT partition table which grub will not
> > write to unless I manually create a small partition as partition 1
> > with
> > blocks from 34-2047 and the system partition as partition 2.
> > 
> > This manual step really not acceptable for deploying from juju and
> > maas.
> > 
> > How do I get maas to deploy the system in a way that it will boot
> > without manual editing?
> 
> 
-- 
Daniel Bidwell 


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: maas grub issue

2016-10-06 Thread Mark Shuttleworth 

'scuse the cross-post but I think you'll get a faster answer from
maas-devel. I'll start by asking if you've tried MAAS 2.0?

Mark

On 06/10/16 08:18, Daniel Bidwell wrote:
> I have a maas-1.9.4 with servers with 4 2T disks for data storage and a
> 120GB disk on an onboard controller for the system disk.  Maas is
> deploying ubuntu 16.04 on the servers.  Ubuntu 16.04 labels the 120GB
> system disk as /dev/sde, not /dev/sda.  In maas I can define the
> /sdev/sde disk as the system disk.
>
> juju bootstrap deploys the system and installs the OS on /dev/sde1 but
> fails to write the grub record to /dev/sde and leaves the disk
> unbootable.  The system fails over to booting from an ephemeral iscsi
> file system where I can examine the state of the machine.
>
> The disk is formated with a GPT partition table which grub will not
> write to unless I manually create a small partition as partition 1 with
> blocks from 34-2047 and the system partition as partition 2.
>
> This manual step really not acceptable for deploying from juju and
> maas.
>
> How do I get maas to deploy the system in a way that it will boot without 
> manual editing?





signature.asc
Description: OpenPGP digital signature
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

maas grub issue

2016-10-06 Thread Daniel Bidwell 
I have a maas-1.9.4 with servers with 4 2T disks for data storage and a
120GB disk on an onboard controller for the system disk.  Maas is
deploying ubuntu 16.04 on the servers.  Ubuntu 16.04 labels the 120GB
system disk as /dev/sde, not /dev/sda.  In maas I can define the
/sdev/sde disk as the system disk.

juju bootstrap deploys the system and installs the OS on /dev/sde1 but
fails to write the grub record to /dev/sde and leaves the disk
unbootable.  The system fails over to booting from an ephemeral iscsi
file system where I can examine the state of the machine.

The disk is formated with a GPT partition table which grub will not
write to unless I manually create a small partition as partition 1 with
blocks from 34-2047 and the system partition as partition 2.

This manual step really not acceptable for deploying from juju and
maas.

How do I get maas to deploy the system in a way that it will boot
without manual editing?
-- 
Daniel Bidwell 


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming changes for the ec2 provider

2016-10-06 Thread Rick Harding 
Thanks Andrew, this is great to hear. Can I bug you about details as to how
it works? Does this introduce their pricing API as a blocker to deploying
with Juju? If they introduce a change to the API we miss or their API goes
down is there any sort of cache of the info that users can continue with
until service is restored?



On Thu, Oct 6, 2016 at 4:52 AM Andrew Wilkins 
wrote:

> Hi folks,
>
> Just a heads up to let you know about some changes made to the ec2
> provider, which will show up in Juju 2.0.
>
> We are now pulling down the Price List API (
> http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html)
> and using that to determine which instance types to launch. This means that
> you will have access to more instance types now, and we should have more
> accurate/up-to-date pricing information, and region availability.
>
> The default constraints for controllers has been modified, so that on ec2
> we will now default controller machines to t2.medium, as long as you have a
> default VPC in your region, or you specify one by ID (--config vpc-id=...).
> We were previously defaulting to m3.medium. The t2.medium instances have a
> little more memory, and 2 CPUs instead of 1. They are burstable instances,
> so they should suit controllers managing a small-to-medium set of
> applications. Controllers are now started with 32GiB root disk, instead of
> 8GiB as they were before.
>
> As before, you can override the defaults by specifying constraints at
> bootstrap time. Also, these changes do not affect non-controller instances.
> If you use "add-machine", you will get an m3.medium if your region supports
> them.
>
> Cheers,
> Andrew
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju state as code?

2016-10-06 Thread Merlijn Sebrechts 
Hi Patrik


Welcome to the Juju community, and thanks for the great question!

I see the bundle as a way to "save" the state of a model you constructed. A
bundle specifies a bunch of charms, their versions, their relations, and
their config values. You can find more info on bundles here:
https://jujucharms.com/docs/2.0/charms-bundles.

You can use the Juju GUI to create a bundle from the running model. You can
then redeploy that bundle whenever you need that model. Deploying bundles
can be done using command line tools or from the Juju GUI. The bundle is
just a yaml file so it's easy to put it in git and edit it yourself.

Does this answer your question?



Kind regards
Merlijn

2016-10-06 10:28 GMT+02:00 Patrik Karisch :

> Hi there,
>
> one thing which mocks my head, when evaluating Juju is, the state is only
> in the controller which gets deployed with commands. Which means I have
> IMHO no docs/history of how my current state of machines and charms was
> constructed?
>
> As a side note: I'm used to Ansible and Puppet, which means I have all my
> infrastructe in a Git repository which describes my whole infrastructure
> and works always in a reproducable and idempotent way. How can I map this
> concept to Juju? I fear a little bit to loose this automation concept while
> using Juju.
>
> Best regards,
> Patrik
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming changes for the ec2 provider

2016-10-06 Thread Andrew Wilkins 
Hi folks,

Just a heads up to let you know about some changes made to the ec2
provider, which will show up in Juju 2.0.

We are now pulling down the Price List API (
http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html)
and using that to determine which instance types to launch. This means that
you will have access to more instance types now, and we should have more
accurate/up-to-date pricing information, and region availability.

The default constraints for controllers has been modified, so that on ec2
we will now default controller machines to t2.medium, as long as you have a
default VPC in your region, or you specify one by ID (--config vpc-id=...).
We were previously defaulting to m3.medium. The t2.medium instances have a
little more memory, and 2 CPUs instead of 1. They are burstable instances,
so they should suit controllers managing a small-to-medium set of
applications. Controllers are now started with 32GiB root disk, instead of
8GiB as they were before.

As before, you can override the defaults by specifying constraints at
bootstrap time. Also, these changes do not affect non-controller instances.
If you use "add-machine", you will get an m3.medium if your region supports
them.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju state as code?

2016-10-06 Thread Patrik Karisch 
Hi there,

one thing which mocks my head, when evaluating Juju is, the state is only
in the controller which gets deployed with commands. Which means I have
IMHO no docs/history of how my current state of machines and charms was
constructed?

As a side note: I'm used to Ansible and Puppet, which means I have all my
infrastructe in a Git repository which describes my whole infrastructure
and works always in a reproducable and idempotent way. How can I map this
concept to Juju? I fear a little bit to loose this automation concept while
using Juju.

Best regards,
Patrik
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju