lp:~axwalk/juju-core/jujud-uninstallscript

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

2043. By Andrew Wilkins on 2013-11-13

Remove mongodb and data-dir on machine-agent termination

This CL is about cleaning up manual environment state
servers. When a manual environment state server is torn
down, it should remove its juju-db service as well as
its own (i.e. the machine-agent upstart service), and
finally remove the data-dir.

This is implemented by adding an UNINSTALL_SCRIPT entry
into the machine-agent's agent.conf. The machine agent
will extract this when it terminates, copy it out to a
file, and execute it. environs/cloudinit takes care of
generating the script based on what gets installed on
the machine.

2042. By William Reade on 2013-11-10

[r=jameinel],[bug=1233457] state: unit removal departs relation scopes

Fixes lp:1233457

https://codereview.appspot.com/23080045/

2041. By Ian Booth on 2013-11-08

[r=wallyworld] Migrate manual provisioning to API

Manual provisioning now works using the API.
Two new client endpoints are provided:
InjectMachines
MachineConfig

The MachineConfig API is similar to the ContainerConfig
used by the local provider, however more information
is required in order to handle provisioning bootstrap
as well as normal host nodes.

Some refactoring of the ProvisionManchine method was also
done to split it into smaller chunks.

https://codereview.appspot.com/23440043/

2040. By Andrew Wilkins on 2013-11-08

[r=axwalk] Migrate ssh-based CLI commands to API

Two new client API methods are introduced:
  - ServiceCharmRelations
  - PublicAddress

ServiceCharmRelations returns the names of
all charm relations for the given service.
This method is used to validate hook names
for debug-hooks.

PublicAddress takes a string, which must be
either a machine ID or unit ID. The call will
return the machine or unit's public address,
or an error if the entity does not have one.

The ssh-based commands (ssh, scp, debug-log
and debug-hooks) now use these methods instead
of going directly to state. The one major
change is that, previously, they used the
instance.Instance.WaitDNSName method to get
a host address. We now use PublicAddress,
which is populated by the machine-agent's
address updater.

Note that debug-log does not use any new
log-specific API; that is a much larger task,
and out of scope here.

https://codereview.appspot.com/23380045/

2039. By Ian Booth on 2013-11-08

[r=wallyworld] Migrate add-machine to api

add-machine command is migrated to api.
This command is really dual personality - it can
add a machine to be provisioned by a cloud provider
or it can add an exisitng machine using ssh. The first
case is fully migrated. The second case has been
refactored to move all the direct state/mgo connection
stuff into the manual provisioning code. A more
substantial refactoring is needed to fully migrate the
manual provisioning case.

https://codereview.appspot.com/22580043/

2038. By Andrew Wilkins on 2013-11-07

[r=axwalk] Push environment secrets after connecting API

This is a much simpler alternative to
https://codereview.appspot.com/22080044/,
implementing the same logic as is present
for the straight-to-state juju.NewConn.

As secrets-pushing will be obsoleted by
synchronous bootstrapping, which is slated
for introduction soon, I have a strong
preference for this option.

There's a drive-by-fix to the EnvironmentSet
API which simplifies testing: allow agent-version
in the parameters as long as it matches the
existing value.

https://codereview.appspot.com/22720043/

2037. By John A Meinel on 2013-11-07

[r=jameinel] state/unit/machine/user: change password hashes

This is a follow up to my previous PasswordHash changes, making it a
more complete step.

1) PasswordHash is split into 3 functions:

   UserPasswordHash(password, salt) passwordhash
   CompatPasswordHash(password) passwordhash {
      return UserPasswordHash(password, oldDefaultSalt)
   }
   AgentPasswordHash(password) passwordHash, error

2) UserPasswordHash does the same 8192 rounds of pbkdf2 hashing to
ensure that it is hard to brute force a user's password. On top of
that, it requires a "salt" value.

state/User grows an added field PasswordSalt. Whenever we call
User.SetPassword we generate a salt and use that to compute the
password hash.

For compatibility, if User.PasswordSalt is the empty string, we use
the CompatPasswordHash which sets the salt to the old hard-coded salt.
I chose to use a different function to make it clear that we don't
really want to support empty salts.

3) User.PasswordValid(password) knows how to check both ways for
compatibility, and if it sees that the saved hash was not salted, it
calls SetPassword() immediately to set a salt and regenerate the
password hash.

4) For Machine and Unit agents, we change their hash function to just
be a simple SHA-512 of the password. We don't bother with a salt or
with iterated pbkdf2. This is because we know that agents have very
high entropy passwords (utils.RandomPassword uses 18 bytes of entropy
or 2^144). This is not really feasible to brute force, so there isn't
really a point to salt or iterate.

As part of this change, AgentPasswordHash(string) string, error can
return an error if it appears the password might not have enough
entropy (for now we just check the length of the password). That way
someone can't accidentally get rooted because they set the machine-0
agent password to "foo".

This probably had the widest effect as we had a lot of tests that set
a simple password just so we could login as that agent, but we just
change it so we use utils.RandomPassword in all of those places.

As mentioned before, this is a big performance win when scaling up to
thousands of agents. Timing shows UserPasswordHash takes about 80ms,
while AgentPasswordHash takes about 8us. PasswordHash was dominating
the time it took for the system to recover after restarting the API
machine.

5) Similar to User.PasswordValid, Machine.PasswordValid and
Unit.PasswordValid will do a fast check using AgentPasswordValid, and
if that fails, they will fall back to the slow CompatPasswordValid. If
they find the passwordhash is a compat value, they reset the value to
the fast-path value.

https://codereview.appspot.com/21000044/

2036. By Dimiter Naydenov on 2013-11-06

[r=dimitern],[bug=1246983] cmd/juju: get- and set-environment using the API

Implemented EnvironmentGet and EnvironmentSet in
the client API and changed the get-environment
and set-environment commands to use that instead
of connecting to state directly.

https://codereview.appspot.com/22210044/

R=fwereade

2035. By John A Meinel on 2013-11-06

[r=jameinel],[bug=1205371] state/apiserver/uniter: use cached APIAddresses

When Roger changed the common.Addresser code to use the cached
addresses, he missed the fact that Uniter had its own implementation.
This was because we weren't exposing StateAddress or CACert to the
Uniter. So this change moves the code around to share the common
APIAddresses method and uses it in the Uniter facade.

This also changes common.Addresser to be named common.StateAddresser
to make it clearer what is going on.

https://codereview.appspot.com/20940043/

2034. By Nate Finch on 2013-11-05

[r=natefinch] API endpoint for set. There actually already was an endpoint that was used by the GUI, but it has logic to treat empty strings as unsetting the configuration value, which is not the behavior we want. To maintain compatibility with the GUI, I created a new endpoint to be used by the client, called NewServiceSetForClientAPI, an intentionally ugly name to remind us that we want to merge the two functions as soon as possible. This new endpoint does not treat empty strings specially, so if you set a configuration value to an empty string it'll be set to an empty string, and you should use unset to unset it.