Juju stable 1.25.3 is now released

[Curtis Hovey-Canonical]

# juju-core 1.25.3

A new stable release of Juju, juju-core 1.25.3, is now available.
This release replaces version 1.25.0.


## Getting Juju

juju-core 1.25.3 is available for Xenial and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/stable

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

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


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * Unit loses network connectivity during bootstrap: juju 1.25.2 +
maas 1.9
Lp 1534795

 * "cannot allocate memory" when running "juju run"
Lp 1382556

  * Bootstrap with the vsphere provider fails to log into the virtual
machine
Lp 1511138

  * Add-machine with vsphere triggers machine-0: panic: juju home
hasn't been initialized
Lp 1513492

  * Using maas 1.9 as provider using dhcp nic will prevent juju
bootstrap
Lp 1512371

  * Worker/storageprovisioner: machine agents attempting to attach
environ-scoped volumes
Lp 1483492

  * Restore: agent old password not found in configuration
Lp 1452082

  * "ignore-machine-addresses" broken for containers
Lp 1509292

  * Deploying a service to a space which has no subnets causes the
agent to panic
Lp 1499426

  * /var/lib/juju gone after 1.18->1.20 upgrade and manual edit of
agent.conf
Lp 1444912

  * Juju bootstrap fails to successfully configure the bridge juju-br0
when deploying with wily 4.2 kernel
Lp 1496972

  * Incompatible cookie format change
Lp 1511717

  * Error environment destruction failed: destroying storage: listing
volumes: get https://x.x.x.x:8776/v2//volumes/detail: local
error: record overflow
Lp 1512399

  * Replica set emptyconfig maas bootstrap
Lp 1412621

  * Juju can't find daily image streams from cloud-
images.ubuntu.com/daily
Lp 1513982

  * Rsyslog certificate fails when using ipv6/4 dual stack with
prefer-ipv6: true
Lp 1478943

  * Improper address:port joining
Lp 1518128

  * Juju status  broken
Lp 1516989

  * 1.25.1 with maas 1.8: devices dns allocation uses non-unique
hostname
Lp 1525280

  * Increment minimum juju version for 2.0 upgrade to 1.25.3
Lp 1533751

  * Make assignment of units to machines use a worker
Lp 1497312

  * `juju environments` fails due to missing ~/.juju/current-
environment
Lp 1506680

  * Juju 1.25 misconfigures juju-br0 when using maas 1.9 bonded
interface
Lp 1516891

  * Destroy-environment on an unbootstrapped maas environment can
release all my nodes
Lp 1490865

  * On juju upgrade the security group lost ports for the exposed
services
Lp 1506649

  * Support centos and windows image metadata
Lp 1523693

  * Upgrade-juju shows available tools and best version but did not
output what it decided to do
Lp 1403655

  * Invalid binary version, version "1.23.3--amd64" or "1.23.3--armhf"
Lp 1459033

  * Add xenial to supported series
Lp 1533262


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


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

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

Re: Tags and object IDs

[William Reade]

On Mon, Jan 25, 2016 at 12:07 PM, Nate Finch 
wrote:

> I was really trying not to give too much information about this exact
> case, so we could avoid talking about a specific implementation, and focus
> on the more general question of how we identify objects.  Yes, we get the
> bytes using an HTTP request, but that is irrelevant to my question :)
>

I thought I did answer the question:

But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>>> have much the same stuff available in the apiserver, in which case I think
>>> you just want to pass the *Unit back into state; without it, you just need
>>> to read the doc from the DB all over again to make appropriate
>>> liveness/existence checks [0], and why bother unless you've already hit an
>>> assertion failure in your first txn attempt?
>>>
>>
...but perhaps I misunderstood what you were looking for?

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

Re: Tags and object IDs

[Nate Finch]

I was really trying not to give too much information about this exact case,
so we could avoid talking about a specific implementation, and focus on the
more general question of how we identify objects.  Yes, we get the bytes
using an HTTP request, but that is irrelevant to my question :)

On Mon, Jan 25, 2016 at 2:00 AM John Meinel  wrote:

> On Sat, Jan 23, 2016 at 1:28 AM, William Reade <
> william.re...@canonical.com> wrote:
>
>> On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch 
>> wrote:
>>
>>> Working in the model layer on the server between the API and the DB.
>>> Specifically in my instance, an API call comes in from a unit, requesting
>>> the bytes for a resource.  We want to record that this unit is now using
>>> the bytes from that specific revision of the resource.  I have a pointer to
>>> a state.Unit, and a function that takes a Resource metadata object and some
>>> reference to the unit, and does the actual transaction to the DB to store
>>> the unit's ID and the resource information.
>>>
>>
>> I'm a bit surprised that we'd be transferring those bytes over an API
>> call in the first place (is json-over-websocket really a great way to send
>> potential gigabytes? shouldn't we be getting URL+SHA256 from the apiserver
>> as we do for charms, and downloading separately? and do we really want to
>> enforce charmstore == apiserver?); and I'd point out that merely having
>> agreed to deliver some bytes to a client is no indication that the client
>> will actually be using those bytes for anything; but we should probably
>> chat about those elsewhere, I'm evidently missing some context.
>>
>
> So I would have expected that we'd rather use a similar raw
> HTTP-to-get-content instead of a JSON request (given the intent of
> resources is that they may be GB in size), but regardless it is the intent
> that you download the bytes from the charm rather from the store directly.
> Similar to how we currently fetch the charm archive content itself.
> As for "will you be using it", the specific request from the charm is when
> it calls "resource-get" which is very specifically the time when the charm
> wants to go do something with those bytes.
>
> John
> =:->
>
>
>> But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>> have much the same stuff available in the apiserver, in which case I think
>> you just want to pass the *Unit back into state; without it, you just need
>> to read the doc from the DB all over again to make appropriate
>> liveness/existence checks [0], and why bother unless you've already hit an
>> assertion failure in your first txn attempt?
>>
>> Cheers
>> William
>>
>> [0] I imagine you're not just dumping (unit, resource) pairs into the DB
>> without checking that they're sane? that's really not safe
>>
>>
>>> On Fri, Jan 22, 2016 at 3:34 PM William Reade <
>>> william.re...@canonical.com> wrote:
>>>
 Need a bit more context here. What layer are you working in?

 In general terms, entity references in the API *must* use tags; entity
 references that leak out to users *must not* use tags; otherwise it's a
 matter of judgment and convenience. In state code, it's annoying to use
 tags because we've already got the globalKey convention; in worker code
 it's often justifiable if not exactly awesome. See
 https://github.com/juju/juju/wiki/Managing-complexity#workers

 Cheers
 William

 On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch 
 wrote:

> I have a function that is recording which unit is using a specific
> resource.  I wrote the function to take a UnitTag, because that's the
> closest thing we have to an ID type. However, I and others seem to 
> remember
> hearing that Tags are really only supposed to be used for the API. That
> leaves me with a problem - what can I pass to this function to indicate
> which unit I'm talking about?  I'd be fine passing a pointer to the unit
> object itself, but we're trying to avoid direct dependencies on state.
> People have suggested just passing a string (presumably
> unit.Tag().String()), but then my API is too lenient - it appears to say
> "give me any string you want for an id", but what it really means is "give
> me a serialized UnitTag".
>
> I think most places in the code just use a string for an ID, but this
> opens up the code to abuses and developer errors.
>
> Can someone explain why tags should only be used in the API? It seems
> like the perfect type to pass around to indicate the ID of a specific
> object.
>
> -Nate
>
> --
> 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:
>> 

Re: Tags and object IDs

[John Meinel]

I think to William's point, we should have already authenticated the unit
as part of the API request, thus we should have a Unit object hanging
around somewhere close to where that request is being made, and can just
pass it into state.

John
=:->

On Mon, Jan 25, 2016 at 3:07 PM, Nate Finch 
wrote:

> I was really trying not to give too much information about this exact
> case, so we could avoid talking about a specific implementation, and focus
> on the more general question of how we identify objects.  Yes, we get the
> bytes using an HTTP request, but that is irrelevant to my question :)
>
> On Mon, Jan 25, 2016 at 2:00 AM John Meinel 
> wrote:
>
>> On Sat, Jan 23, 2016 at 1:28 AM, William Reade <
>> william.re...@canonical.com> wrote:
>>
>>> On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch 
>>> wrote:
>>>
 Working in the model layer on the server between the API and the DB.
 Specifically in my instance, an API call comes in from a unit, requesting
 the bytes for a resource.  We want to record that this unit is now using
 the bytes from that specific revision of the resource.  I have a pointer to
 a state.Unit, and a function that takes a Resource metadata object and some
 reference to the unit, and does the actual transaction to the DB to store
 the unit's ID and the resource information.

>>>
>>> I'm a bit surprised that we'd be transferring those bytes over an API
>>> call in the first place (is json-over-websocket really a great way to send
>>> potential gigabytes? shouldn't we be getting URL+SHA256 from the apiserver
>>> as we do for charms, and downloading separately? and do we really want to
>>> enforce charmstore == apiserver?); and I'd point out that merely having
>>> agreed to deliver some bytes to a client is no indication that the client
>>> will actually be using those bytes for anything; but we should probably
>>> chat about those elsewhere, I'm evidently missing some context.
>>>
>>
>> So I would have expected that we'd rather use a similar raw
>> HTTP-to-get-content instead of a JSON request (given the intent of
>> resources is that they may be GB in size), but regardless it is the intent
>> that you download the bytes from the charm rather from the store directly.
>> Similar to how we currently fetch the charm archive content itself.
>> As for "will you be using it", the specific request from the charm is
>> when it calls "resource-get" which is very specifically the time when the
>> charm wants to go do something with those bytes.
>>
>> John
>> =:->
>>
>>
>>> But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>>> have much the same stuff available in the apiserver, in which case I think
>>> you just want to pass the *Unit back into state; without it, you just need
>>> to read the doc from the DB all over again to make appropriate
>>> liveness/existence checks [0], and why bother unless you've already hit an
>>> assertion failure in your first txn attempt?
>>>
>>> Cheers
>>> William
>>>
>>> [0] I imagine you're not just dumping (unit, resource) pairs into the DB
>>> without checking that they're sane? that's really not safe
>>>
>>>
 On Fri, Jan 22, 2016 at 3:34 PM William Reade <
 william.re...@canonical.com> wrote:

> Need a bit more context here. What layer are you working in?
>
> In general terms, entity references in the API *must* use tags; entity
> references that leak out to users *must not* use tags; otherwise it's a
> matter of judgment and convenience. In state code, it's annoying to use
> tags because we've already got the globalKey convention; in worker code
> it's often justifiable if not exactly awesome. See
> https://github.com/juju/juju/wiki/Managing-complexity#workers
>
> Cheers
> William
>
> On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch 
> wrote:
>
>> I have a function that is recording which unit is using a specific
>> resource.  I wrote the function to take a UnitTag, because that's the
>> closest thing we have to an ID type. However, I and others seem to 
>> remember
>> hearing that Tags are really only supposed to be used for the API. That
>> leaves me with a problem - what can I pass to this function to indicate
>> which unit I'm talking about?  I'd be fine passing a pointer to the unit
>> object itself, but we're trying to avoid direct dependencies on state.
>> People have suggested just passing a string (presumably
>> unit.Tag().String()), but then my API is too lenient - it appears to say
>> "give me any string you want for an id", but what it really means is 
>> "give
>> me a serialized UnitTag".
>>
>> I think most places in the code just use a string for an ID, but this
>> opens up the code to abuses and developer errors.
>>
>> Can someone explain why tags should only