Re: We are pulling he 2.3.6 agents

[Nicholas Skaggs]

All 2.3.6 binaries should now be removed from distribution. The snap 
should refresh to 2.3.5 if you have the 2.3.6 binary.


Thanks,

Nicholas

On 04/23/2018 10:06 AM, Adam Israel wrote:

Hi all,

What wasn't clear to me from the email is that, with 2.3.6 pulled, 
we're unable to bootstrap new controllers without providing an 
alternate agent-stream, i.e., --agent-stream=proposed.


In future cases like this, is it feasible to roll back the snap to the 
previous version, so new installs work as expected?


On Sun, Apr 22, 2018 at 11:43 PM Tim Penhey > wrote:


Hey people,

We have field reports where a 2.3.6 upgrade interacted badly with some
charm settings causing Juju to get itself into a stuck, somewhat
corrupt
state. We are still evaluating how to fix this for stuck systems.

The symptom is the 2.3.6 upgrade fails and gets stuck.

The agents are being removed from streams to stop people accidentally
upgrading to a broken version, even though this breakage doesn't
impact
everyone.

We are also looking into the continuous integration tests around our
upgrades for extra testing to catch other issues like this one.

We will be releasing 2.3.7 shortly to address this isue.

Thanks for your patience.
Tim


-- 
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 2.4-beta1 is released

[Nicholas Skaggs]

A new development release of Juju is here, 2.4-beta1. Those wishing to 
utilize bionic for controllers should target and plan to use the 2.4 
series of juju.



## New and Improved


* Model owner changes

The concept of model owner is becoming obsolete. Model owner is just 
another model user with administrative access. We are working to remove 
any special access that the model owner has, and move to having the 
models in a namespace rather than grouped by owner.



* Charm goal state

Charm goal state allows charms to discover relevant information about 
their deployment. The key pieces of information a charm needs to 
discover are:


 *

   what other peer units have been deployed and their status

 *

   what remote units exist on the other end of each endpoint, and their
   status


Charms use a new goal-state hook command to query the information about 
their deployment. This hook command will print only yaml or json output 
(default yaml):



$ goal-state --format yaml


The output will be a subset of that produced by the juju status command. 
There will be output for sibling (peer) units and relation state per unit.



The unitstatus values are the workload status of the (sibling) peer 
units. We also use a unit status value of dyingwhen the unit's life 
becomes dying. Thus unit status is one of:


 *

   allocating

 *

   active

 *

   waiting

 *

   blocked

 *

   error

 *

   dying


The relationstatus values are determined per unit and depend on whether 
the unit has entered or left scope. The possible values are:


 *

   joining(relation created but unit not yet entered scope)

 *

   joined(unit has entered scope and relation is active)

 *

   broken(unit has left, or is preparing to leave scope)

 *

   suspended(parent cross model relation is suspended)

 *

   error


By reporting error state, the charm has a chance to determine that goal 
state may not be reached due to some external cause. As with status, we 
will report the time since the status changed to allow the charm to 
empirically guess that a peer may have become stuck if it has not yet 
reached active state.



* Controllers and remove-machine updates

 *

   It is now possible to `juju remove-machine` a controller machine. As
   long as there is another controller, we will gracefully shut down
   the existing machine, and remove it from the HA set (of mongo, raft,
   and juju API servers).

 *

   It is also possible to `juju remove-machine --force` for those
   conditions where the machine is not available to be gracefully
   removed. Currently this is not guaranteed to remove the machine from
   the Mongo replicaset, so it should be used only as a last resort.

 *

   There is also a known issue that trying to `juju remove-machine` the
   machine that is currently the Mongo primary will not cleanup
   properly. This should be addressed in the next 2.4 release.

 *

   In future 2.4 releases, we will also be updating `juju enable-ha` to
   remove its logic around demoting machines. Instead, `juju enable-ha`
   will only be a way to ensure that you have the correct number of
   controller machines being started/intended to participate in HA.
   This will also fix issues around launching 2 new machines (going to
   5) while machines 2 and 3 are still starting.


* Controller configuration options for spaces

Two new controller configuration settings have been introduced. These are:

 *

   juju-mgmt-space

 *

   juju-ha-space


juju-mgmt-spaceis the name of the network space used by agents to 
communicate with controllers. Setting a value for this item limits the 
IP addresses of controller API endpoints in agent config, to those in 
the space. If the value is misconfigured so as to expose no addresses to 
agents, then a fallback to all available addressesresults. Juju client 
communication with controllers is unaffected by this value.



Juju-ha-spaceis the name of the network space used for MongoDB 
replica-set communication in high availability (HA) setups. This 
replaces the previously auto-detected space used for such communication. 
When enabling HA, this value mustbe set where member machines in a HA 
set have more than one IP address available for MongoDB use, otherwise 
an error will be reported. Existing HA replica sets with multiple 
available addresses will report a warning instead of an error provided 
the members and addresses remain unchanged.



Using either of these options during bootstrap or enable-ha effectively 
adds constraints to machine provisioning. The commands will fail with an 
error if such constraints can not be satisfied.



* Cloud credential changes

Cloud credentials are used by models to authenticate communications with 
the underlying provider as well as to perform authorised operations on 
this provider.


Juju has always dealt with both cloud credentials stored locallyon a 
user’s client machine as well as the cloud credentials stored remotelyon 
a bootstrapped Juju controller. 

Juju 2.3.6 Released

[Nicholas Skaggs]

Juju 2.3.6 has arrived. This is primarily a bug fix release. For the 
full list of bugs, see the 2.3.6 milestone 
.



## Critical bugs fixed

 *

   1762741  Juju
   bootstraps latest LTS by default


## Enhancements

 *

   1606617 This adds
   container-image-metadata-url and container-image-stream as config
   for KVM and LXD containers.

 *

   1760390 Add basic
   support for bionic and mongo3.6

 *

   1749201 Add
   juju-updateseries to allow for charm series upgrades


Users are *highly encouraged* to update to 2.3.6 to ensure xenial 
remains the default series for bootstrapping a controller.



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.


sudo 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 IRC, 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

Re: More juju upgrade-juju failings

[Nicholas Skaggs]

Sandor, thanks for this perspective! It was really helpful to see how 
upgrades went for you in real life, and more importantly, that 2.3.x 
seems to have gone smoothly. We'll be carefully watching and monitoring 
2.3->2.4 upgrades as the release draws nearer.


Nicholas

On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our 
experiences going from 2.1 to 2.3. Hopefully it provides some feedback 
and can be helpful for others in the same position.


http://zeestrataca.com/posts/upgrading-juju/ 
<http://zeestrataca.com/posts/upgrading-juju/>


Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs 
<nicholas.ska...@canonical.com <mailto:nicholas.ska...@canonical.com>> 
wrote:


Sandor, re:sharing experiences, if you want to frame some
scenarios you've had trouble with, please feel free to share
those. Distilling it down into a repeatable deployment -> upgrade
will help us understand and account for it. As Tim mentioned,
tools like juju-upgrader are generally candidates for
incorporation into juju itself, provided they prove valuable to
the community at large. We always welcome any PR's, but especially
so for improvements that add this functionality.

Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We
are aware
of the juju-upgrader plugin, and will be looking to
incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of
our CI,
which enables more test scenarios to help discover issues
between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to
2.3.x and
hitting some bugs along the way in staging (see below),
I'd agree that
the process needs a bit of love and wouldn't mind sharing
some experiences.

Rick mentioned https://launchpad.net/juju-upgrader
<https://launchpad.net/juju-upgrader> on the Juju show a
couple of episodes back, but I haven't seen it mentioned
anywhere else
yet. Are those tools supposed to deal with some of these
issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
<https://bugs.launchpad.net/juju/+bug/1746265>
https://bugs.launchpad.net/juju/+bug/1748294
<https://bugs.launchpad.net/juju/+bug/1748294>
https://bugs.launchpad.net/juju/+bug/1697936
<https://bugs.launchpad.net/juju/+bug/1697936>

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
<m...@ubuntu.com <mailto:m...@ubuntu.com>
<mailto:m...@ubuntu.com <mailto:m...@ubuntu.com>>> wrote:


     I think this UX on the upgrade process has obvious
problems. Nobody
     should have to guess at what to do, in which sequence.

     Can I suggest that we have a shared Google doc to
mock up a nice
     experience starting with the simple command 'juju
upgrade' which then
     walks people through the process, including the
distinction between
     upgrading charms, agents and controllers, as well as
the ability to do
     aerospace-grade upgrades through live migration to
newer controllers?

     Mark

     On 02/27/2018 11:26 PM, Tim Penhey wrote:
     > Hi Daniel,
     >
     > The issue here is that you are upgrading the
default model, not the
     > controller model itself.
     >
     > I think we could make the error messaging more
clear, and also
     have the
     > command also check the controller version before
showing a lot of
     > baffling output.
     >
     > What you need to do is upgrade the controller model
first, so either
     > switch to it or run:
     >
     >   juju upgrade-juju -m controller --agent-version 2.3.3
     >
     > Cheers,
     > Tim
     >
     > On 28/02/18 11:19, Daniel Bidwell wrote:
     >> I am running on juju 2.3

Juju 2.3.5 is released

[Nicholas Skaggs]

**

*Juju 2.3.5 has arrived. This is primarily a bug fix release.*

*

## Critical bugs fixed.

 *

   1737058 network-get
   failed to find configs

 *

   1751287 openstack
   bootstrap failed


## Important High bugs fixed.

 *

   1729880 actions are removed
   when status changes to Complete

 *

   1754735 support for current
   aws instance types


There's also a few enhancements like:

 *

   1753593 support for st1 and
   sc1 ebs volume types on aws

 *

   1757926 juju remove-offers
   command gets a --force option to remove offers with relations in place


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.


sudo 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 IRC, 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

Re: More juju upgrade-juju failings

[Nicholas Skaggs]

Sandor, re:sharing experiences, if you want to frame some scenarios 
you've had trouble with, please feel free to share those. Distilling it 
down into a repeatable deployment -> upgrade will help us understand and 
account for it. As Tim mentioned, tools like juju-upgrader are generally 
candidates for incorporation into juju itself, provided they prove 
valuable to the community at large. We always welcome any PR's, but 
especially so for improvements that add this functionality.


Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We are aware
of the juju-upgrader plugin, and will be looking to incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of our CI,
which enables more test scenarios to help discover issues between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that
the process needs a bit of love and wouldn't mind sharing some experiences.

Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else
yet. Are those tools supposed to deal with some of these issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth > wrote:


 I think this UX on the upgrade process has obvious problems. Nobody
 should have to guess at what to do, in which sequence.

 Can I suggest that we have a shared Google doc to mock up a nice
 experience starting with the simple command 'juju upgrade' which then
 walks people through the process, including the distinction between
 upgrading charms, agents and controllers, as well as the ability to do
 aerospace-grade upgrades through live migration to newer controllers?

 Mark

 On 02/27/2018 11:26 PM, Tim Penhey wrote:
 > Hi Daniel,
 >
 > The issue here is that you are upgrading the default model, not the
 > controller model itself.
 >
 > I think we could make the error messaging more clear, and also
 have the
 > command also check the controller version before showing a lot of
 > baffling output.
 >
 > What you need to do is upgrade the controller model first, so either
 > switch to it or run:
 >
 >   juju upgrade-juju -m controller --agent-version 2.3.3
 >
 > Cheers,
 > Tim
 >
 > On 28/02/18 11:19, Daniel Bidwell wrote:
 >> I am running on juju 2.3.3-xenial-amd64 and my controllers are
 running
 >> in VMware Vsphere with version 2.3.2.  I thought that it would be a
 >> good thing for me to upgrade the controllers.
 >>
 >> I have a controller, "juju switch" generates:
 >> bannercontroller:admin/default
 >>
 >> and juju status generates:
 >> ModelControllerCloud/Region  Version  SLA
 >> default  bannercontroller  myvscloud/New
 Datacenter  2.3.2unsupported
 >>
 >> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
 >>
 >> Unit  Workload  Agent  Machine  Public address  Ports  Message
 >>
 >> Machine  State  DNS  Inst id  Series  AZ  Message
 >>
 >> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
 >>
 >> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc
 go1.9.2]
 >> 17:16:19 DEBUG juju.cmd supercommand.go:57   args:
 []string{"/snap/juju/3452/bin/juju", "upgrade-juju",
 "--agent-version", "2.3.3", "--debug"}
 >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
 [10.1.61.239:17070 ]
 >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.api apiclient.go:597 connection established
 to
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
 [10.1.61.239:17070 ]
 >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.api apiclient.go:597 connection established
 to
 

Re: More juju upgrade-juju failings

[Nicholas Skaggs]

Sandor, re:sharing experiences, if you want to frame some scenarios 
you've had trouble with, please feel free to share those. Distilling it 
down into a repeatable deployment -> upgrade will help us understand and 
account for it. As Tim mentioned, tools like juju-upgrader are generally 
candidates for incorporation into juju itself, provided they prove 
valuable to the community at large. We always welcome any PR's, but 
especially so for improvements that add this functionality.


Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We are aware
of the juju-upgrader plugin, and will be looking to incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of our CI,
which enables more test scenarios to help discover issues between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that
the process needs a bit of love and wouldn't mind sharing some experiences.

Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else
yet. Are those tools supposed to deal with some of these issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936

Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth > wrote:


 I think this UX on the upgrade process has obvious problems. Nobody
 should have to guess at what to do, in which sequence.

 Can I suggest that we have a shared Google doc to mock up a nice
 experience starting with the simple command 'juju upgrade' which then
 walks people through the process, including the distinction between
 upgrading charms, agents and controllers, as well as the ability to do
 aerospace-grade upgrades through live migration to newer controllers?

 Mark

 On 02/27/2018 11:26 PM, Tim Penhey wrote:
 > Hi Daniel,
 >
 > The issue here is that you are upgrading the default model, not the
 > controller model itself.
 >
 > I think we could make the error messaging more clear, and also
 have the
 > command also check the controller version before showing a lot of
 > baffling output.
 >
 > What you need to do is upgrade the controller model first, so either
 > switch to it or run:
 >
 >   juju upgrade-juju -m controller --agent-version 2.3.3
 >
 > Cheers,
 > Tim
 >
 > On 28/02/18 11:19, Daniel Bidwell wrote:
 >> I am running on juju 2.3.3-xenial-amd64 and my controllers are
 running
 >> in VMware Vsphere with version 2.3.2.  I thought that it would be a
 >> good thing for me to upgrade the controllers.
 >>
 >> I have a controller, "juju switch" generates:
 >> bannercontroller:admin/default
 >>
 >> and juju status generates:
 >> ModelControllerCloud/Region  Version  SLA
 >> default  bannercontroller  myvscloud/New
 Datacenter  2.3.2unsupported
 >>
 >> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
 >>
 >> Unit  Workload  Agent  Machine  Public address  Ports  Message
 >>
 >> Machine  State  DNS  Inst id  Series  AZ  Message
 >>
 >> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
 >>
 >> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc
 go1.9.2]
 >> 17:16:19 DEBUG juju.cmd supercommand.go:57   args:
 []string{"/snap/juju/3452/bin/juju", "upgrade-juju",
 "--agent-version", "2.3.3", "--debug"}
 >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
 [10.1.61.239:17070 ]
 >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.api apiclient.go:597 connection established
 to
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
 [10.1.61.239:17070 ]
 >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
 "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
 "
 >> 17:16:19 INFO  juju.api apiclient.go:597 connection established
 to
 

Re: 100 contributors to juju!

[Nicholas Skaggs]

Odd.. I wonder what the missing 2 contributors are then -- the homepage
shows 100 :-)

https://github.com/juju/juju/
<https://github.com/juju/juju/graphs/contributors>

On Wed, Mar 14, 2018 at 6:10 PM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> That page ends at #98 - but still great to see! Proud to have my 6 commits
> in there
>
> On Wed, Mar 14, 2018 at 5:45 PM Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> We're in triple digits! I'm not sure when this happened, but it's
>> exciting nonetheless.
>>
>> https://github.com/juju/juju/graphs/contributors
>>
>> Thanks to all our contributors, and here's to the next 100.
>>
>> Nicholas
>>
>>
>> --
>> 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

100 contributors to juju!

[Nicholas Skaggs]

We're in triple digits! I'm not sure when this happened, but it's 
exciting nonetheless.


https://github.com/juju/juju/graphs/contributors

Thanks to all our contributors, and here's to the next 100.

Nicholas


--
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.1 is released

[Nicholas Skaggs]

A new release of Juju is here, 2.3.1. This is primarily a bug fix 
release which addresses this critical upgrade issue.



https://bugs.launchpad.net/juju/+bug/1737107




Note, you may see a spurious message similar to “CRITICAL ** 
SetModelAgentVersion: 2.3.1 false” while upgrading. This can be safely 
ignored and isn’t present in 2.3.



## How can I get it?


The best way to get your hands on this release of Juju is to install it 
as a snap package (see https://snapcraft.io/ for more info on snaps).



snap install juju --classic


Other packages are available for a variety of platforms. Please see the 
online documentation at 
https://jujucharms.com/docs/stable/reference-install. Those subscribed 
to a snap channel should be automatically upgraded. If you’re using the 
ppa/homebrew, you should see an upgrade available.



## 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.0 is here!

[Nicholas Skaggs]

The Juju team are extremely pleased to announce the release of Juju 2.3.
Juju is now more versatile, more efficient, and more configurable than ever.

Cross Model Relations deliver a new way of organising your software stack.
Deploy a database in one model and connect it to an application running
another, even one running on a different controller, or even a different
cloud.

For containers at scale, Juju now integrates Canonical's Fan overlay
network system. This allows containers to map network traffic to any other
container on the fan network without distributed databases, consensus
protocols, or any extra overhead.

Juju's support for bundles has made it possible to quickly deploy connected
sets of applications for some time now, but no two use cases are the same.
That's why we have introduced the concept of an 'overlay' bundle - now you
can easily add your own configuration and tweaks to a bundle at deploy
time. See below for links to more information on this and other key
features.


## How can I get it?


The best way to get your hands on this release of Juju is to install it via
snap packages (see https://snapcraft.io/for more info on snaps).


   snap install juju --classic


Other packages are available for a variety of platforms. Please see the
online documentation at https://jujucharms.com/docs/2.3/reference-install <
https://jujucharms.com/docs/stable/reference-install>. Those subscribed to
a snap channel should be automatically upgraded. If you’re using the
ppa/homebrew, you should see an upgrade available.


For highlights of this release, please see the documentation at

https://jujucharms.com/docs/2.3/whats-new. Further details are below.



## New


* Cross Model Relations:

 - see https://jujucharms.com/docs/2.3/models-cmr


* Persistent Storage:

 - see https://jujucharms.com/docs/2.3/charms-storage


* FAN:

 - see https://jujucharms.com/docs/2.3/charms-fan


* Bundle deployments:

 - Changed flags for deploying bundles to existing machines

 - Bundle deploy flag --bundle-config replaced with --overlay

 - Deploying bundles now supports --dry-run

 - Deploying bundles can now target existing machines


* Update Application Series:

 - see https://jujucharms.com/docs/2.3/howto-updateseries


* Parallelization of the Machine Provisioner:

- Groups of machines will now be provisioned in parallel reducing
deployment time, especially on large bundles.


* open_port and close_port hook tools now support ICMP

- The open_port and close_port hook tools now support opening firewall
access for ICMP. The syntax is:

open_port icmp


* LXD Storage Provider:

 - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)


## Fixes


* Listing of Juju models is more efficient and can now handle more models
gracefully

* Leadership coordinations is no longer tied to local time which avoids
problems with clock skew and reduces overall load on the database

* Models are now more reliably destroyed and several fixes to avoid
negative impacts while they are being removed


You can check the milestones for a detailed breakdown of the Juju bugs we
have fixed:


https://launchpad.net/juju/+milestone/2.3.0

https://launchpad.net/juju/+milestone/2.3-rc2

https://launchpad.net/juju/+milestone/2.3-rc1

https://launchpad.net/juju/+milestone/2.3-beta3

https://launchpad.net/juju/+milestone/2.3-beta2

https://launchpad.net/juju/+milestone/2.3-beta1



## Known issues

The issues are targeted to be addressed in the upcoming 2.3.1 release.


* Firewaller issues on vmware vsphere https://bugs.launchpad.net/juj
u/+bug/1732665


* LXD broken on vmware
https://bugs.launchpad.net/juju/+bug/1733882


* Can't deploy bundle with map-machines=existing and subordinates
https://bugs.launchpad.net/juju/+bug/1736592


* load spike on controller following remove-application
https://bugs.launchpad.net/juju/+bug/1733708



## Feedback Appreciated!


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


Join us at regular Juju shows - subscribe to our Youtube channel
https://youtube.com/jujucharms

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.


https://jujucharms.com/docs/2.3/contact-us 


## 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

Re: Juju 2.3-rc2 is here!

[Nicholas Skaggs]

Is your agent stream set to released per chance?

juju model-config -m controller

If so, your client won't see the agent binaries as they aren't in the 
release stream (2.3 isn't yet released).


Nicholas

On 12/06/2017 03:10 PM, Merlijn Sebrechts wrote:
I tried this but I get the error that no agent binaries are found? I 
can send you the exact error tomorrow, I don't have my laptop with me 
at the moment.


On 6 Dec 2017 20:56, "Tim Penhey" <tim.pen...@canonical.com 
<mailto:tim.pen...@canonical.com>> wrote:


Hi Merlijn,

You should be able to go:
  juju upgrade-juju -m controller

That should do the trick. If the client version is different you may
want to specify the agent version:

  juju upgrade-juju -m controller --agent-version 2.3-rc2

Tim

On 07/12/17 06:26, Merlijn Sebrechts wrote:
> Is there a way to upgrade a controller from rc1.1 to rc2?
>
> 2017-11-29 1:03 GMT+01:00 Nicholas Skaggs
<nicholas.ska...@canonical.com <mailto:nicholas.ska...@canonical.com>
> <mailto:nicholas.ska...@canonical.com
<mailto:nicholas.ska...@canonical.com>>>:
>
>     A new release of Juju is here, 2.3-rc2. This is primarily a
bug fix
>     release which addresses issues carried over from rc1.
>
>
>     ## New and Improved
>
>
>     * juju list-models is significantly faster, especially on
>     controllers with large numbers of models
>
>
>     * juju no longer records the execution of the update-status
hook.
>     This means that you will no longer see 'idle' units move to
>     'executing' showing 'running update-status hook'. This also
means
>     that it isn't recorded in the show-status-log for the unit. As a
>     related item, the squashing of the status-log, which was
buggy, has
>     been removed.
>
>
>     ## Fixes
>
>
>     For a list of all bugs fixed in this release, see
>
>
> https://launchpad.net/juju/+milestone/2.3-rc2
<https://launchpad.net/juju/+milestone/2.3-rc2>
>     <https://launchpad.net/juju/+milestone/2.3-rc2
<https://launchpad.net/juju/+milestone/2.3-rc2>>
>
>
>
>     ## How can I get it?
>
>
>     The best way to get your hands on this release of Juju is to
install
>     it as a snap package (see https://snapcraft.io/for more info
on snaps).
>
>
>     snap install juju --classic --candidate
>
>
>     Other packages are available for a variety of platforms.
Please see
>     the online documentation at
> https://jujucharms.com/docs/stable/reference-install
<https://jujucharms.com/docs/stable/reference-install>
>     <https://jujucharms.com/docs/stable/reference-install
<https://jujucharms.com/docs/stable/reference-install>>. Those
>     subscribed to a snap channel should be automatically
upgraded. If
>     you’re using the ppa/homebrew, you should see an upgrade
available.
>
>
>     ## 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
<mailto:j...@lists.ubuntu.com>
>     <mailto:j...@lists.ubuntu.com <mailto: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 <mailto:Juju-dev@lists.ubuntu.com>
<mailto:Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>>
>     Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
<https://lists.ubuntu.com/mailman/listinfo/juju-dev>
>     <https://lists.ubuntu.com/mailman/listinfo/juju-dev
<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 2.3-rc2 is here!

[Nicholas Skaggs]

A new release of Juju is here, 2.3-rc2. This is primarily a bug fix release
which addresses issues carried over from rc1.

## New and Improved

* juju list-models is significantly faster, especially on controllers with
large numbers of models

* juju no longer records the execution of the update-status hook. This
means that you will no longer see 'idle' units move to 'executing' showing
'running update-status hook'. This also means that it isn't recorded in the
show-status-log for the unit. As a related item, the squashing of the
status-log, which was buggy, has been removed.

## Fixes

For a list of all bugs fixed in this release, see

https://launchpad.net/juju/+milestone/2.3-rc2


## How can I get it?

The best way to get your hands on this release of Juju is to install it as
a snap package (see https://snapcraft.io/ for more info on snaps).

snap install juju --classic --candidate

Other packages are available for a variety of platforms. Please see the
online documentation at https://jujucharms.com/docs/stable/reference-install.
Those subscribed to a snap channel should be automatically upgraded. If
you’re using the ppa/homebrew, you should see an upgrade available.

## 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-rc1 is now availible

[Nicholas Skaggs]

A new release of Juju is here, 2.3-rc1. This is primarily a bug fix release
which addresses issues carried over from beta3.

## New and Improved

* Changed flags for deploying bundles to existing machines

When deploying bundles, machines specified in the bundle are added to the
model as new machines. In order to use the existing machines in the model
rather than create new machines, the option --map-machines=existing can be
used. To specify particular machines for the mapping, multiple comma
separated values of the form "bundle-id=existing-id" can be passed where
the bundle-id and the existing-id refer to top level machine IDs. For
example, if there were a bundle that specified machines 1, 2, and 3, and
the model had machines 1, 2, 3 and 4, the following deployment of the
bundle would use machines 1 and 2 in the model for machines 1 and 2 in the
bundle and use machine 4 in the model for the bundle machine 3.

 juju deploy some-bundle --map-machines existing,3=4


* Bundle deploy flag --bundle-config replaced with --overlay.

The bundle config files used to allow overwriting configuration values of
applications that had already been defined in the base bundle, but did
nothing else.

The overlay files are now full bundles in their own right. The overlay
bundle can specify new applications, change values like the previous
bundle-config files, and also specify the removal of an application in the
base bundle. An application can be removed from the bundle definition by
defining the application name in the application section, but no values
specified. Removing an application also removes all the relations for that
application. If a machines section is specified in an overlay bundle it
replaces the machines section of the base bundle. No merging of machine
information is attempted. Multiple overlay bundles can be specified and
they are processed in the order they appear on the command line.

## Fixes

For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.3-rc1

## How can I get it?

The best way to get your hands on this release of Juju is to install it as
a snap package (see https://snapcraft.io/ for more info on snaps).

snap install juju --classic --candidate

Other packages are available for a variety of platforms. Please see the
online documentation at https://jujucharms.com/docs/stable/reference-install.
Those subscribed to a snap channel should be automatically upgraded. If
you’re using the ppa/homebrew, you should see an upgrade available.

## 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.2.4 is here!

[Nicholas Skaggs]

Coming hot on the heels of 2.2.3, we are happy to announce the release of
Juju 2.2.4!

## New and Improved

This release is primarily a bug fix release which addresses some issues
that missed the cutoff for the previous 2.2.3 release or were discovered in
2.2.3.

A notable fix is for model migration:


   -

   Model migration would previously fail if the model had subordinate
   applications that were related to multiple principals. This is now fixed.


For a list of all bugs fixed in this release, see
https://launchpad.net/juju/+milestone/2.2.4

## How can I get it?

The best way to get your hands on this release of Juju is to install it as
a snap package (see https://snapcraft.io for more info on snaps).

snap install juju --classic

Other packages are available for a variety of platforms. Please see the
online documentation at https://jujucharms.com/docs/stable/reference-install.
Those subscribed to a snap channel should be automatically upgraded. If
you’re using the ppa/homebrew, you should see an upgrade available.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Consuming MongoDB from a Snap

[Nicholas Skaggs]

On Fri, Jun 23, 2017 at 10:36 AM, Menno Smits 
wrote:

>
>
> On 23 June 2017 at 12:09, Andrew Wilkins 
> wrote:
>
>>
>>> *1. Does snapd work on all architectures that Juju supports?*
>>>
>>> The answer appears to be "yes with some caveats". For xenial onwards
>>> there are snapd packages for all the architectures the Juju team cares
>>> about.
>>>
>>
>> Ah, I thought the question was rather whether or not the mongo snap
>> existed for all of those architectures. I don't think it does. IIANM, the
>> snap comes from https://github.com/niemeyer/snaps/blob/master/mongodb/
>> mongo32/snapcraft.yaml, which (if you look at the "mongodb" part,
>> appears to only exist for x86_64). So we would need to do some work on that
>> first.
>>
>
> ​I imagine we would have a custom MongoDB snap for Juju rather than using
> this one as is. We want direct control over the snap. The niemeyer snap
> would probably be a good starting point though.
>
Long term, I think it would be interesting to switch the unit payload over
to a snap. One snap would get you the agent, and everything you need to run
it. Barring the issues with snaps, this would make the entire story quite
clean. I know we spoken about this in the past, but I think it makes sense
to keep in mind if you wish to migrate. Juju should bundle everything into
a juju server snap. On the client / bootstrap side, centos, windows, and
mac support is still something to keep in mind.

Nicholas
-- 
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.2-rc2 has been released

[Nicholas Skaggs]

Yes, and this too has been corrected. You should expect releases to flow 
down to level of risk. So, when 2.2 releases, beta, candidate and stable 
will all point to the 2.2 revision (until the first beta for 2.3, and so 
on).


channels:
  latest/stable:2.1.3  (1922) 24MB classic
  latest/candidate: 2.2-rc2(1929) 25MB classic
  latest/beta:  2.2-rc2(1929) 25MB classic
  latest/edge:  2.3-alpha1+develop-1cb9c09 (1933) 42MB classic


Nicholas

On 06/12/2017 12:17 PM, Jason Hobbs wrote:

Nicholas,

Thanks.  beta is still 2.2rc1.  Should it be 2.2rc2 also?

Jason

On Mon, Jun 12, 2017 at 11:15 AM, Nicholas Skaggs 
<nicholas.ska...@canonical.com <mailto:nicholas.ska...@canonical.com>> 
wrote:


Thanks for the heads-up Jason. Yes, small snafu with publishing
the builds. Edge builds are tracking develop (2.3-alpha1) and now
are being published again.

Nicholas

On 06/12/2017 11:18 AM, Jason Hobbs wrote:

I noticed that for the juju snap, edge and beta channels have
older releases than candidate.  Shouldn't they always be at
least the same version as candidate, if not newer?

  stable:2.1.3   (1922) 24MB classic
  candidate: 2.2-rc2 (1929) 25MB classic
  beta:  2.2-rc1 (1925) 25MB classic
  edge:  2.2-rc1+develop-7256fe0 (1915) 44MB classic

Thanks,
Jason

On Fri, Jun 9, 2017 at 6:25 AM, Chris Lee
<chris@canonical.com <mailto:chris@canonical.com>
<mailto:chris@canonical.com
<mailto:chris@canonical.com>>> wrote:

# Juju 2.2-rc2 Release Notes

We are delighted to announce the release of Juju and
conjure-up
2.2-rc2! In this release, Juju greatly improves memory and
storage
consumption, works on KVM containers, and improves network
modelling. conjure-up now supports Juju as a Service (JAAS),
provides a MacOS client, and adds support for repeatable spell
deployments.

The best way to get your hands on this release of Juju and
conjure-up is to install them via snap packages (see
https://snapcraft.io/for more info on snaps).

   snap install juju --classic --candidate

snap install conjure-up --classic --candidate

Other packages are available for a variety of platforms.
Please
see the online documentation at
https://jujucharms.com/docs/devel/reference-releases#development
<https://jujucharms.com/docs/devel/reference-releases#development>
   
<https://jujucharms.com/docs/devel/reference-releases#development

<https://jujucharms.com/docs/devel/reference-releases#development>>

Please note that if you are upgrading an existing controller,
please make sure there is at least 6G of free disk space. The
upgrade step for the logs can take a while, in the
vicinity of 10
or more minutes if the current logs collection is at its
maximum size.

Since 2.2-rc1

## New and Improved

   



Better support credential management in the Azure provider

* support autoload-credentials and juju add-credential in the
azure provider when Azure CLI is installed.

(this removes the requirement that the user discover their
subscription ID before creating credentials)

Rate limit login and connection requests to the
controller(s) on
busy systems.

## Fixes

   



Fix issue where status history logs were not pruned:

https://bugs.launchpad.net/juju/+bug/1696491
<https://bugs.launchpad.net/juju/+bug/1696491>
<https://bugs.launchpad.net/juju/+bug/1696491
<https://bugs.launchpad.net/juju/+bug/1696491>>



--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>
<mailto:Juju-dev@lists.ubuntu.com
<mailto:Juju-dev@lists.ubuntu.com>>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
<https://lists.ubuntu.com/mailman/listinfo/juju-dev>
<https://lists.ubuntu.com/mailman/listinfo/juju-dev
<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: OS X VMS on JAAS

[Nicholas Skaggs]

On 06/03/2017 02:56 AM, John Meinel wrote:
You can add a manually provisioned machine to any model, as long as 
there is connectivity from the machine to the controller. Now, I would 
have thought initial setup was initiated by the Controller, but its 
possible that initial setup is actually initiated from the client.


Once initial setup is complete, then it is definitely true that all 
connections are initiated from the agent running on the controlled 
machine to the controller. The controller no longer tries to 
socket.connect to the machine. (In 1.X 'actions' were initiated via 
ssh from the controller, but in 2.X the agents listen to see if there 
are any actions to run like they do for all other changes.)


Now, given that he added a model into "us-east-1" if he ever did just 
a plain "juju add-machine" or "juju deploy" (without --to) it would 
definitely create a new instance in AWS and start configuring it, 
rather than from your VM.
Is it possible for us to convey the model's proper location, even when 
using jaas? He's in effect lying to the controller which does have the 
knock-on affect of weird behavior.


Which is why using something like the "lxd provider" would be a more 
natural use case, but according to James the sticking point is having 
to set up a controller in the first place. So "--to lxd:0" is easier 
for them to think about than setting up a provider and letting it 
decide how to allocate machines.


Note, it probably wouldn't be possible to use JAAS to drive an LXD 
provider, because *that* would have JAAS be trying to make a direct 
connection to your LXD agent in order to provision the next machine. 
However "--to lxd:0" has the local juju agent (running for 'machine 
0') talking to the local LXD agent in order to create a container.
If this is a useful case, could we define it as a mode of operation and 
have juju just work in such a scenario? It's an interesting mix of 
allowing the benefits of jaas for manually provisioned machines and 
environments. Just eliminating the weird behaviors and having to pretend 
it's a known cloud / provider could be useful. An assume nothing mode if 
you will.


Nicholas

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

Juju 1.25.12, 2.0.4, and 2.1.3 Security Update Release

[Nicholas Skaggs]

We have issued an update to Juju 1.25.12, 2.0.4, and 2.1.3 in order to
address a security issue. The update fixes a privilege escalation
vulnerability when executing `juju-run` on the cloud instances, not to be
confused with the 'juju run' CLI command.



See the following for further details on the vulnerability:

   -

   https://bugs.launchpad.net/juju/+bug/1682411
   -

   CVE-2017-9232 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9232



This vulnerability affects all currently distributed versions of Juju
(1.25.x, 2.0.x and 2.1.x). All users are encouraged to upgrade their
existing models and controllers.



How to know if you need to update

-



We’ve put together a helpful Python script that will loop through your
controllers and then output the version of each model on the controller. It
requires Python 2.7 or higher.



 curl -L https://goo.gl/59gxnz | python



How do I update? I’m on…

-



JAAS



JAAS has been updated to the new 2.1.3 release. Users with models in JAAS
do not need to perform any upgrade steps to their models that are running
in JAAS.



Juju 2.2-betaX

~~~

Users of the 2.2-beta releases need to temporarily update to using the edge
channel. Users will need to use this until Juju 2.2-rc1 is released in the
coming days. You can easily switch your snap install client by using the
following:



   snap refresh juju --edge --classic



Once you’ve completed this step you’ll need to run through the normal
upgrade steps on your models, as explained in the documentation:



https://jujucharms.com/docs/models-upgrade#the-upgrade-juju-command




Note for non-snap beta users: we suggest you do not run controllers with
the 2.2 beta releases. We suggest you move to the edge channel of the snap
releases or to wait and redeploy when 2.2 RC1 is released.



Juju 2.1.x



You can follow the current upgrade documentation to upgrade. Make sure that
you update your controller model as well as each model on that controller.



https://jujucharms.com/docs/2.1/models-upgrade



Juju 2.0.x



Juju 2.0.x is an older release of Juju. We highly recommend all users
upgrade to the current stable and supported release of Juju 2.1 (see
above).



https://jujucharms.com/docs/2.0/models-upgrade



Juju 1.25.x



Users of Juju 1.25 can upgrade using the upgrade documentation for their
release.



https://jujucharms.com/docs/1.25/juju-upgrade





Questions/Concerns

--



If you have any questions please don’t hesitate to reach out to the team
via:



   -

   the #juju Freenode IRC channel
   -

   the juju mailing list https://lists.ubuntu.com/mailman/listinfo/juju



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



Join us at regular Juju shows - subscribe to our Youtube channel
https://youtube.com/jujucharms

More information





To learn more about these great technologies please visit

https://jujucharms.com and http://conjure-up.io.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.1-beta5 is here

[Nicholas Skaggs]

The Juju team would like to introduce Juju and conjure-up 2.1-beta5! The 
most visible changes are to container networking and that juju 
controllers now expose Prometheus metrics over an HTTPS endpoint. 
Finally, conjure-up is also a snap, provides juju, and can be installed 
on trusty as a snap as well!


We would especially like feedback on the container networking changes. 
Do let us know of your experiences, and feel free to open bugs and 
threads to discuss.


## What’s New in Beta 5

[conjure-up] Now snapped for Trusty and Xenial.
[conjure-up] Support for Canonical Kubernetes 1.5.2.
[conjure-up] Ability to teardown models with the new `conjure-down` 
command.

[juju] Container networking improvements:
- LXD and KVM guests no longer join all spaces on the host 
machine, but use constraints and bindings to determine what spaces 
should be used
- Bridges are not created during provisioning, but only created on 
demand for containers that will use them.
- For clouds other than MAAS, we continue to put containers onlocal 
bridges (lxdbr0)
   [juju] Juju ssh/scp now selects correct address to use to connect to 
the controller.
[juju] Model config now supports an "extra-info" field for holding 
additional metadata.

[juju] More memory leaks have been addressed.
[juju] Stricter rules for validating charm metadata field names to 
conform to data storage requirements. Charm metadata fields can not 
contain dots.
[juju] controllers now expose HTTPS endpoints under 
“/introspection/”, accessible to controller superusers, and users with 
read access to the controller model:/introspection/debug/pprof/profile, 
/introspection/depengine/,/introspection/metrics.



## Bugs Addressed

Check the milestones for a detailed breakdown of juju and conjure-up 
bugs corrected.


https://launchpad.net/juju/+milestone/2.1-beta5

https://github.com/conjure-up/conjure-up/milestone/14?closed=1

## How do I get it?

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

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

   sudo apt-get install juju

Or install Juju from the snap store:

   snap install juju --beta --devmode

Install conjure-up from the snap store:

snap install conjure-up --classic --beta

If you are on Trusty, you'll need to run a few extra commands:
   sudo apt-get install snapd
   sudo groupadd lxd && sudo usermod -a -G lxd $USER
   sudo reboot

Now you can install snaps, including conjure-up, as normal:
   snap install conjure-up --classic --beta

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

   https://launchpad.net/juju/+milestone/2.1-beta5

## 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.


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

A new supported stable release of Juju, 1.25.10, is here!

[Nicholas Skaggs]

A new supported stable release of Juju, 1.25.10, is here!


## Bug fixes

* Jujud and mongodb ram and cpu spikes
https://bugs.launchpad.net/juju/+bug/1587644

 * Log sending between 1.25.X series
https://bugs.launchpad.net/juju-core/+bug/1654528

 ## How do I get it?

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

sudo add-apt-repository ppa:juju/1.25
sudo apt-get update; sudo apt-get install juju-core

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

https://launchpad.net/juju-core/+milestone/1.25.10

## 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.


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

A new development release of Juju, 2.1-beta4, is here!

[Nicholas Skaggs]

The Juju team would like to introduce Juju and conjure-up 2.1-beta4!

## What’s New

Openstack Provider has been updated to support Neutron networking apis
New APIs for querying instance types and characteristics available on 
clouds

Model Migration is no longer behind a feature flag
Instrumentation of Juju via Prometheus endpoints
vSphere provider improvements
[conjure-up] New ‘Architecture’ button allows editing machine placement, 
including specifying a machine in a MAAS
[conjure-up] Updated Canonical Kubernetes spell for Kubernetes 1.5.1 and 
deploying to the Localhost (LXD) Provider.


## Bugs Addressed

Check the milestones for a detailed breakdown of juju and conjure-up 
bugs corrected.

https://launchpad.net/juju/+milestone/2.1-beta4
https://github.com/conjure-up/conjure-up/milestone/14?closed=1

## How do I get it?

If you are running Ubuntu, you can get juju and conjure-up from the juju 
devel ppa:


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

Or install juju from the snap store

snap install juju --beta --devmode

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

https://launchpad.net/juju/+milestone/2.1-beta4

## Known Issues

Renaming of models not yet supported:
https://bugs.launchpad.net/juju/+bug/1649738

## 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.


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

Juju 2.0.2 is here!

[Nicholas Skaggs]

A new stable release of Juju, 2.0.2, is here!

## What's new?

This release contains bugfixes for MAAS and openstack, including fixing 
nova support.


## New to juju 2?

https://jujucharms.com/docs/2.0/introducing-2

## How do I get it?

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

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

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

https://launchpad.net/juju/+milestone/2.0.2

 ## What else is in it?

* #1636648 cinder fails with badRequest... "Invalid input for 
field/attribute device"

* #1638304 Juju 2.0.1 is not able to bootstrap with nova
* #1638706 environSuite.TestBootstrapInstanceConstraints fails on 
rare archs and series

* #1640282 upgrade-juju: manual-provider no matching tools available
* #1557726 Restore fails on some openstacks like prodstack
* #1636919 MAAS machine selected with space in violation of constraint
* #1636969 [1.9] Multiple negative spaces constraints given and 
rejected by MAAS
* #1637595 allWatcherStateSuite.TestRemoveRemoteApplication waiting 
for remote connection


## 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.


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

Juju 2.1-beta2 is here!

[Nicholas Skaggs]

A new development release of Juju, 2.1-beta2, is here!


## What's new?


*Openstack Provider has been updated to support Neutron networking apis

* New APIs for querying instance types and characteristics available on 
clouds


* Model Migration is no longer behind a feature flag

* Instrumentation of Juju via Prometheus endpoints

* Fix to enable deploying to cluster for vsphere as provider 
https://bugs.launchpad.net/juju/+bug/1590143


* Other Bug fixes https://launchpad.net/juju/+milestone/2.1-beta2


## Known Issues:


* Model Migration Fails on 3rd attempt: 
https://bugs.launchpad.net/juju/+bug/1646310


* Model Migrations does not support charms with resources, this will 
land before 2.1-rc1


* HA tests fail after the leader is deleted: 
https://bugs.launchpad.net/juju/+bug/1640535



## 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


Or install it from the snap store


   snap install juju --beta --devmode


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


   https://launchpad.net/juju/+milestone/2.1-beta2


## 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 aboutyour feedback and 
usage of juju.



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

Juju 1.25.7 is proposed for release

[Nicholas Skaggs]

A new proposed stable release of Juju 1.25.7, is now available.
We invite you to test this proposed update to the 1.25 series and 
provide feedback before it's release.


## Getting Juju 1.25.7

A proposed version of juju-core 1.25.7 is available in the following PPA:

https://launchpad.net/~juju/+archive/ubuntu/1.25-proposed

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.7

NOTE: Proposed releases use the "proposed" simple-streams. You must 
configure
the `agent-stream` option in your environments.yaml to use the matching 
juju agents.
See https://jujucharms.com/docs/1.25/config-general for help with 
setting this.


## Notable Changes

* Added support for new AWS regions: ap-south-1 and us-east-2
* Fixed issue allowing you to re-provision a machine with manual 
provider, https://bugs.launchpad.net/juju/+bug/1418139
* Improved charm garbage collection, 
https://bugs.launchpad.net/juju-core/+bug/1626304
* HA Agents connectivity fixes; 
https://bugs.launchpad.net/juju/+bug/1510651 , 
https://bugs.launchpad.net/juju/+bug/1597830
* Correct Backup and Restore failures; 
https://bugs.launchpad.net/juju/+bug/1457575 , 
https://bugs.launchpad.net/juju/+bug/1544796


For the full list of bugs addressed, checkout the milestone:

https://launchpad.net/juju-core/+milestone/1.25.7

## 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!




--
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.1 is here!​

[Nicholas Skaggs]

t;83A781AE-9A0C-43C7-B405-310A5A94566E"}}])


Could this occur due to the new version of goose according to:

Merge pull request #6501 <https://github.com/juju/juju/issues/6501> 
from axw/lp1636648-openstack-update-goose


provider/openstack: update goose

Use new version of goose, to omit the device
field on volume attachment requests when no
device is specified.

This branch also uses the new OpenStack API
version discovery code in goose.

Fixes https://bugs.launchpad.net/juju/+bug/1636648

Any advice or help here how to debug it and provide better quality for 
a bug report is appreciate.


Best regards,
Malte Menkhoff

On 31 Oct 2016, at 23:33, Nicholas Skaggs 
<nicholas.ska...@canonical.com 
<mailto:nicholas.ska...@canonical.com>> wrote:


Our first update to Juju 2 is here! This Juju 2.0.1 release brings 
some improvements including;


   * Support for the new AWS region us-east-2
   * Correct OSX Sierra support
   * Update list-models output to show cloud/region vs owner
   * Update model-migrations with support for endpoints, cloud 
credentials


## New to juju 2?

https://jujucharms.com/docs/2.0/introducing-2

## Ready to install it?

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

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

Or install it from the snap store

   snap install juju --beta --devmode

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

https://launchpad.net/juju/+milestone/2.0.1

## What else is in it?

Notable bug fixes include:
   * #1623136, #1629452 Vsphere improvements
   * #1614239 use-floating-ip is not honored from clouds.yaml config
   * #1619808 bootstrap-timeout ignored in --config
   * #1602840 juju show-machines should show all addresses a machine has
   * #1616098 Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0

For the full list of bugs addressed, checkout the milestone: 
https://launchpad.net/juju/+milestone/2.0.1


## 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.


--
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 2.0.1 is here!​

[Nicholas Skaggs]

Our first update to Juju 2 is here! This Juju 2.0.1 release brings some 
improvements including;


* Support for the new AWS region us-east-2
* Correct OSX Sierra support
* Update list-models output to show cloud/region vs owner
* Update model-migrations with support for endpoints, cloud credentials

## New to juju 2?

https://jujucharms.com/docs/2.0/introducing-2

## Ready to install it?

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

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

Or install it from the snap store

snap install juju --beta --devmode

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

https://launchpad.net/juju/+milestone/2.0.1

## What else is in it?

Notable bug fixes include:
* #1623136, #1629452 Vsphere improvements
* #1614239 use-floating-ip is not honored from clouds.yaml config
* #1619808 bootstrap-timeout ignored in --config
* #1602840 juju show-machines should show all addresses a machine has
* #1616098 Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0

For the full list of bugs addressed, checkout the milestone: 
https://launchpad.net/juju/+milestone/2.0.1


## 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.


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

Juju 2.0 is here!

[Nicholas Skaggs]

Juju 2.0 is here! This release has been a year in the making. We’d like 
to thank everyone for their feedback, testing, and adoption of juju 2.0 
throughout its development process! Juju brings refinements in ease of 
use, while adding support for new clouds and features.


## New to juju 2?

https://jujucharms.com/docs/2.0/getting-started

## Need to install it?

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

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

Or install it from the snap store

snap install juju --beta --devmode

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

https://launchpad.net/juju/+milestone/2.0.0

## Want to upgrade to GA?

Those of you running an RC version of juju 2 can upgrade to this release 
by running:


juju upgrade-juju

## 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.


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

Juju 2.0-beta17 is here!

[Nicholas Skaggs]

A new development release of Juju, 2.0-beta17, is here!

## What's new?

* add-model now takes region name as an optional positional argument,
  to be consistent with bootstrap. The --region flag has been removed.
* show-controller now includes the agent version
* show-controllers has been removed as an alias to show-controller

## 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 update; sudo apt install juju-2.0

Or install it from the snap store

snap install juju --beta --devmode

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

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


## 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



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

Juju 2.0-beta16 is here!

[Nicholas Skaggs]

A new development release of Juju, 2.0-beta16, is here!

## 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 update; sudo apt install juju-2.0

Or install it from the snap store

snap install juju --beta --devmode

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

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

## What's new?

This release fixed 61 bugs and added some new and expanded features. Some
of the notable changes include:

* Juju rejects LXD 2.1 https://bugs.launchpad.net/bugs/1614559
* debug-log usability changes
 - only tails by default when running in a terminal
--no-tail can be used to not tail from a terminal
--tail can be used for force tailing when not on a terminal
 - time output now defaults to local time (--utc flag added to show times
in utc)
 - filename and line number no longer shown by default (--location flag
added to include location in the output)
 - dates no longer shown by default (--date flag added to include dates in
output)
--ms flag added to show timestamps to millisecond precision
 - severity levels and location now shown in color in the terminal
--color option to force ansi color codes to pass to 'less -R'
* controllers models, and users commands now show current controller and
model respectively using color as well as the asterix
* removal of smart formatter for CLI commands. Where 'smart' used to be the
default, now it is 'yaml'.
* controllers, models, and users commands now print the access level users
have against each model/controller
* juju whoami command prints the current controller/model/logged in user
details
* fix for LXD image aliases so that the images auto update (when
bootstrapping a new LXD cloud, images will be downloaded again the first
time, even if existing ones exist)
* Expanded controller and model permissions.

Also, juju-2 has moved on launchpad to launchpad.net/juju.
launchpad.net/juju-core will continue to be utilized for juju-1 milestones
and bug tracking.


## 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
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju snap edge channel enabled

[Nicholas Skaggs]

Following up on Ian's work to remove the need for --upload-tools, I've
enabled daily publishing to the edge channel for the juju snap. The snap
utilizes this work so the snap 'just works' as expected. A new snap is
generated and published once a day so you'll always have the latest
changes. Make sure you install using the edge channel.

snap install juju --edge --devmode

Remember, the code has been through basic QA checks, but stability is not
warranted. Please don't use them for production deployments, but otherwise
have fun living on the edge!

Note, snap-confine currently has a bug which affects the juju snap and LXD;
it's not possible to use LXD as a substrate when juju is installed as a
snap package. See LP# 1613845. I expect this to be sorted very soon so LXD
works once again.

Enjoy!

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

Re: So I wanted to update a dependency . .

[Nicholas Skaggs]

nes of code.  What is a minor annoyance
> in a small project becomes much worse in a large project.  Obviously, part
> of that is inescapable - we can't make juju smaller.  I do think it's worth
> considering ways to make our lives easier.
>
> -Nate
>
> On Thu, Aug 11, 2016 at 7:08 PM Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
>> On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> This is a simple story of a man and a simple mission. Eliminate the
>>> final 2 dependencies that are in bazaar and launchpad. It makes juju and
>>> it's dependencies live completely in git. A notable goal, and one that I
>>> desired for getting snaps to build with launchpad.
>>>
>>> I don't feel I need to explain the pain that making a no-source change
>>> update to a dependency (point juju and friends to it's new location) has
>>> been. I've had to carefully craft a set of PR's, and land them in a certain
>>> order. I've encountered contention (because I have to change hundreds of
>>> imports), unit test issues (because juju's dependencies aren't tested when
>>> merged, so they can be incompatible with the latest juju without knowing
>>> it), and circular dependencies that require some magic and wishful thinking
>>> to workaround.
>>>
>>> I'm still not finished landing the change, but I hope to do so *soon*.
>>> It must be close now!
>>>
>>> All of this to say, I think it would be useful to have a discussion on
>>> how we manage dependencies within the project. From a release perspective,
>>> it can be quite cumbersome as dependencies are picked up and dropped. It's
>>> also recently made a release (And critical bugfix) really difficult at
>>> times. From my newly experience contributor perspective, I would really
>>> think twice before attempting to make an update :-) I suspect I'm not alone.
>>>
>>> I've heard ideas in the past about cleaning this up, and some things
>>> like circular dependencies between romulus and juju are probably best
>>> described as tech debt. But there also is some pain in the larger scheme of
>>> things. For example, we are currently hacking a patch to juju's source for
>>> the mgo dependency since updating the source or vendoring or any other
>>> option is way too painful. It's time to really fix this. Ideas?
>>>
>>
>> My team's been chipping away at romulus and it'll be sorted out soon
>> enough. We've already moved the terms API client out to
>> github.com/juju/terms-client, and we'll be doing something similar for
>> the other APIs. As for the commands.. these probably need to find a better
>> home closer to the command base types they extend, in cmd/juju/...
>>
>> One thing that occurred to me today though is most of our dependencies
>> also have tests (well, they should!). We don't often run *those* tests
>> as part of Juju CI, but you could run into some cases where some
>> dependencies share common dependencies, but are tested with different
>> common dependency versions than those specified by Juju's dependencies.tsv.
>>
>>
>>> --
>>> 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

So I wanted to update a dependency . .

[Nicholas Skaggs]

This is a simple story of a man and a simple mission. Eliminate the final 2
dependencies that are in bazaar and launchpad. It makes juju and it's
dependencies live completely in git. A notable goal, and one that I desired
for getting snaps to build with launchpad.

I don't feel I need to explain the pain that making a no-source change
update to a dependency (point juju and friends to it's new location) has
been. I've had to carefully craft a set of PR's, and land them in a certain
order. I've encountered contention (because I have to change hundreds of
imports), unit test issues (because juju's dependencies aren't tested when
merged, so they can be incompatible with the latest juju without knowing
it), and circular dependencies that require some magic and wishful thinking
to workaround.

I'm still not finished landing the change, but I hope to do so *soon*. It
must be close now!

All of this to say, I think it would be useful to have a discussion on how
we manage dependencies within the project. From a release perspective, it
can be quite cumbersome as dependencies are picked up and dropped. It's
also recently made a release (And critical bugfix) really difficult at
times. From my newly experience contributor perspective, I would really
think twice before attempting to make an update :-) I suspect I'm not alone.

I've heard ideas in the past about cleaning this up, and some things like
circular dependencies between romulus and juju are probably best described
as tech debt. But there also is some pain in the larger scheme of things.
For example, we are currently hacking a patch to juju's source for the mgo
dependency since updating the source or vendoring or any other option is
way too painful. It's time to really fix this. Ideas?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Uniter test failure from utils update

[Nicholas Skaggs]

Thanks for the insights here. I ended up reverting the offending change,
https://github.com/juju/utils/pull/203. @bogdanteleaga, my apologies for
reverting, but I'm not sure how to fix with your change so I went back to
something that worked. It's worth following up and figuring out how to
re-land it.

On Thu, Aug 11, 2016 at 8:18 AM, William Reade 
wrote:

> (or, at least, it's something like that -- the general point is that you
> shouldn't throw away values you don't know you don't need)
>
> On Thu, Aug 11, 2016 at 2:14 PM, William Reade <
> william.re...@canonical.com> wrote:
>
>> worker/uniter/operation/runcommands.go:68... uses `context.ErrReboot` to
>> indicate "there is a valid response value that should be handled, but we
>> also need to queue a reboot". The change throws away the valid response.
>>
>> On Thu, Aug 11, 2016 at 1:47 AM, Martin Packman <
>> martin.pack...@canonical.com> wrote:
>>
>>> Nicholas was struggling today to land his snapcraft pull request:
>>>
>>> 
>>>
>>> As a side effect this updates some dependencies, including a couple of
>>> changes to juju/utils, which it turns out, causes
>>> UniterSuite.TestRebootFromJujuRun to fail.
>>>
>>> Here's a run of master, which passes:
>>>
>>> 
>>>
>>> Then the failure, just with utils updated to rev 8a9dea0:
>>>
>>> 
>>>
>>> I'm not clear on how the new exec behaviour is actually causing the
>>> test failure:
>>>
>>> 
>>>
>>> So, any insights or suggestions welcome.
>>>
>>>
>>> Note, the log also includes two other errors, but they appear in both
>>> the passing and failing log, so are not actually affecting the test
>>> outcome:
>>>
>>> [LOG] 0:01.631 ERROR juju.apiserver Unable to prime
>>> /tmp/check-1447535164350529303/5/logsink.log (proceeding anyway):
>>> chown /tmp/check-1447535164350529303/5/logsink.log: operation not
>>> permitted
>>>
>>> This code should probably just not be being run under unit test, is
>>> assuming root privs?
>>>
>>> [LOG] 0:03.078 ERROR juju.worker.uniter.context updating agent status:
>>> cannot set invalid status "rebooting"
>>>
>>> The status setting code in uniter is a twisty confusion, I don't know
>>> why this is happening or where the error is being swallowed.
>>>
>>> Martin
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/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: Juju and snappy implementation spike - feedback please

[Nicholas Skaggs]

On Mon, Aug 8, 2016 at 11:49 AM, John Meinel  wrote:

> If we are installing in '--devmode' don't we have access to the unfiltered
> $HOME directory if we look for it? And we could ask for an interface which
> is to JUJU_HOME that would give us access to just $HOME/.local/share/juju
>

> We could then copy that information into the normal 'home' directory of
> the snap. That might give a better experience than having to import your
> credentials anytime you want to just evaluate a dev build of juju.
>
I agree this gets more difficult with the idea of sharing builds -- as you
say, you have to re-add your credentials for each new developer.In regards
to your thoughts on --devmode, it does give you greater access, but some
things are still constrained. The HOME interface doesn't allow access to
dot files or folders by default. So it's not useful in this instance. If
juju were to change where it stores it's configuration files (aka, not in a
dotfolder) this technically becomes not a problem as the current home
interface would allow this.

>
> AIUI, the 'common' folder for a snap is only for different versions of the
> exact same snap, which means that if I publish 'juju-jameinel' it won't be
> able to share anything with 'juju-wallyworld' nor the official 'juju', so
> there isn't any reason to use it.
>
> I don't know exactly how snap content interfaces work, but it might be
> interesting to be able to share the JUJU_HOME between snaps (like they
> intend to be able to share a "pictures" or "music" directory).
>
> If we *don't* share them, then we won't easily be able to try a new Juju
> on an existing controller. (If I just want you to see how the new 'juju
> status' is formatted, you'd rather run it on a controller that has a bunch
> of stuff running.)
>
It's worth mentioning / filing a bug about our needs with the snapcraft
folks to see what options might exist. I've started conversations a few
weeks ago and solved or got good bugs in on other juju issues. I think they
understand the application config limitations / issues, so we can push for
a resolution.

>
>
>
> On Mon, Aug 8, 2016 at 5:05 PM, Ian Booth  wrote:
>
>> Hi folks
>>
>> The below refers to work in a branch, not committed to master.
>>
>> TL:DR; I've made some changes to Juju so that a custom build can be easily
>> snapped and shared. The snap is still required to be run in devmode until
>> new
>> interfaces are done.
>>
>
> ...
>
>
>> 2. As a developer, I want to hack on Juju and try out my changes.
>>
>> hack, hack, hack
>> $ go install github.com/juju/juju/...
>> $ juju bootstrap mycontroller lxd
>>
>> Note: no build-agent (upload-tools) is needed.
>>
>
> So I'd personally be fine if this was changed to:
> $ make 
>
> And the last step of that was actually to create the .tar.gz instead of
> just having a 'jujud' binary. The main reason is that if you look at 'juju
> bootstrap --debug' we actually do spend a fair bit of time doing the 'gzip'
> step (jujud is about 93MB on my disk). Also, it makes it clearer that we
> are building something that would match what we would have if you
> downloaded it from streams.canonical.com.
>
>
>>
>> 3. Packaging released version of Juju
>> This need some work and consultation. It may not be feasible. How to
>> handle
>> agent binaries for different os/arch etc.
>> Maybe we just want to officially package a juju client snap that behaves
>> just
>> like bootstrap today - no jujud agent binary included in snap, the juju
>> client
>> creates the controller and pulls agent binaries from simplestreams.
>>
>
> I don't think we want to do multi-arch snaps, as (ignoring series) we
> build at least 7 different architectures + windows-amd64. We also would
> have to sort out how they would get updates. So I think it makes sense in
> the current time to continue with what we have (until we get to the point
> where we might distribute the agents themselves as snaps.)
>
>
>> About upload tools
>> --
>> So, the need to specify --upload-tools is now almost eliminated. And the
>> name
>> has been changed to --build-agent because that's what it does. (and
>> because the
>> "tools" terminology is something we need to move away from).
>>
>> When Juju bootstraps, it does the following:
>> - look in simplestreams for a compatible agent binary
>> - look in the same directory as the juju client for an agent binary with
>> the
>> exact same version
>>
>
> I'd rather get rid of this one, and have it look for a juju-VERSION.tgz
> instead.
>
>
>> - build an agent binary from source
>>
>
> I feel this one is also really not needed, especially not in the
> production version. Having to do a "make " before you 'juju bootstrap'
> doesn't feel onerous for developers (I think most of us have a 'go install
> github.com/juju/juju/...' in our bash history to do exactly this.)
>
>
>> It stops looking when it finds a suitable binary.
>>
>> As a developer, you would normally hack on 

Juju 2.0-beta9 is here!

[Nicholas Skaggs]

A new development release of Juju, 2.0-beta9 is here!

## What's new?

* New `juju unregister` command for cleaning up local references to 
controllers

  Usage: juju unregister 
* `juju status` has been enhanced for ease of reading
* Removal of support for legacy lxc containers in favor of lxd
* "Services" are now known as "Applications"

## How do I get it?

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

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

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

https://launchpad.net/juju-core/+milestone/2.0-beta9

## Feedback Appreciated!

We encourage everyone to subscribe to the mailing list at 
j...@lists.ubuntu.com

and join us at #juju on freenode.
We would love to hear your feedback and about your 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

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

Re: adding unit tests that take a long time

[Nicholas Skaggs]

On 04/28/2016 10:12 AM, Katherine Cox-Buday wrote:

On 04/27/2016 09:51 PM, Nate Finch wrote:
So, this is exactly why I didn't want to mention the nature of the 
test, because we'd get sidetracked. I'll make another thread to talk 
about that specific test.
Sorry I forced you into it, but it was important to this discussion. I 
was wanting to understand your feelings towards a test you should be 
running regularly as you develop, aka a unit test, that took more than a 
trivial amount of time to actually execute.


I do still want to talk about what we can do for unit tests that take 
a long time.  I think giving developers the option to skip long tests 
is handy - getting a reasonable amount of coverage when you're in the 
middle of the develop/test/fix cycle.  It would be really useful for 
when you're making changes that affect a lot of packages and so you 
end up having to run full tests over and over.  Of course, running 
just the short tests would not give you 100% confidence, but once 
you've fixed everything so the short tests pass, *then* you could do 
a long run for thorough coverage.


I believe Cheryl has something like this in the works and will be 
sending a note out on it soon.


Yes. It is imperative that developers can quickly (and I mean quickly or 
it won't happen!) run unit tests. We absolutely want testruns to be a 
part of the code, build, run iteration loop.
This is a very low friction way to increase developer productivity, 
and something we can implement incrementally.  It can also lead to 
better test coverage over all.  If you write 10 unit tests that 
complete in milliseconds, but were thinking about writing a couple 
longer-running unit tests that make sure things are working 
end-to-end, you don't have the disincentive of "well, this will make 
everyone's full test runs 30 seconds longer", since you can always 
skip them with -short.


The only real negative I see is that it makes it less painful to 
write long tests for no reason, which would still affect landing 
times but hopefully everyone is still aware of the impact of 
long-running tests, and will avoid them whenever possible.


I will gently point out that we were prepared to land a test that 
takes ~17s to run without discussion. The motivations are honest and 
good, but how many others think the same? This is how our test suite 
grows to be unmanageable.


I also agree with Andrew that the nature of the test should be the 
delineating factor. Right now we tend to view everything through the 
lens of the Go testing suite; it's a hammer, and everything is a nail. 
Moving forward, I think we should try much harder to delineate between 
the different types of tests in the so-called test pyramid, 
 place like tests with 
like tests, and then run classes of tests when and where they're most 
appropriate.
I advocate for slotting things into the pyramid, and making sure we are 
right-sized in our testing. What sort of test counts would we come up 
with for tests are each level? Would the base of the pyramid contain the 
bulk of the tests? I suspect many of the juju unit tests are really 
integration tests, and part of the problem that exists now with running 
the unit tests suite. The other thing to note is the higher you go in 
the pyramid, several things happen that work against making it easy for 
developers. The higher the test on the pyramid, the more fragile the 
test is (more prone to intermittent failures, breaking code), the harder 
it is to write, and the longer it takes to run. Those tests at the top 
of the pyramid will absolutely require the most investment and 
maintenance. This is why it's important for our testsuites to be 
right-sized, and for us to think carefully about what we need to test 
and where / how we test it.


To help with semantics, you can simply designate tests as small, medium 
and large based upon how long they take to run. Small being the bottom 
of the pyramid, and large being the top. No need to argue scope which 
can get tricky. So Nate, assuming your test in this case wasn't static 
analysis or code checking (which by the way I would recommend be 
'enforced' at the build bot level) but did require 17 seconds to run, I 
would be hard pressed to place it in the small category. For a codebase 
the size of juju, having even a small percentage of "unit" tests run 
that long would quickly spiral to long overall runtimes. For example, 
even if only 5% of say 500 tests ran for 10 seconds, a full testrun 
still takes over 4 minutes.



Nicholas


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

Re: adding unit tests that take a long time

[Nicholas Skaggs]

This is a timely discussion Nate. I'll avoid saying too much off the 
top, but I do have a question.


On 04/27/2016 12:24 PM, Nate Finch wrote:

I just wrote a test that takes ~16.5 seconds on my machine.
Why does the test take so long? Are you intending it to be a short / 
small scoped test?


Nicholas

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

Re: LXD polish for xenial

[Nicholas Skaggs]

On Mon, Apr 18, 2016 at 2:17 PM, Martin Packman <
martin.pack...@canonical.com> wrote:
>
> For the lxd provider, I understand we're resigned to the user having
> to manually configure a bridge for lxd before bootstrap can work.
> Currently the documentation is confused as to what exactly the steps
> are, the release notes refer to these two links:
>
> 
> 
>
> But I think the latest advice is as committed with this change to our
> documentation:
>
> 
>
> Note that just running dpkg-reconfigure is not enough, you have to
> poke a service or run `lxc` afterwards or you get this error with
> beta4:
>
> $ juju bootstrap --config default-series=xenial lxd-test lxd
> ERROR cannot find network interface "lxcbr0": route ip+net: no
> such network interface
> ERROR invalid config: route ip+net: no such network interface
>
> That's probably the cause of the other confusion in the updated docs -
> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
> already has lxc setup in some fashion there's a different error from
> juju telling them to run the dpkg-reconfigure command. That should
> presumably always appear whenever there's no usable bridge.
>
The flip flopping back and forth on the bridge name is going to cause havoc
even after release. Do we have clear direction now from LXD on how they
plan to handle the competing network bridge names? I understand we're now
saying a dpkg-reconfigure is required, but I'm not clear if / when we plan
to make this easier.

> Unlike other providers, lxd exposes no way to use the daily images
> instead of release images, so at present any machine using lxd
> containers with juju for the first time will get the xenial beta2
> image then upgrade basically every package. This issue goes away next
> week, but gets in the way of testing before then.
>
I think some workarounds for this were discussed -- did we have any success
here? Do we have an issue filed upstream on this?


>
> In a related note, the lxc container handling in juju manages images
> on the state server, but from what I see of the lxd code, each
> deployed machine will fetch images from cloud-images.ubuntu.com and
> keep a separate set of images. That makes the above problem much worse
> for any bundle with multiple machines that use containers.
>
Same as above. I just want to make sure we don't loose sight of this and do
our part in reporting it so upstream can seek to resolve at some point.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Nicholas Skaggs]

On Mon, Apr 18, 2016 at 7:57 PM, Marco Ceppi 
wrote:

> Thanks so much for spending time on this polish! It'll really help our
> user experience shine for cost effective dev.
>
> On Mon, Apr 18, 2016, 2:17 PM Martin Packman 
> wrote:
>
>> When it comes to using lxd in clouds, as I understand it we've settled
>> on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
>> mean bundles have to be manually changed at present to start using
>> lxd. Most of the CI bundle testing is using real bundles out of the
>> store, which all still say 'lxc' and therefore don't exercise the lxd
>> container code at all.
>>
>
> This bit confused me, and I realize this is late in the cycle, but I'd be
> remiss if I didn't at least float the though.
>
> I would have expected juju to do the right thing for bundles. With what
> you've stated, we now have bundles that won't deploy in 1.25 that will in
> 2.0 and vice versa despite charms supporting both. This seems like a step
> backwards from a UX.
>
Are you concerned bundles will have to be written specific to both lxc and
lxd to support 1.25 and 2.0?  (one using lxc and the other lxd?)

>
> What's the reasons behind this? Will there be a min-juju-version like in
> charms? (Hopefully not)
>
> My expectation would have been juju 1.25 for lxc placement produces a
> lxc-1 container and in 2.0 produces a lxd/lxc-2 container.
>
> Marco, I'm guessing for your expectation to work here, juju2 would have
simply kept all of the juju-1 lxc code and supported both lxc and lxd? As
Martin demonstrated, just swapping a bundle to use lxd instead of lxc
fails, which I think is to be expected. Is there something else you were
looking for here?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev