juju/juju

…ses-1.24

1509292: ignore machine addresses 1.24

Ignore machine addresses should be ignored for containers, which only have machine addresses.

(Review request: http://reviews.vapour.ws/r/2992/)

Do not panic if api address info is missing from agent conf

Fixes: https://bugs.launchpad.net/juju-core/+bug/1392814

If the is api address info missing from agent conf, we used to panic. Now just an error is returned.

(Review request: http://reviews.vapour.ws/r/2957/)

cmd/juju/status: added environment-status section (1.24)

1. The recently added top-level available-version section is now underneath a new environment-status section. This section will later be used to also show information about environment migration and other
high-level concerns. The environment-status section is only displayed when there's something to be shown in it.

2. The display of an available upgrade was removed from the oneline formatter. The upgrade notification was being shown as if it was a unit which is confusing and could break automated parsing. Given the tight focus of the oneline output (showing the units and subordinates) I think it's best not to even attempt to include the upgrade notification there.

3. The tests have been cleaned up. Instead of making it appear an upgrade is available during all status tests - requiring that all expected output include the upgrade notification, even when a test case has nothing to do with the upgrade notification - there are now specific tests for the upgrade notification.

(Review request: http://reviews.vapour.ws/r/2954/)

1. The recently added top-level available-version section is now
underneath a new environment-status section. This section will later
be used to also show information about environment migration and other
high-level concerns. The environment-status section is only displayed
when there's something to be shown in it.

2. The display of an available upgrade was removed from the oneline
formatter. The upgrade notification was being shown as if it was a
unit which is confusing and could break automated parsing. Given the
tight focus of the oneline output (showing the units and subordinates)
I think it's best not to even attempt to include the upgrade
notification there.

3. The tests have been cleaned up. Instead of making it appear an
upgrade is available during all status tests - requiring that all
expected output include the upgrade notification, even when a test
case has nothing to do with the upgrade notification - there are now
specific tests for the upgrade notification.

Increment juju to 1.24.8

Fix MAAS /etc/network/interfaces for dhcp with aliases - 1.24

A minor fix for rendering of /etc/network/interfaces when using DHCP with aliases.

(Review request: http://reviews.vapour.ws/r/2899/)

make it more explicit that we're removing nils during createSettingsOp

This is a much more explicit fix for https://bugs.launchpad.net/juju-core/+bug/1495681

Nil values should not be set during create, since at all other times, a nil value means to delete the value (and use the default).  This change makes createSettingsOp explicitly remove nils itself, rather than relying on callers to do so themselves.  This simplifies the caller's code, and makes for better separation of concerns.  It's also more obvious than running the settings through the state.Settings value just to get a side effect of deleting nil values.

(Review request: http://reviews.vapour.ws/r/2680/)

1494476 maas 1.9 bootstrap issue - backport

 Fix cloud init to handle the static network configuration used by maas 1.9. Also separate out that part of the cloud init so that it can be unit tested on its own.

(Review request: http://reviews.vapour.ws/r/2895/)

More robust configstore lock.

Retry unlocking if it fails, longer acquire timeout, and explicit break lock if time over expectations.

(Review request: http://reviews.vapour.ws/r/2889/)

…ak lock if time over expectations.

agent: SetAPIHostPorts now uses all candidate addresses for each server (1.24)

network: added SelectInternalHostPorts

This is like SelectInternalHostPort but selects all the best candidate addresses, instead of just one of them. The logic for selecting the best matching addresses has been cleaned up and reworked in terms of selecting multiple addresses.

---

agent: SetAPIHostPorts now uses all candidate addresses for each server

SetAPIHostPorts used to pick just one address for each API server. It now writes all best-matched addresses (using the new SelectInternalHostPorts).

Fixes LP #1497094.

(Review request: http://reviews.vapour.ws/r/2853/)

SetAPIHostPorts used to pick just one address for each API server. It
now writes all best-matched addresses (using the new
SelectInternalHostPorts).

Fixes LP #1497094.

This is like SelectInternalHostPort but selects all the best candidate
addresses, instead of just one of them. The logic for selecting the
best matching addresses has been cleaned up and reworked in terms of
selecting multiple addresses.

Reintroduce storage feature flag for 1.24

Storage was classified as experimental in 1.24, and has been found to be
problematic. Since storage is used implicitly by charms with default
stores, we should disable it to prevent breaking deployments.

Fixes https://bugs.launchpad.net/juju-core/+bug/1503740

(Review request: http://reviews.vapour.ws/r/2841/)

lp1373516 - Change default ec2 instance to m3.medium

This PR changes the selection of ec2 instance types to follow
the following rules:

- m1 instances will only be selected if explicitly specified using
the instance-type=m1.* constraint

- if no constraints are specified, the default instance type will
be m3.medium

- if constraints are specified, m1 instance types which satisfy
the constraints will not be selected for deployment

(Review request: http://reviews.vapour.ws/r/2844/)

This PR changes the selection of ec2 instance types to follow
the following rules:

- m1 instances will only be selected if explicitly specified using
the instance-type=m1.* constraint

- if no constraints are specified, the default instance type will
be m3.medium

- if constraints are specified, m1 instance types which satisfy
the constraints will not be selected for deployment

Storage was classified as experimental in 1.24, and has been found to be
problematic. Since storage is used implicitly by charms with default
stores, we should disable it to prevent breaking deployments.

Fixes https://bugs.launchpad.net/juju-core/+bug/1503740

Set preferred addresses on machine creation

Fix for issue #1499571 

Newly created machines now have preferred addresses set from the provided template.

(Review request: http://reviews.vapour.ws/r/2835/)