lp://staging/~cmars/juju-core/local-repo-resolve

Created by Casey Marshall and last modified
Get this branch:
bzr branch lp://staging/~cmars/juju-core/local-repo-resolve
Only Casey Marshall can upload to this branch. If you are Casey Marshall please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Casey Marshall
Project:
juju-core
Status:
Development

Recent revisions

2594. By Casey Marshall

Local repo chooses best series when ambiguous.

Fixes LP: #1303880. When a series is not specified, choose the latest LTS
series matching the charm name, followed by latest series found in the repo.

2593. By Roger Peppe

[r=natefinch] The machine agent is now responsible for setting up mongo. Cloud Init is no longer used to set up the upstart script. Mongo now starts with --replSet and the replicaset gets initiated. We still start just a single machine, but more machines will be able to be added later (once we have code to do so).

2592. By John A Meinel

[r=jameinel],[bug=1304340] state/apiserver/upgrader: Managers upgrade first

This addresses bug #1304340. It gives us a step along the path of having
Manager nodes (API Servers) upgrade themselves before we have all the
other machine agents upgrade (before we have the Unit agents upgrade).
We already had the last two steps. This isn't 100% reliable in HA
circumstances, because we aren't waiting for *all* nodes to be upgraded.

We could potentially change the check so it was just if DesiredVersion
!= CurrentVersion (rather than >= CurrentVersion). It also doesn't probe
the database unless there is an upgrade pending, so DesiredVersion
should still be cheap. This doesn't change FindTools, but it doesn't
seem like it needs to. (All places that call FindTools first call
DesiredVersion, because we broke stuff in the past when we didn't have
API Credentials in time.)

Also, this falls back to returning version.Current rather than returning
the version of the machine/unit/etc had recorded in State. I'm not sure
if that is worth implementing, but when we do the DB lookup to find out
if this entity.IsManager() we could grab its current version.

https://codereview.appspot.com/85450043/

2591. By Wayne Witzel III

[r=jameinel] cleanup: fixing go vet warnings

Cleanup code that has go vet warnings.

https://codereview.appspot.com/81570045/

2590. By Dimiter Naydenov

[r=dimitern] state;api: Allow adding existing networks/NICs

Added an AlreadyExistsError in errors/ and in
state/api/params with IsAlreadyExistsError and
IsCodeAlreadyExists helpers. This is used in
the provisioner API to report networks and
interfaces that already exist, and is needed
so that when provisioning more machines on the
same network wont' lead to errors (trying to
add existing network/NIC is just ignored).

https://codereview.appspot.com/85380043/

2589. By Ian Booth

[r=wallyworld],[bug=1302205],[bug=1304132] Noisy instance poller

The instance poller was trying to poll instances which
are not yet provisioned, as well as manual instances, creating lots of log noise.
This fixes that.

https://codereview.appspot.com/85770043/

2588. By Ian Booth

[r=wallyworld],[bug=1302205] Force manual storage-port to int

The manual provider storage-port config
attribute needs to have a schema definition
of ForceInt so it can be deserialised from
state correctly.

https://codereview.appspot.com/85750045/

2587. By Roger Peppe

[r=rogpeppe] cmd/jujud: upgradeWorker opens state

The scheme that this replaces makes an unwarrantedly chummy
relationship between APIWorker and StateWorker.
(and it panicked when StateWorker was invoked more
than once).

We fix it by making an independent connection to the
state for the upgrader's needs.

We also refactor some of the testing code
to move as much test-related logic out of the
production code as possible and to merge some
duplicated code.

https://codereview.appspot.com/85450044/

2586. By Abel Deuring

[r=TheMue][bug=1227574] Remove OpenStack security groups a machine is removed or the environment is destroyed.

2585. By Nate Finch

[r=natefinch] support mongo namespaces

This change consolidates the name of the juju mongo database where it belongs - in the code that creates the scripts for mongo. It also fixes several bugs that were introduced due to the name change of the mongo service. Finally, it removes the ability to specify the exact name of the mongo service, but it still lets you add a namespace to prevent conflicts. This is necessary to support removal of old scripts.... the mongo code needs to control how the names are constructed.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp://staging/~go-bot/juju-core/trunk
This branch contains Public information 
Everyone can see this information.

Subscribers