Re: Automatic retries of hooks

[roger peppe]

On 21 January 2016 at 09:51, James Page  wrote:
> On Wed, 20 Jan 2016 at 20:31 William Reade 
> wrote:
>>
>> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer 
>> wrote:
>>>
>>> You realize James was complaining and not celebrating the "success" ? The
>>> fact that we can have a discussion trying to determine whether something is
>>> a bug or a feature indicates a problem.
>>
>>
>> Sorry, I didn't intend to disparage his experience; I took it as
>> legitimate and reasonable surprise at a change we evidently didn't
>> communicate adequately. But I don't think it's a misfeature; I think it's a
>> necessary approach, in service of global reliability in challenging
>> environments.
>
>
> You didn't - don't worry!
>
>>
>> But: if there are times it's inconvenient and not just surprising, we
>> should surely be able to disable it. Gabriel/Bogdan, would you be able to
>> address this?
>
>
> I Agree with David's +1 on this feature with the condition that it can be
> disabled so that charm authors actually understand the behaviour of the
> software they are deploying.
>
> Please lets also ensure the retry limit is sensible - otherwise we might end
> up with end-users waiting a loong time to understand that something is
> not recoverable which could be equally as damaging.

It would perhaps be good if the default status showed that
the hook was being retried. On the other hand, if retries
become common, then it could be the basis of any number
of false-alarm support calls.

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

Re: Automatic retries of hooks

[James Page]

On Wed, 20 Jan 2016 at 20:31 William Reade 
wrote:

> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer 
> wrote:
>>
>> You realize James was complaining and not celebrating the "success" ? The
>> fact that we can have a discussion trying to determine whether something is
>> a bug or a feature indicates a problem.
>>
>
> Sorry, I didn't intend to disparage his experience; I took it as
> legitimate and reasonable surprise at a change we evidently didn't
> communicate adequately. But I don't think it's a misfeature; I think it's a
> necessary approach, in service of global reliability in challenging
> environments.
>

You didn't - don't worry!


> But: if there are times it's inconvenient and not just surprising, we
> should surely be able to disable it. Gabriel/Bogdan, would you be able to
> address this?
>

I Agree with David's +1 on this feature with the condition that it can be
disabled so that charm authors actually understand the behaviour of the
software they are deploying.

Please lets also ensure the retry limit is sensible - otherwise we might
end up with end-users waiting a loong time to understand that something
is not recoverable which could be equally as damaging.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Defaulting tests internal to the package

[Nate Finch]

[reposting this to the wider juju-dev mailing list]

So, I hit an interesting problem a while back.  I have some unit tests that
need to be internal tests, thus they are in 'package foo'.  However, my
code needs to use some testhelper functions that someone else wrote...
which are in 'package foo_test'.  It's impossible to reference those, so I
had to move those helpers to package foo, which then either requires that
we make them exported (which is exactly like using export_test.go, which,
in the juju-core Oakland sprint, we all agreed was bad), or all tests that
use the helpers need to be in 'package foo'... which means I had to go
change a bunch of files to be in package foo, and change the calls in those
files from foo.SomeFunc() to just SomeFunc().

Given the assumption that some tests at some point will make sense to be
internal tests, and given it's likely that helper functions/types will want
to be shared across suites - should we not just always make our tests in
package foo, and avoid this whole mess in the first place?

(A note, this happened again today - I wanted to add a unit test of a
non-exported function to an existing test suite, and can't because the unit
tests are in the foo_test package)

There seems to only be two concrete benefits to putting tests in package
foo_test:
1. It avoids circular dependencies if your test needs to import something
that imports the package you're testing.
2. It makes your tests read like normal usages of your package, i.e.
calling foo.SomeFunc().
The first is obviously non-negotiable when it comes up... but I think it's
actually quite rare (and might indicate a mixture of concerns that warrants
investigation).  The second is nice to have, but not really essential (if
we want tests that are good examples, we can write example functions).

So, I propose we put all tests in package foo by default.  For those devs
that want to only test the exported API of a package, you can still do
that.  But this prevents problems where helper code can't be shared between
the two packages without ugliness and/or dumb code churnm, and it means
anyone can add unit tests for non-exported code without having to create a
whole new file and testsuite.

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

Juju devel 2.0-alpha1 is available for testing

[Curtis Hovey-Canonical]

# juju-core 2.0-alpha1

A new development release of Juju, juju-core 2.0-alpha1, is now available.
This release replaces version 1.26-alpha3.


## Getting Juju

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

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

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

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

Development releases use the "devel" simple-streams. You must configure
the 'agent-stream' option in your environments.yaml to use the matching
juju agents.

Upgrading from older releases to this development release is not
supported.


## Notable Changes

* Terminology
* Testing Advice
* Command Name Changes
* Multi-Model Support Active by Default
* Native Support for Charm Bundles
* Multi Series Charms
* Improved Local Charm Deployment
* LXD Provider
* Microsoft Azure Resource Manager Provider
* Bootstrap Constraints, Series
* Juju Logging Improvements
* Unit Agent Improvements
* API Login with Macaroons
* MAAS 1.8 Compatibility


### Terminology

In Juju 2.0, environments will now be referred to as "models".  Commands
which referenced "environments" will now reference "models".  Example:

juju get-environment

will become

juju get-model


The "state-server" from Juju 1.x becomes a "controller" in 2.0. The
change in terminology will be done across several alphas, so messages
and errors provided by juju may still reference "environments".


### Testing Advice

Juju 2.0's new features and behaviours will confuse older Juju clients.
It is best to create a new juju home to ensure you can revert to a 1.x
Juju client. You can move an existing .juju/ directory out of the way or
create a new directory and export it for Juju to find like so:

export JUJU_HOME=~/new-juju-testing

If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x
reports problems with the environment, you can delete ~/.go-cookie and
the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x.
Juju 2.0 will store its data in a new location soon.

It is not possible to test an upgrade from Juju 1.x to 2.0 at this time.
Juju will support this in future releases.


### Command Name Changes

After a while experimenting with nested command structures, the decision
was made to go back to a flat command namespace as the nested commands
always felt clumsy and awkward when being used even though they seemed
like a good idea.

So, we have the following changes:

1.25 command   2.0-alpha1 command

juju environment destroy   juju destroy-environment *
juju environment get   juju get-environment **
juju environment get-constraints   juju get-constraints **
juju environment retry-provisioningjuju retry-provisioning
juju environment set   juju set-environment **
juju environment set-constraints   juju set-constraints **
juju environment share juju share-environment
juju environment unset juju unset-environment **
juju environment unshare   juju unshare-environment
juju environment users juju list-shares
juju user add  juju add-user
juju user change-password  juju change-user-password
juju user credentials  juju get-user-credentials
juju user disable  juju disable-user
juju user enable   juju enable-user
juju user info juju show-user
juju user list juju list-users

* the behaviour of destroy-environment has changed, see the section on
controllers below
** these commands existed at the top level before but become the
recommended approach again.

And for the extra commands previously under the "jes" feature flag but
now available out of the box:

juju system create-environment juju create-environment
juju system destroyjuju destroy-controller
juju system environments   juju list-environments
juju system kill   juju kill-controller
juju system list   juju list-controllers
juju system list-blocksjuju list-all-blocks
juju system login  juju login
juju system remove-blocks  juju remove-all-blocks
juju system use-environmentjuju use-environment

Fundamentally, listing things should start with 'list-', and looking at
an individual thing should start with 'show-'. 'remove' is generally
used for things that can be easily added back, whereas 'destroy' is used
when it is not so easy to add back.


### Multi-Model Support Active by Default

The multiple model support that was previously behind the "jes"
developer feature flag is now enabled by default. Along with the
enabling there

A new concept has been introduced, that of a "controller".

A Juju Controller, also sometimes called the "controller model",