Juju 2.3.2 is released

2018-01-16 Thread Christian Muirhead 
Juju 2.3.2 has arrived! This is primarily a bug fix release.

## Critical bugs fixed.

Among the bugs fixed two were considered critical.

   -

   1737058  `network-get`
   fails to find valid configs
   -

   1738728  Can’t run `juju
   run` after upgrading


If you were affected by any of the bugs fixed in this release
, your feedback is
appreciated. Please contact the juju team using the communication channels
specified in the feedback section.

## Get juju.

The easiest way to get juju is using the snap package.

snap install juju --classic

## Feedback Appreciated!

We encourage everyone to let us know how you're using Juju. Send us a message
on Twitter using #jujucharms, join us at #juju on freenode, and subscribe
to the mailing list at j...@lists.ubuntu.com.

## More information
To learn more about juju please visit https://jujucharms.com.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.3.2 is released

2018-01-16 Thread Christian Muirhead 
Juju 2.3.2 has arrived! This is primarily a bug fix release.

## Critical bugs fixed.

Among the bugs fixed two were considered critical.

   -

   1737058  `network-get`
   fails to find valid configs
   -

   1738728  Can’t run `juju
   run` after upgrading


If you were affected by any of the bugs fixed in this release
, your feedback is
appreciated. Please contact the juju team using the communication channels
specified in the feedback section.

## Get juju.

The easiest way to get juju is using the snap package.

snap install juju --classic

## Feedback Appreciated!

We encourage everyone to let us know how you're using Juju. Send us a

message on Twitter using #jujucharms, join us at #juju on freenode, and

subscribe to the mailing list at juju@lists.ubuntu.com.

## More information
To learn more about juju please visit https://jujucharms.com.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: JUJU bootstrap error

2017-08-03 Thread Christian Muirhead 
Hi Wahi -
Can you look in the MAAS web UI and confirm that MAAS can see the 4GB of
memory in the machine you expect? I've had a situation where I added ram to
a KVM but forgot to re-enlist the machine or update the ram in MAAS.
Cheers,
Christian

On Thu., 3 Aug. 2017, 19:13 wahi,  wrote:

> Dear all,
>
>
> Recently I am investingating the installation of Openstack using MAAS and
> JUJU.
>
> I installaed MAAS on bare metals server Ubuntu 16.04, I have another
> server also which has Ubuntu 16.04.
>
> I managed to deploy several KVM virtual machines on two servers using
> MAAS, so every VM got private IP address form MAAS.
>
>
> I installed JUJU package on a VM which is located on the second server
> (not MAAS server), from there I did the following steps:
>
> juju add-cloud /here I chose MAAS/
>
> Here: Enter the API endpoint url: http://public_IP_OF_MAAS:5240/MAAS
>
> juju bootstrap maas-cloud
>
> juju clouds /maas-cloud is there/
>
> juju add-credential maas-cloud /Entered the API key/
>
> juju bootstrap maas-cloud maas-cloud-controller
>
> after this command getting
>
> Creating Juju controller "prodmaas-controller" on prodmaas
>
> Looking for packaged Juju agent version 2.0.2 for amd64
>
> Launching controller instance(s) on prodmaas...
>
> ERROR failed to bootstrap model: cannot start bootstrap instance: cannot
> run instances: cannot run instance: No available machine matches
> constraints: [('zone', ['default']), ('agent_name',
> ['f7a273ac-6190-4798-8ee6-f7d2df722b27']), ('mem', ['3584'])] (resolved to
> "mem=3584.0 zone=default")
>
>
> I need to mention that I have a VM on MAAS server with 4GB memory!!! (I
> don’t know if the error related to that)
>
>
> Could you please help me to identify the problem.
>
>
> Thank you very much in advance.
>
>
>
> Regards,
>
> Wahi
> --
> 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

Weekly Development Summary

2017-06-09 Thread Christian Muirhead 
Hi everyone -

It's Friday again! That means it's time for another Juju development
summary, and then the weekend.

Juju 2.2-rc1 was released on Tuesday and rc2 was released today with some
additional bug fixes, and support for loading credentials directly from the
Azure CLI [0]. Team focus has shifted briefly to some issues coming out of
very large Juju deployments. Fixing these bugs will improve stability,
especially in models with large numbers of units.

Key fixes from this effort (with more on the way):
* A field mismatch deleting status history meant that removing units would
cause a lot of load on Mongo [1]
* Rate limiting incoming API connections and log messages on the controller
[2] [3]
* Making the size of the Mongo connection pool configurable [4]
* Collecting more statistics from mgo in Prometheus [5]

Around fixing bugs and handling CI issues for the releases we're continuing
feature work on upgrades from Juju 1.25 to 2.x, cross-model relations, and
more support for persistent storage.

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Cheers!
Christian

[0] https://github.com/juju/juju/pull/7457
[1] https://bugs.launchpad.net/juju/+bug/1696491
[2] https://github.com/juju/juju/pull/7470
[3] https://github.com/juju/juju/pull/7474
[4] https://github.com/juju/juju/pull/7481
[5] https://github.com/juju/juju/pull/7482
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fwd: Big memory usage improvements

2016-10-13 Thread Christian Muirhead 
Oops, meant to reply-all.

-- Forwarded message -
From: Christian Muirhead <christian.muirh...@canonical.com>
Date: Thu, 13 Oct 2016, 09:26
Subject: Re: Big memory usage improvements
To: Katherine Cox-Buday <katherine.cox-bu...@canonical.com>




On Wed, 12 Oct 2016, 22:36 Katherine Cox-Buday, <
katherine.cox-bu...@canonical.com> wrote:

Awesome, good work, Christian!


:)
Thanks for your help with the StatePool!


Not to detract from this fantastic news, but it's still worrisome that an
idle Juju seems to have a memory which is growing linearly (before picture
looked like the beginning of an exponential curve?). Do we feel this is
memory which will at some point be GCed?


No, I think there's still a leak there. The other ones I fixed were
goroutine leaks which were a bit easier to track down. There aren't any
goroutines escaping now so I'll need to switch back to looking at heap
dumps to find more.

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

Re: Big memory usage improvements

2016-10-13 Thread Christian Muirhead 
On Wed, 12 Oct 2016, 21:39 Menno Smits,  wrote:

> Interestingly the MongoDB memory usage profile is quite different as well.
> I'm not sure if this is due to Christian's improvements or something else.
>

Thanks Menno! One of the fixes was a state.State instance being leaked when
the model was destroyed, and that held a Mongo session open which would've
held memory in the mongod process as well.

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

Re: Juju 2.0-rc3 is here!

2016-10-07 Thread Christian Muirhead 
It indicates that that unit is the leader for the application. It's a bit
academic in the status you pasted, since each application only has one
unit, but I can see it being useful if you had scaled out a bit.

Cheers,
Christian

On Fri, Oct 7, 2016 at 5:59 PM Adam Israel 
wrote:

> It looks like rc3 introduced a minor change in the status output. Each
> unit has an asterisk next to its name, i.e., mariadb/0* (full output in
> pastebin). What is the asterisk meant to represent?
>
> http://pastebin.ubuntu.com/23289710/
>
> On Thu, Oct 6, 2016 at 5:28 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical <
> cur...@canonical.com> 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-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> 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-07 Thread Christian Muirhead 
It indicates that that unit is the leader for the application. It's a bit
academic in the status you pasted, since each application only has one
unit, but I can see it being useful if you had scaled out a bit.

Cheers,
Christian

On Fri, Oct 7, 2016 at 5:59 PM Adam Israel 
wrote:

> It looks like rc3 introduced a minor change in the status output. Each
> unit has an asterisk next to its name, i.e., mariadb/0* (full output in
> pastebin). What is the asterisk meant to represent?
>
> http://pastebin.ubuntu.com/23289710/
>
> On Thu, Oct 6, 2016 at 5:28 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical <
> cur...@canonical.com> 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
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> 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: Error while doing bootstrap

2016-09-01 Thread Christian Muirhead 
Hi Rajith -

You need to run that command on the machine that will host your containers
(it doesn't need to be run as root). It configures LXD to listen to HTTPS
traffic on port 8443, so that the connection to LXD from the bootstrapped
controller (inside the container) will succeed. If you run that command and
then bootstrap to LXD it should complete.

Is that enough information?

Cheers,
Christian


On Thu, Sep 1, 2016 at 8:34 AM Rajith P Venkata <rajith...@in.ibm.com>
wrote:

> Hi Christain,
>
> In  bug 1618636, you have mentioned of workaround
>
> The workaround is to run this command to make lxd listen to https:
> lxc config set core.https_address [::]
>
> please give more details, so I can try with workaround
>
>
> Thanks and Regard
>
>
> Rajith
>
>
>
> From:Christian Muirhead <christian.muirh...@canonical.com>
> To:Rajith P Venkata/India/IBM@IBMIN
> Cc:juju@lists.ubuntu.com, Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com>
> Date:31-08-16 01:43 PM
> Subject:Re: Error while doing bootstrap
> --
>
>
>
> I've raised *http://pad.lv/1618636* <http://pad.lv/1618636> for this. I
> can reproduce it using the beta16 from the ppa but not from the beta16 tag
> built from source.
>
> The bug probably needs more logs - what should I add?
>
> On Wed, Aug 31, 2016 at 7:07 AM Rajith P Venkata <*rajith...@in.ibm.com*
> <rajith...@in.ibm.com>> wrote:
> Hi
>
> Error I am getting is different from lp:1605714.   Below error I have
> encountered while bootstraping on juju 2 beta 16.
>
>
> Error details:
>
> tmux is already the newest version (2.1-3build1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Attempt 1 to download tools from
> *https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgz..*
> <https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgz..>
> .
> tools from
> *https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgz*
> <https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgz>downloaded:
> HTTP 200; time 22.641s; size 19586816 bytes; speed 865091.000 bytes/s Tools
> downloaded successfully.
> 5c8364fad79e358cf74713734a421dbd826edefe25c608583911770c75495e08
>  /var/lib/juju/tools/2.0-beta16-xenial-ppc64el/tools.tar.gz
> ff24b22b83734a4c209ea825daa1106976a0001d30d58f1ef93ee07134b8c566
>  /var/lib/juju/gui/gui.tar.bz2
> 2016-08-31 06:03:18 INFO juju.cmd supercommand.go:63 running jujud
> [2.0-beta16 gc go1.6.2]
> 2016-08-31 06:03:18 ERROR cmd supercommand.go:458 creating LXD client: Get
> *https://10.12.56.1:8443/1.0:* <https://10.12.56.1:8443/1.0:>Unable to
> connect to: *10.12.56.1:8443* <http://10.12.56.1:8443/>
> ERROR failed to bootstrap model: subprocess encountered error code 1
>
> Let us know if any other details required.
>
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Cell- 9901966577
> Email: *rajith...@in.ibm.com* <rajith...@in.ibm.com>
>
>
>
> From:Christian Muirhead <*christian.muirh...@canonical.com*
> <christian.muirh...@canonical.com>>
> To:Katherine Cox-Buday <*katherine.cox-bu...@canonical.com*
> <katherine.cox-bu...@canonical.com>>, Rajith P Venkata/India/IBM@IBMIN
> Cc:*juju@lists.ubuntu.com* <juju@lists.ubuntu.com>
> Date:30-08-16 09:05 PM
> Subject:Re: Error while doing bootstrap
> --
>
>
>
> Someone was just asking about the same error in #juju. I can reproduce it
> if I do a bootstrap inside a lxd container (with security.nesting on), with
> either lxd 2.1 or 2.0.4. Trying it with a built-from-source juju doesn't
> give the same error.
>
> On Tue, Aug 30, 2016 at 3:29 PM Katherine Cox-Buday <
> *katherine.cox-bu...@canonical.com* <katherine.cox-bu...@canonical.com>>
> wrote:
> Hey Rajith,
>
> This sounds like lp:1605714, do you agree? Mick (CCed) is currently
> investigating this as his top priority, so hopefully we'll have a fix soon.
>
> "Rajith P Venkata" <*rajith...@in.ibm.com* <rajith...@in.ibm.com>> writes:
>
> > Hi
> >
> > I am installing juju 2.16 on Ubuntu 16.04 power machine: ppc64le.
> > While doing bootstrap getting below error:
> >
> > 2016-08-30 04:40:24 ERROR cmd supercommand.go:458 creating LXD client:
> > Get *https://10.12.56.1:8443/1.0:Unable*
> <https://10.12.56.1:8443/1.0:Unable>to connect to: *10.12.56.1:8443*
> &

Re: Error while doing bootstrap

2016-08-31 Thread Christian Muirhead 
I've raised http://pad.lv/1618636 for this. I can reproduce it using the
beta16 from the ppa but not from the beta16 tag built from source.

The bug probably needs more logs - what should I add?

On Wed, Aug 31, 2016 at 7:07 AM Rajith P Venkata <rajith...@in.ibm.com>
wrote:

> Hi
>
> Error I am getting is different from lp:1605714.   Below error I have
> encountered while bootstraping on juju 2 beta 16.
>
>
> Error details:
>
> tmux is already the newest version (2.1-3build1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Attempt 1 to download tools from
> https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgz..
> .
> tools from
> https://streams.canonical.com/juju/tools/agent/2.0-beta16/juju-2.0-beta16-xenial-ppc64el.tgzdownloaded:
> HTTP 200; time 22.641s; size 19586816 bytes; speed 865091.000 bytes/s Tools
> downloaded successfully.
> 5c8364fad79e358cf74713734a421dbd826edefe25c608583911770c75495e08
>  /var/lib/juju/tools/2.0-beta16-xenial-ppc64el/tools.tar.gz
> ff24b22b83734a4c209ea825daa1106976a0001d30d58f1ef93ee07134b8c566
>  /var/lib/juju/gui/gui.tar.bz2
> 2016-08-31 06:03:18 INFO juju.cmd supercommand.go:63 running jujud
> [2.0-beta16 gc go1.6.2]
> 2016-08-31 06:03:18 ERROR cmd supercommand.go:458 creating LXD client: Get
> https://10.12.56.1:8443/1.0:Unable to connect to: 10.12.56.1:8443
> ERROR failed to bootstrap model: subprocess encountered error code 1
>
> Let us know if any other details required.
>
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> ____
>
> Cell- 9901966577
> Email: rajith...@in.ibm.com
>
>
>
> From:Christian Muirhead <christian.muirh...@canonical.com>
> To:Katherine Cox-Buday <katherine.cox-bu...@canonical.com>,
> Rajith P Venkata/India/IBM@IBMIN
> Cc:juju@lists.ubuntu.com
> Date:30-08-16 09:05 PM
> Subject:Re: Error while doing bootstrap
> --
>
>
>
> Someone was just asking about the same error in #juju. I can reproduce it
> if I do a bootstrap inside a lxd container (with security.nesting on), with
> either lxd 2.1 or 2.0.4. Trying it with a built-from-source juju doesn't
> give the same error.
>
> On Tue, Aug 30, 2016 at 3:29 PM Katherine Cox-Buday <
> *katherine.cox-bu...@canonical.com* <katherine.cox-bu...@canonical.com>>
> wrote:
> Hey Rajith,
>
> This sounds like lp:1605714, do you agree? Mick (CCed) is currently
> investigating this as his top priority, so hopefully we'll have a fix soon.
>
> "Rajith P Venkata" <*rajith...@in.ibm.com* <rajith...@in.ibm.com>> writes:
>
> > Hi
> >
> > I am installing juju 2.16 on Ubuntu 16.04 power machine: ppc64le.
> > While doing bootstrap getting below error:
> >
> > 2016-08-30 04:40:24 ERROR cmd supercommand.go:458 creating LXD client:
> > Get *https://10.12.56.1:8443/1.0:Unable*
> <https://10.12.56.1:8443/1.0:Unable>to connect to: *10.12.56.1:8443*
> <http://10.12.56.1:8443/>
> > ERROR failed to bootstrap model: subprocess encountered error code 1
> >
> > Please fix this issue.
> >
> > Rajith
> >
> > IBM AIX Certified, OCPCertified
> > 
> >
> > Cell- 9901966577
> > Email: *rajith...@in.ibm.com* <rajith...@in.ibm.com>
>
> --
> Katherine
>
> --
> Juju mailing list
> *Juju@lists.ubuntu.com* <Juju@lists.ubuntu.com>
> Modify settings or unsubscribe at:
> *https://lists.ubuntu.com/mailman/listinfo/juju*
> <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: Error while doing bootstrap

2016-08-30 Thread Christian Muirhead 
Someone was just asking about the same error in #juju. I can reproduce it
if I do a bootstrap inside a lxd container (with security.nesting on), with
either lxd 2.1 or 2.0.4. Trying it with a built-from-source juju doesn't
give the same error.

On Tue, Aug 30, 2016 at 3:29 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Hey Rajith,
>
> This sounds like lp:1605714, do you agree? Mick (CCed) is currently
> investigating this as his top priority, so hopefully we'll have a fix soon.
>
> "Rajith P Venkata"  writes:
>
> > Hi
> >
> > I am installing juju 2.16 on Ubuntu 16.04 power machine: ppc64le.
> > While doing bootstrap getting below error:
> >
> > 2016-08-30 04:40:24 ERROR cmd supercommand.go:458 creating LXD client:
> > Get https://10.12.56.1:8443/1.0:Unable to connect to: 10.12.56.1:8443
> > ERROR failed to bootstrap model: subprocess encountered error code 1
> >
> > Please fix this issue.
> >
> > Rajith
> >
> > IBM AIX Certified, OCPCertified
> > 
> >
> > Cell- 9901966577
> > Email: rajith...@in.ibm.com
>
> --
> Katherine
>
> --
> 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: The CI build time continue to rise alarmingly

2016-06-08 Thread Christian Muirhead 
Hi Torsten -

That fix shouldn't have increased build times unless we also changed the
test run to be against Mongo 3.2. If builds are still against 2.4 then the
change will have made them slightly faster (because we only drop and
recreate the database at the suite level).

I don't think we've switched runs to be against 3.2 because there were
other problems that were unrelated to the slow state tests - these two that
I know about:
https://bugs.launchpad.net/juju-core/+bug/1588784
https://bugs.launchpad.net/juju-core/+bug/1573286

Cheers,
Christian


On Wed, 8 Jun 2016, 16:06 Torsten Baumann, 
wrote:

> Hi David,
>
> Thanks for raising the inefficiency.
>
> From what I understand there was a change introduced in and around June
> 1st for https://bugs.launchpad.net/juju-core/+bug/1573294 that may have
> increased the time again. :-( As regrettable as this is we did review this
> with the tech board and it was accepted as part of the fix.
>
>
> I discussed with a few people and there is some time we can shave off on
> the tarball assembly (2-4 minutes) if we spent a few days work there.
>
> I also believe we can save time if we ran the tests in LXC containers but
> there may be some reliability issues there. we can always switch the jobs
> to use lxc and see what happens?
>
> Other than that I am open to seeing who else on this list has ideas as to
> what we can do to reduce the time? I would rather we go after the most
> important ones first if we can identify them.
>
> thanks everyone,
>
> Torsten
>
>
>
> -- Forwarded message --
> From: David Cheney 
> Date: Thu, Jun 2, 2016 at 9:49 PM
> Subject: The CI build time continue to rise alarmingly
> To: "juju-dev@lists.ubuntu.com" 
>
>
> CI build times are now an average of 36 minutes. That means in a
> typical 8 hour work day, assuming doing nothing other than landing
> branches, less than 16 commits can be landed.
>
> While bugs can be worked on and reviewed in parallel, landing is a
> sequential action that blocks everyone, and given the landing bot is
> batting less than 0.500, this limits the practical number of changes
> that can be landed in a day, a sprint, a iteration, or a development
> cycle.
>
> I cannot make it any clearer than this, the speed of CI limits the
> velocity of this team.
>
> Dave
>
> --
> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

2016-05-18 Thread Christian Muirhead 
Yeah, I think so too - it seems like one of those performance bugs where
the fix would be obvious to someone familiar with the codebase. But the
response to Gustavo's bug (from October!) didn't give me much hope of it
being fixed very soon.

On Wed, May 18, 2016 at 11:36 AM David Cheney <david.che...@canonical.com>
wrote:

> This feels like a bug in mongodb. We store approximately zero data in
> mongodb during test runs -- seriously, one machine, a charm at most,
> that's it. It mongodb has such amazingly high overheads just start to
> store data that sounds like a serious problem that is being ignored.
>
> On Wed, May 18, 2016 at 7:32 PM, Christian Muirhead
> <christian.muirh...@canonical.com> wrote:
> > WiredTiger is *much* slower at creating and dropping indexes and
> > collections. I haven't worked out why that is, other than doing some
> > stracing and seeing that a lot of time is spent in fdatasync - I haven't
> dug
> > into the mongo source code.
> > There's a bit more detail in these bugs:
> > https://bugs.launchpad.net/juju-core/+bug/1573294
> > https://jira.mongodb.org/browse/SERVER-21198
> >
> > I've changed the tests so that instead of dropping and recreating
> databases
> > in teardown and setup we clear out all of the collections (except the
> > transaction collections) between tests. Obviously that's worse from the
> > perspective of test isolation, but it seems to work well - better than I
> was
> > expecting, to be honest.
> >
> > Cheers,
> > Christian
> >
> > On Wed, May 18, 2016 at 9:58 AM roger peppe <roger.pe...@canonical.com>
> > wrote:
> >>
> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> >> speed it up again?
> >>
> >> On 18 May 2016 09:51, "Christian Muirhead"
> >> <christian.muirh...@canonical.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 18, 2016 at 2:04 AM David Cheney <
> david.che...@canonical.com>
> >>> wrote:
> >>>>
> >>>> 100x more webscale
> >>>
> >>> Ha!
> >>>
> >>> I'm *just about* finished the hack to make the state tests on 3.2 run
> in
> >>> about the same time as on 2.4. On my machine the state tests take
> 6m24s on
> >>> 3.2 and the old version took 4m56s. Which is still worse,
> unfortunately, but
> >>> at least it isn't 100x worse. So if there are stability benefits to
> running
> >>> the tests on 3.2 it's still a win, I guess?
> >>>
> >>>
> >>>>
> >>>>
> >>>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
> >>>> <horacio.du...@canonical.com> wrote:
> >>>> > For now we are trying to go around mongo issues that make the tests
> >>>> > 100x
> >>>> > slower (yes one hundred) once this is fixed we should start using
> >>>> > mongo 3.2
> >>>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
> >>>> > storage
> >>>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
> >>>> > nearing EOL
> >>>> > I am currently on the phone but if You want more details I can dig
> up
> >>>> > the
> >>>> > bug with details of what I am talking about.
> >>>> >
> >>>> >
> >>>> > On Tuesday, 17 May 2016, David Cheney <david.che...@canonical.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
> >>>> >> versions for the foreseeable future, or is there a possibility to
> >>>> >> make
> >>>> >> it a build or run time failure if mongo < 3.2 is installed on the
> >>>> >> host
> >>>> >> ?
> >>>> >>
> >>>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
> >>>> >> <martin.pack...@canonical.com> wrote:
> >>>> >> > On 17/05/2016, Curtis Hovey-Canonical <cur...@canonical.com>
> wrote:
> >>>> >> >>
> >>>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
> >>>> >> >> xenial
> >>>> >> >> and without other changes, 2.4 will be used by all other 1.25
> >>>> >> >> series.
> >>>

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

2016-05-18 Thread Christian Muirhead 
Michael, thanks for all the clear info in the bugs by the way!

I also got good results from running the tests under tmpfs - the 3.2 run
was almost acceptably fast. But obviously it's not practical to require
every machine running the tests to have a tmpfs mounted (or somehow mount
one in the test run).

On Wed, May 18, 2016 at 10:36 AM Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> On 18 May 2016 at 21:32, Christian Muirhead
> <christian.muirh...@canonical.com> wrote:
> > WiredTiger is *much* slower at creating and dropping indexes and
> > collections. I haven't worked out why that is, other than doing some
> > stracing and seeing that a lot of time is spent in fdatasync - I haven't
> dug
> > into the mongo source code.
>
> Yeah, this is what I concluded too. I tried running mongo under
> eatmydata but it didn't work for reasons I didn't get around to
> understanding. I even built a mongo with the fdatasync call commented
> out but then I moved onto other things...
>
> Cheers,
> mwh
>
> > There's a bit more detail in these bugs:
> > https://bugs.launchpad.net/juju-core/+bug/1573294
> > https://jira.mongodb.org/browse/SERVER-21198
> >
> > I've changed the tests so that instead of dropping and recreating
> databases
> > in teardown and setup we clear out all of the collections (except the
> > transaction collections) between tests. Obviously that's worse from the
> > perspective of test isolation, but it seems to work well - better than I
> was
> > expecting, to be honest.
> >
> > Cheers,
> > Christian
> >
> > On Wed, May 18, 2016 at 9:58 AM roger peppe <roger.pe...@canonical.com>
> > wrote:
> >>
> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> >> speed it up again?
> >>
> >> On 18 May 2016 09:51, "Christian Muirhead"
> >> <christian.muirh...@canonical.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 18, 2016 at 2:04 AM David Cheney <
> david.che...@canonical.com>
> >>> wrote:
> >>>>
> >>>> 100x more webscale
> >>>
> >>> Ha!
> >>>
> >>> I'm *just about* finished the hack to make the state tests on 3.2 run
> in
> >>> about the same time as on 2.4. On my machine the state tests take
> 6m24s on
> >>> 3.2 and the old version took 4m56s. Which is still worse,
> unfortunately, but
> >>> at least it isn't 100x worse. So if there are stability benefits to
> running
> >>> the tests on 3.2 it's still a win, I guess?
> >>>
> >>>
> >>>>
> >>>>
> >>>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
> >>>> <horacio.du...@canonical.com> wrote:
> >>>> > For now we are trying to go around mongo issues that make the tests
> >>>> > 100x
> >>>> > slower (yes one hundred) once this is fixed we should start using
> >>>> > mongo 3.2
> >>>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
> >>>> > storage
> >>>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
> >>>> > nearing EOL
> >>>> > I am currently on the phone but if You want more details I can dig
> up
> >>>> > the
> >>>> > bug with details of what I am talking about.
> >>>> >
> >>>> >
> >>>> > On Tuesday, 17 May 2016, David Cheney <david.che...@canonical.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
> >>>> >> versions for the foreseeable future, or is there a possibility to
> >>>> >> make
> >>>> >> it a build or run time failure if mongo < 3.2 is installed on the
> >>>> >> host
> >>>> >> ?
> >>>> >>
> >>>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
> >>>> >> <martin.pack...@canonical.com> wrote:
> >>>> >> > On 17/05/2016, Curtis Hovey-Canonical <cur...@canonical.com>
> wrote:
> >>>> >> >>
> >>>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
> >>>> >> >> xenial
> >>>> >> >> and without other changes, 2.4 will be used by all other 1.25
&g

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

2016-05-18 Thread Christian Muirhead 
WiredTiger is *much* slower at creating and dropping indexes and
collections. I haven't worked out why that is, other than doing some
stracing and seeing that a lot of time is spent in fdatasync - I haven't
dug into the mongo source code.
There's a bit more detail in these bugs:
https://bugs.launchpad.net/juju-core/+bug/1573294
https://jira.mongodb.org/browse/SERVER-21198

I've changed the tests so that instead of dropping and recreating databases
in teardown and setup we clear out all of the collections (except the
transaction collections) between tests. Obviously that's worse from the
perspective of test isolation, but it seems to work well - better than I
was expecting, to be honest.

Cheers,
Christian

On Wed, May 18, 2016 at 9:58 AM roger peppe <roger.pe...@canonical.com>
wrote:

> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> speed it up again?
> On 18 May 2016 09:51, "Christian Muirhead" <
> christian.muirh...@canonical.com> wrote:
>
>>
>>
>> On Wed, May 18, 2016 at 2:04 AM David Cheney <david.che...@canonical.com>
>> wrote:
>>
>>> 100x more webscale
>>>
>> Ha!
>>
>> I'm *just about* finished the hack to make the state tests on 3.2 run in
>> about the same time as on 2.4. On my machine the state tests take 6m24s on
>> 3.2 and the old version took 4m56s. Which is still worse, unfortunately,
>> but at least it isn't 100x worse. So if there are stability benefits to
>> running the tests on 3.2 it's still a win, I guess?
>>
>>
>>
>>>
>>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
>>> <horacio.du...@canonical.com> wrote:
>>> > For now we are trying to go around mongo issues that make the tests
>>> 100x
>>> > slower (yes one hundred) once this is fixed we should start using
>>> mongo 3.2
>>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
>>> storage
>>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
>>> nearing EOL
>>> > I am currently on the phone but if You want more details I can dig up
>>> the
>>> > bug with details of what I am talking about.
>>> >
>>> >
>>> > On Tuesday, 17 May 2016, David Cheney <david.che...@canonical.com>
>>> wrote:
>>> >>
>>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
>>> >> versions for the foreseeable future, or is there a possibility to make
>>> >> it a build or run time failure if mongo < 3.2 is installed on the host
>>> >> ?
>>> >>
>>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
>>> >> <martin.pack...@canonical.com> wrote:
>>> >> > On 17/05/2016, Curtis Hovey-Canonical <cur...@canonical.com> wrote:
>>> >> >>
>>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
>>> xenial
>>> >> >> and without other changes, 2.4 will be used by all other 1.25
>>> series.
>>> >> >
>>> >> > This isn't yet true, there's a bug open for it:
>>> >> >
>>> >> > "Use juju-mongodb2.6 for 1.25 on xenial"
>>> >> > <https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1570650>
>>> >> >
>>> >> > I had made the packaging change, but without juju code changes as
>>> well
>>> >> > it just went and installed the old (2.4) juju-mongodb anyway when
>>> >> > setting up a state server.
>>> >> >
>>> >> > Martin
>>> >> >
>>> >> > --
>>> >> > 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
>>>
>>> --
>>> 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
>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev