Re: Juju Leader Election and Application-Specific Leadership

[Aaron Bentley]

On 2017-04-05 09:30 PM, Andrew Wilkins wrote:
> On Wed, Apr 5, 2017 at 10:26 PM Dmitrii Shcherbakov

> This doc says
> "If the election process is done internally to the service, other code
> should be used to signal the leader to Juju.".

> Longer: if your application has its own internal leadership election,
> then you may wish to present the name of the leader to the user (or
> other applications), e.g. using application status or relation data.
> That's what I take "other code" to mean.

"to Juju" makes it sound as if you're signaling Juju itself (i.e the
controllers), rather than using Juju to signal other applications or the
user.

Aaron



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

Re: lxd and constraints

[Aaron Bentley]

ISTM that
 - constraints are used to ensure that a workload runs well.  Minimum
   constraints serve this, and maximum constraints do not.  (Maximum
   constraints may be useful to ensure that a workload does not swamp
   processes outside its container.)

 - Juju cannot enforce a minimum constraint.  LXD could potentially add
   support for this, and then Juju would be able to leverage it.

 - Given that Juju cannot enforce a minimum constraint on LXD at this
   time, it would make sense to emit a warning that it is ignoring the
   constraint.  This would retain the portability of bundles that use
   constraints while keeping the user informed.

On 2017-01-13 01:14 PM, Nate Finch wrote:
> I just feel like we're entering a minefield that our application and CLI
> aren't really built to handle.  I think we *should* handle it, but it
> needs to be well planned out, instead of just doing a tiny piece at a
> time and only figuring out later if we did the right thing.
> 
> There's a few problems I can see: 
> 
> 1.) you can have 10 lxd containers with memory limit of 2GB on a machine
> with 4GB of RAM.  Deploying 10 applications to those containers that
> each have a constraint of mem=2GB will not work as you expect.  We could
> add extra bookkeeping for this, and warn you that you appear to be
> oversubscribing the host, but that's more work.
> 
> 2.) What happens if you try to deploy a container without a memory limit
> on a host that already has a container on it?  
> 
> For example:
> 4GB host
> 2GB lxd container
> try to deploy a new service in a container on this machine.
> Do we warn?  We have no clue how much RAM the service will use.  Maybe
> it'll be fine, maybe it won't.
> 
> 3.) Our CLI doesn't really work well with constraints on containers:
> 
> juju deploy mysql --constraints mem=2G --to lxd
> 
> Does this deploy a machine with 2GB of ram and a container with a 2GB
> ram limit on it?  Or does it deploy a machine with 2GB of ram and a
> container with no limit on it?  It has to be one or the other, and
> currently we have no way of indicating which we want to do, and no way
> to do the other one without using multiple commands.
> 
> This is a more likely use case, creating a bigger machine that can hold
> multiple containers:
> juju add-machine --constraints mem=4GB
> // adds machine, let's say 5
> // create a container on machine 5 with 2GB memory limit
> juju deploy mysql --constraints mem=2GB --to lxd:5
> 
> At least in this case, the deploy command is clear, there's only one
> thing they can possibly mean.  Usually, the placement directive would
> override the constraint, but in this case, it does what you would
> want... but it is a littler weird that --to lxd:5 uses the constraint,
> but --to 5 ignores it.
> 
> Note that you can't just write a simple script to do the above, because
> the machine number is variable, so you have to parse our output and then
> use that for the next command.  It's still scriptable, obviously, but
> it's more complicated script than just two lines of bash.
> 
> Also note that using this second method, you can't deploy more than one
> unit at a time, unless you want multiple units on containers on the same
> machine (which I think would be pretty odd).
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:48 AM Rick Harding  > wrote:
> 
> In the end, you say you want an instance with 2gb of ram and if the
> cloud has an instance with that exact limit it is in fact an exact
> limit. The key things here is the clouds don't have infinite
> malleable instance types like containers (this works for kvm and for
> lxd). So I'm not sure the mis-match is as far apart as it seems.
> root disk means give me a disk this big, if you ask for 2 core as
> long as you can match an instance type with 2 cores it's exactly the
> max you get. 
> 
> It seems part of this can be more adjusting the language from
> "minimum" to something closer to "requested X" where request gives
> it more of a "I want X" without the min/max boundaries. 
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:14 AM John Meinel  > wrote:
> 
> So we could make it so that constraints are actually 'exactly'
> for LXD, which would then conform to both minimum and maximum,
> and would still be actually useful for people deploying to
> containers. We could certainly probe the host machine and say
> "you asked for 48 cores, and the host machine doesn't have it".
> 
> However, note that explicit placement also takes precedence over
> constraints anyway. If you do:
>   juju deploy mysql --constraints mem=4G
> today, and then do:
>  juju add-unit --to 2
> We don't apply the constraint limitations to that specific unit.
> Arguably we should at *least* be warning that the constraints
> for the overall application don't appear to be val

Re: Bug 1642609: new model config defaults

[Aaron Bentley]

On 2016-12-07 03:37 PM, Michael Foord wrote:
> I am strongly of the opinion that at the very least a newly created
> model should be capable of deploying workloads, which means that at
> least a subset of model-config options should be propagated by default
> to new models. This means at least, agent-stream, agent-metadata-url,
> proxy settings etc.

Options that pertain to network activity by the controller should be
retained across models, i.e. agent-metadata-url.

A controller can create models in a different cloud/region, so options
pertaining to network activity by other agents should be associated with
the cloud or region, not the controller.  e.g. proxy settings.

Aaron



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

Re: A (Very) Minimal Charm

[Aaron Bentley]

I hope that as you implement this, you avoid making fat charms.  Can you
use "resources" for this?

Aaron

On 2016-12-01 08:39 AM, Marco Ceppi wrote:
> On Thu, Dec 1, 2016 at 8:28 AM Free Ekanayaka
> mailto:free.ekanay...@canonical.com>> wrote:
> 
> On 1 December 2016 at 13:53, Marco Ceppi  > wrote:
> 
> On Thu, Dec 1, 2016 at 5:00 AM Adam Collard
> mailto:adam.coll...@canonical.com>>
> wrote:
> 
> On Thu, 1 Dec 2016 at 04:02 Nate Finch
> mailto:nate.fi...@canonical.com>>
> wrote:
> 
> On IRC, someone was lamenting the fact that the Ubuntu
> charm takes longer to deploy now, because it has been
> updated to exercise more of Juju's features.  My
> response was - just make a minimal charm, it's easy. 
> And then of course, I had to figure out how minimal you
> can get.  Here it is:
> 
> 
> This is neat, but doesn't detract from the bloat in the
> ubuntu charm.
> 
> 
> I'm happy to work though changes to the Ubuntu charm to decrease
> "bloat".
>  
> 
> IMHO the bloat in the ubuntu charm isn't from support for
> Juju features, but the switch to reactive plus conflicts in
> layer-base wanting to a) support lots of toolchains to allow
> layers above it to be slimmer and b) be a suitable base for
> "just deploy me" ubuntu.
> 
> 
> But it is to support the reactive framework, where we utilize
> newer Juju features, like status and application-version to make
> the charm rich despite it's minimal goal set.
> 
> 
> Yeah, and I think this is a good thing.
>  
> 
> Honestly, a handful of cached wheelhouses and some apt packages
> don't strike me as bloat
> 
> 
> No it's not per-se. However I think this highlights a more general
> issue with the current implementation of the reactive stack. It's
> not only the ubuntu charm that has slowed done, it's any
> reactive-based charm, because the steps required to "setup" reactive
> take longer than they used to.
> 
> 
> The problem we're hitting with wheelhouses is exactly the one that snaps
> aim to solve:
> 
> - apt packages are not cross distro, and we have reactive centos charms
> - apt packages lag a bit meaning we can't get consistent features even
> between trusty and xenial, let alone xenial and tip
> 
> I see a couple of (possibly alternative) ways to improve the situation:
> 
> 1) Make sure the dependencies of the base reactive layer are
> packaged, that should be much faster than pip install, and fall back
> to pip only for what's not there (i.e. dependencies added by the
> consumers of the base layer). Also, package the base layer itself.
> 
> 
> I'm very keen on a development in the snap world, where an unconfined
> "classic" style package would be available. This means we could snap up
> all the dependencies of the basic layer for every architecture and skip
> the setup phase for reactive. I think this is probably our best bet
> going forward.
>  
> 
> 2) Add support for images, so when you deploy some vanilla charm
> there's an associated "pre-built" image that will be very fast. I
> guess this is in the juju road map anyways.
> 
> 
> Sure, a build step is an interesting one, but it still incurs the same
> wait for a setup, you just don't feel it as much.
>  
> 
> We always need to keep in mind that this experience will be compared
> with things like Kubernetes and Docker, and speed-y deployments
> really unlock velocity when iterating on charm development (think
> for instance running integration tests).
> 
> 
> Speed is just one facet of the experience, though an important one. For
> the speed of Kubernetes we win, hands down: 10 mins to deploy a full k8s
> cluster (with Juju) is only really outpaced by SAAS. I know that's not
> the point you were making, but it's the true speed comparison of what
> we're doing.
> 
> That being said, we're very keen on making charm development, and
> deployment, faster. Reactive 1.0 was a first leap in that direction, as
> we round off work in 2.0 and leveraging other technologies like
> unconfined snaps, we can start to speed up the bootstrap process of
> reactive charms.
> 
> I'll file bugs to track these items
> 
> Marco
> 
> 



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

AWS US East (Ohio) Region now supported for Juju 2.x

[Aaron Bentley]

The Juju QA & Release team is pleased to announce support for Amazon's
new US East (Ohio) Region, aka us-east-2.

To use it with 2.0.0, just run "juju update-clouds" once.  You will see
the message:
Updated your list of public clouds with 1 cloud region added:

added cloud region:
- aws/us-east-2

After that, the new region will work the same as any other.

Support for the 1.x series is also planned, but will happen as part of a
Juju release.

Enjoy!

Aaron



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

Re: Latest new about Juju master branch - upload-tools obsoleted

[Aaron Bentley]

On 2016-08-15 08:27 AM, Ian Booth wrote:
> Please let me know if there's any questions. --upload-tools is still supported
> but will be removed soon.

Has --upload-tools already been removed?  The lack of it appears to be
breaking gui tests:

http://reports.vapour.ws/releases/4259/job/function-uitest-gui/attempt/419#highlight

Aaron



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

Re: Juju CLI change (status output)

[Aaron Bentley]

Thanks for the warning.  CI uses only YAML and JSON output, so it won't
be affected.

Aaron

On 2016-07-26 11:01 AM, John Meinel wrote:
> One tweak that is landing for the next 2.0 beta (14?) is to change 'juju
> status' output to put PORTS after PUBLIC-ADDRESS. This is just alignment
> with the fact that usually when you see it, it is 10.3.2.1:8080
>  not 8080 10.3.2.1
> 
> The particular PR is here:
> https://github.com/juju/juju/pull/5870
> 
> It is a small tweak, but if people have been scraping the tabular
> output, it will be changing. (no change to juju status --format=yaml).
> 
> John
> =:->
> 
> 
> 



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

Re: Windows and --race tests are now gating

[Aaron Bentley]

On 2016-07-11 11:57 AM, Mark Shuttleworth wrote:
> On 11/07/16 09:26, Aaron Bentley wrote:
>> But is this week really any different from any other week? Won't there
>> always be something critical that has to land? 
> 
> I think it's fine to make it a plan that we will have Windows tests on
> for 2.0 GA, but at the moment we're focused on all the breaking changes
> to the APIs and those are not Windows-relevant.
> 
>>> With the race tests, we got all of
>>> those passing before turning on gating. We need to do the same for the 
>>> Windows
>>> tests. We need to deactivate gating on Windows at this stage.
>> But there are some tests that do pass under windows.  By disabling all
>> tests, we risk further regressions on Windows.  Instead, you could
>> disable the tests that don't pass (only when running under Windows, of
>> course), and then work to fix them.
> 
> Please do that now - leave the passing Windows tests in place and ask
> the Windows teams to enable further tests which we then add to the gate.

I have talked with Alexis and I'll work with her and the core team to
get that done.

Aaron



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

Re: Windows and --race tests are now gating

[Aaron Bentley]

On 2016-07-10 08:34 PM, Ian Booth wrote:
> Turning on gating for Windows tests before all tests were passing is premature
> and is now blocking us from landing critical fixes for beta12 that we need to
> release this week for inclusion into xenial.

Hey, this is why I pointed out that it would block all landings.  And
believe me, I double-checked that this was really what Torsten wanted.

But is this week really any different from any other week?  Won't there
always be something critical that has to land?

> With the race tests, we got all of
> those passing before turning on gating. We need to do the same for the Windows
> tests. We need to deactivate gating on Windows at this stage.

But there are some tests that do pass under windows.  By disabling all
tests, we risk further regressions on Windows.  Instead, you could
disable the tests that don't pass (only when running under Windows, of
course), and then work to fix them.

That way, we have a passing test suite and a way to work incrementally
on fixing the Windows testing instead of requiring a flag-day
coordinated change.

Aaron



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

Windows and --race tests are now gating

[Aaron Bentley]

Hi Juju developers,

As requested by juju-core, we have added --race and Windows unit tests
to gated landings.  These tests are run concurrently, not sequentially,
but all must complete before code can be landed.

As a practical matter, this means that landings are now impossible until
the Windows and --race tests can pass.

The output from this initial version is a bit crude-- it will tell you
which tasks failed (e.g. "windows"), and you then need to look at the
corresponding logs under the Jenkins artifacts.  We aim to improve this
soon.

Aaron



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

Re: Juju 2.0-beta9 ETA

[Aaron Bentley]

On 2016-06-13 09:35 AM, Ian Booth wrote:
> $ juju set-model-config foo=bar
> 
> That sets foo on the current model.  Or
> 
> $ juju -m mymodel set-model-config foo=bar
> 
> operates on model mymodel.
> 
> The above are model commands. So we need a way to set foo=bar on the 
> controller
> itself (ie update the shared controller wide config). What are you proposing?
> Did you intend that setting foo on the controller model would satisfy the
> requirement?

Maybe a flag on set-model-config would be the way to go.  It would
conflict with -m.

e.g.

$ juju set-model-config --controller-default foo=bar.

(The name could probably be improved.)

Aaron



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

Re: LXD polish for xenial

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-20 04:20 AM, roger peppe wrote:
> The fact that the command to manipulate lxd containers was named
> "lxc" added to my confusion.

I think it's a poor choice to use a command named "lxc" to manipulate
lxd containers if they're different from lxc containers.  e.g.
lxc-list won't show 'em.

Which is one way that silently translating lxc -> lxd could poke users
in the eye; they may run lxc-manipulating commands later and be
confused.  A warning would probably make sense.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXF4ozAAoJEK84cMOcf+9hLRQIALAL46e5Wb9TPHDyj6upMQlY
mQ6c7z8mk/2mLBPP787DvDH1s6eAkxTfhs8PXrANMZwZ0trHno7USlxe13L+in3X
oPFmlP5fEEVMA5EqFGw+nenjDeu/AC35lqXBpKz5OpZFNoZIGpukTwbtmFvWZlJj
mWT1ahilrcl6jzxnkviPzTGhN3tC3d2pbvxVAMw+z+faWIuK5GhiXPo6mLFs+Unh
U79XgZOAKDCBRzxTgmnI+/1WjxQ2dqR/qlcB+sHmipj8CS0ujerEwXQz1bhEEQhS
nXhdMAcgyH8OoXDaxif74MNGxjb+B1RyPHU1/KSQWuxgDhmwHvr+CsVHxIXS4Ds=
=ynuy
-END PGP SIGNATURE-

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

Re: hacking upload tools for development

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-19 05:19 AM, Michael Foord wrote:
> 
> 
> On 14/04/16 19:38, Aaron Bentley wrote: Hi there.
> 
> I've done a lot of work with simplestreams lately, and we've got
> some decent tools for generating them quickly and easily.  I'd be
> happy to work with someone from core to develop a tool to generate
> streams that you can use in place of --upload-tools.
> 
>> That sounds ideal.

Great.  I do need to partner with someone on core for this, to make
sure the resulting tool is something that devs will want to use.  Are
you up for that?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXFkr6AAoJEK84cMOcf+9hYFgH/0DVVDmDkYLDFcwOyAR9Rykg
PGC+RvRVbitn9vx7vCDGYKl1syqsnRr50xEe43RWN5Ix6NrmgekKciB7VZocEzg4
IxzLkv0X8MU2HVkYVwR1O/f12vCExHTxriP/UdeuubHaEWNr2k0K3Lxpl5zT1oqB
8ZZo+nhGUqGYRYHACvIbatlbI2MJ7rvmMeKycNTk9AzeFxZFC4keW6Pweee+Ptas
Yg131FnNbKf5ReI8lDrvPyWGxTVHPRH+HXLgb9Op7abQX1yBb4M4fOc9n/O3vY49
EJxTFMRE+dXZ/5MHxbaczaTo+MjDY6JrROxylfsRXxDXc6z8xvC9aZ6Bmk0gRi4=
=qZlB
-END PGP SIGNATURE-

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

public-clouds.syaml is now active

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

I've put public-clouds.syaml up at streams.canonical.com, so "juju
update-clouds" now works.

http://streams.canonical.com/juju/public-clouds.syaml

Please coordinate with QA if you need to change the values there.

Thanks,

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXEO/1AAoJEK84cMOcf+9hVNEIALt6bpSRp44B8047X1yb7fHc
mwkbc1M/5qMZ5e/3Lt0SmhUiTRgDyOM0se4hp51dbK0kTI2MSMqPga5Ft8xkKVqr
M3cTGbbPFypaMJli0oAj0mFHjA8HTJ1D/Hn2pX5flFS4OwHCiSVRDmHSkTYcZ4Wg
rsMkiqPHiFLwNKtVv56yISgu7x7VwQ2CWuccETp+lTcQioyAEfFrK0YSNpjkw0N1
ogEe/dLwN5VhSI77tfO/JCcr1DV1M6Jj1tWLtrvdsYUxtaBtW7pTC/2ONQ/lvr7c
Kowi1ReWXO4EuSqiZA8Z21QQJzB0gsOlVKgtDegMLW+lPOwHCYB+JMJW4LAG8Gw=
=7P7H
-END PGP SIGNATURE-

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

Re: hacking upload tools for development

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi there.

I've done a lot of work with simplestreams lately, and we've got some
decent tools for generating them quickly and easily.  I'd be happy to
work with someone from core to develop a tool to generate streams that
you can use in place of --upload-tools.

Aaron

On 2016-04-14 09:52 AM, Nate Finch wrote:
> I wrote a wiki page about how to hack bootstrap --upload-tools so
> that it doesn't stop the controller from going through the normal
> processes of requesting tools from streams etc.  This can be handy
> when that's the part of the code you want to debug, but you need to
> upload a custom binary with extra debugging information and/or
> changes to that code.  It turns out that the changes are very
> minimal, they're just hard to find and spread out in a few
> different files.
> 
> Feel free to make corrections if there's anything I've missed or
> could do better:
> https://github.com/juju/juju/wiki/Hacking-upload-tools
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXD+ONAAoJEK84cMOcf+9hT/4IALfSUh8Z5r8FqzAROYq5FnMq
8UG3Do6FkN/zFDZBelM1NJpePOWqkyvcJbZSLHGsnbcDRMpADXju0LDALKKcx87p
AVzsiMea/7RcZi9ln2Pdb+Ct508eBK4IN7f8L20iA1x3i83gvZ9s1JzJ/Gxb9+KP
5ovkQ7MNnekjQz5ejCBFjRgOq31dIhTCV26QzaUqQxJnEmA5N2SpOfEgfsqcTGxX
PWQYLcm255er/QBp4Pr76bOAeVdqR0yGNx6N3fiezH39noNPQMl7L5bbWABk8DHc
by3FjrDdFYSQmEUPwJVmfK3lBD6JjdJH7y7fu4qE5A+Zp2mV2cN/mr3Fuw0m57I=
=PKZ7
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-07 12:40 AM, John Meinel wrote:
> 2. We move CI towards making kill-controller fail the test suite.
> If destroy doesn't do everything they want, then we have a bug and
> it should be telling developers that.

e.g. exit status 0 = "I successfully destroyed without resorting to
the provider", status 1 = "I had to resort to the provider to
destroy", status 2+ = "I did not destroy"?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBmk4AAoJEK84cMOcf+9hjwgH/RqcX5OqVKx7SoxCbjnbj7sk
O5UKWCbn00F2LsGxfuwM3jL94dXFO0q854BHWSBsjOJUD3i4CdKAlI9MYBkCYOk6
CEYnG8U+12LG+g56tAVEGLhYJ/wlA7hJVr/64xlQw1AiNliqKpNWaLftTMGUs6DC
gUQ06EEqkrFQwyh6A0DB0c5FbpX9sA5W+TpGsJJz+TTsJVxBycaLJQF06ZbyxREX
LEar/v8sr+4uZia+OrJofynGUVxt5Ub6p4+XNBnMF4oWkg2kYjmTNnGduUFv9mKk
bLuIYrOJzz6l8ZiTn6VrPI7Ztad+6+CIPcITaw+s3wMZ8pCT0zRNNk6OxZREXcs=
=hyhy
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 01:41 PM, Nate Finch wrote:
> I'd much prefer giant warning text:
> 
> DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE
> RESOURCES RUNNING IN YOUR CLOUD!  ALWAYS TRY destroy-controller
> FIRST!

I don't see why this warning is needed.  kill-controller always tries
destroy-controller first anyhow.  If kill-controller does leave
resources lying around, that was the best case anyhow.

> In fact, if I were feeling sneaky, I might accept -y and still make
> them confirm, since they're obviously just banging out the command
> without thinking.

That would break this command such that QA could not use it.  We would
be very vexed.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBWKaAAoJEK84cMOcf+9h6xMH/27hpIV0NqaGxOttJWPZBlGK
qNybd9JGSMQy3cmaHyPTNqZFcq3Qw+nCPrT3SNVCpl+AnnspGA2uysZ61jejds4Y
QG0246mluC7O3TMOEBlPSqU5ezJST0X3f+hrpTEj6f0yym6LAZ96daozsqbvbLAP
33lqBJS2kT/5JvC3A1iPM/YyZbBDpJPgrlSoNfDvTVFdj4/3R0UkLADIHrG0ZcGR
umW+BsIWsuPyTOM+hCO8mNr2gS6i4+KwIcus7Np7rPdDdExsHrcthPilHmvg4KQn
/9tMJTViRnLmjXSdHRFLSnmF4eAau5VuApaLara1hfPWYRpBF4IhlPJEXb3vi+o=
=tmNe
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 11:02 AM, Cheryl Jennings wrote:
> Another relevant bug:
> https://bugs.launchpad.net/juju-core/+bug/1566426
> 
> Maybe kill-controller tries to destroy through the API, but has a
> time out if things get "stuck" where it will fall back to the
> provider.

Interesting.  It does have a timeout for connecting to the API, and
it's a pretty short one.  But I guess we also want a timeout for the
destroy-controller API to succeed.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBSZpAAoJEK84cMOcf+9hRaoIAKUe5omkkhWeR1LcXvHGhXS1
Gi2gzo6Qz6cviJjcUv4ulNT+ZIHtwvdQDDLSIksMda8+i+FRZrX7c6owo+VDFxf3
4LjigyKsWWSLBHNxKIG6SaK8QZWeVrkjhuRDTJhu4gUHUepMh++grarj/Z92jn8J
tmHF8bHMyt6Pz9/pUjHzxLtmGy+K1GA088q+ec82qk7isZK+bEtsmkEqWSIbzKwo
tYeBrRHMS7zJe91AUX5ES4jp6ua28u7Ot3NfV2JrEYYD3D090aKtsI3IEDB65DgH
aJPD1CRzYhuLPmIQsiAlvPim6oiIQ7kTWKGRA5DxRxwG7sc+f6kVVsOFqXHoO2U=
=gqOt
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 10:45 AM, Nate Finch wrote:
> Wait, didn't destroy-environment --force fall back to the provider?
> I thought that was the whole point of --force

No, it didn't fall back.  It uses the provider unconditionally,
without trying a normal destroy-controller first.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
=vm/H
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 08:22 AM, Andrew Wilkins wrote:
> What I would like to see is: * destroy-controller to take on a
> --force flag, causing it to do what kill-controller does now, and
> what destroy-environment --force used to do

What kill-controller does now, where it attempts to use Juju, but
falls back to the provider, is much more valuable to us in QA than
what destroy-environment --force used to do.  We don't want to leak
resources unnecessarily, but we do want things to die when we try to
kill them.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBRv5AAoJEK84cMOcf+9ho54H/iPRI5RpxT4kPoD3oJ3OXGAM
AjUrOcvghiik3K021yOzN4LIQm9dLdKv0rKZ0zYBW7EUaE2OUBt5HLSzINLMRXU/
T2qqTgDgu0iYWit06dp4jRyYiErGoENHCUciISXVMyGtk5xJPy+4kdcHZheq8jHW
WCtN07JNuMk6OUjQB4mDwKo1E0pEU36tKhPChFEceYT6O3OdCB66H+ZV+t1RlasR
2ktNeKg9bDjTu5/JwzOe4+eIFK8tvdgCRG1dmRXpQ6ewXN2IjFunkRVYkqc3RZcH
zphCjyuofv0CueuSSp1wbdQOxi6M05XyXb6czrdkkkgajqdTxXt2VI3JCMjrIgg=
=O5Bo
-END PGP SIGNATURE-

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

Re: Go 1.6 is now in trusty-proposed

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-03-28 09:03 AM, Katherine Cox-Buday wrote:
> Generally +1 on this, but I'm also intrigued by Martin's
> statistic... do we currently weight test failures by how likely
> they are to fail (i.e. how likely they are flaky)? That seems like
> it would be a great metric to use to decide which to fix first.

We don't do it on the likelihood of failure, but we do it on the
frequency of failure.

http://reports.vapour.ws/releases/top-issues

I report on these on the cross-team call, and once the 2.0 settles
down, I'll be reporting them on the release call again.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW+VJcAAoJEK84cMOcf+9hWrwH/0JradfscIE0wnt+yCW9nNCR
9hTHI2U19v1VuP6pWI4UiC7srfojPI8EXXEXrrAhF9rT8tpVK4EcJRJK9RvWvvz5
BEquHMS0+eROFOqDJFavEB8hU7BKHErzkSwSG8uKq7JuwHs9gNtQO9z9fIhVKjnr
aP4z2IliCqbYfXbupfSTD8TmqhI0AipQymTg3QB4C3sJdXzc5GjzIIckUo/X7aJj
zH1tEtlwOdP0c9F+8ZVs1j6AAkb+uDGc/1Qr4MT1kInqGkli2UNF4TOX/AihNPyH
iwYgq6O7uOkijFTrL9obRfbXxIFw1WCc9cYzxbRYnGfQff47Dyj7/BUStPPH0i0=
=8FQ6
-END PGP SIGNATURE-

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

Re: Introducing, juju resources!

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-02-14 01:40 PM, Rick Harding wrote:
> 
> 
> On Sun, Feb 14, 2016 at 12:50 PM Aaron Bentley Yes, you can work
> around this with tarfiles, but why do we want to? It's a pain to
> build a tar file every time a single dependency changes.  It's
> easier to use S3 instead for a particular use case, but it doesn't
> solve the general case.
> 
> 
> I'd push back a little bit here though. We do this in a couple of
> python web applications. We keep a repo of 'download-cache' which
> is the current pypi .tar.gz and use that built into a single
> download-cache tarball for deliver in the charms. This would be one
> resource. The second resource would then be the actual python
> application. It would have the makefile, requirements.txt file,
> source code, etc. It would depend on the download-cache file being
> there and so with the two, you'd manage both the source code and
> the dependencies as two different resource files that are all
> updated individually from the actual charm itself.

I would call that "working around this with tarfiles".  I still think
that it's more convenient to use S3 than to have to update the
dependencies tarfile every time a resource changes, and I think that
being less convenient that alternatives will hinder uptake.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWwMw9AAoJEK84cMOcf+9hX3EH+gKybA2e5bWJBvCOURgv6Ep2
esVvugT7h5bW84zJUX7He+OZLM+PQV9RcWo10A+SjN3U+AVS+zgIHIlXXTDmLb4N
orP8nHsgTptYuv52kNmrycASY+QDUTBrr1KhxtUjPobMO2DW4dwrbXRzWKD0U2rY
1oHH5KE6CjnRRFJGnXik6OOoP9Xskty3sOguBw9KVISjLlh4k0kl3EKRS00ED7KY
PgBC/EKjD1+mLFt+TA9m+Ds6y/dSco0yWVNgbjBZ18ftxY6g4J4LCd1Sj5zXW03q
Ic/iNWj3gI89dV1TGVx7VNqSex7lKS1AYODjeZC3saPcJ3oIRV97WxA7D66wRQw=
=p32x
-END PGP SIGNATURE-

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

Re: Introducing, juju resources!

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-02-13 09:10 AM, Rick Harding wrote:
> Your read is correct. You must declare the resources. It's helpful
> to users to know what to stick in there and for the charm to be
> able to handle different items. In your case, a single tar file of
> the plugins you'd like to enable could be sent up and the charm
> would be able to untar, loop through them, etc. Ideally the charm
> would be uploaded to the store with a standard set of plugins and
> folks could then customize which ones they wanted by creating their
> own tar of plugins.

Another use case is when you want to create a charm deploys Python
code.  You want it to use "resources" instead of downloading
dependencies from PyPI.

1. The list of resources can change over time.  You don't want the
charm to have to change every time the deployed software adds/removes
a dependency.

2. The version numbers are embedded in the filenames.  You don't want
the charm to have to change ever time deployed software changes its
version numbers.

Yes, you can work around this with tarfiles, but why do we want to?
It's a pain to build a tar file every time a single dependency
changes.  It's easier to use S3 instead for a particular use case, but
it doesn't solve the general case.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWwL5XAAoJEK84cMOcf+9hVLQIAI5q7epn8UKtAILu9E41PoPK
CzVE+8gkWHEOZ9fOpfC8rXGVl1MmF279vx7o5eEYaXq8LNIL4yQx4rg4BahnkIhn
oO5LwPLXTp6c+XJ6muofqQZtvm80HJO3AcsuYbdrQoBDrQrNqjPr4yMXZi0BJ1c1
iGmqNTgl4IWfYJtxMGmzV7qBLrjepG17lClHSNFpMz4rpftZje7H0utPsoFvFRcU
ya0LiGiKjTgkBfPWuopgO6cBZ8Y0FVPV94tyLc67PNrjSYDYKeSrfMCAMdHZ4Gh9
kMM4pnEjX0lT01d8A8PcecbmUDRJ1NLHnzDW1VeJxDXVrzA/vIMF+QWc0EUJKCo=
=BEaN
-END PGP SIGNATURE-

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

Re: Introducing, juju resources!

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-02-12 04:26 PM, Katherine Cox-Buday wrote:
> Moonstone have been working hard on a new feature coming up in Juju
> 2.0 called "Juju Resources", and we're now at a point where we can
> share the goodness and call for bugs/feedback!

I'm glad to see you folks are working on this. On the QA side, we've
been wanting Juju to support some kind of native blob storage,
basically since we started.

Is is necessary to enumerate the names in the charm? I'd rather we
didn't. One of our use cases is plugins for Jenkins. The Jenkins charm
has has a setting that tells it which plugins to install, but there's
no predetermined list. It would be nice if the plugins could be
retrieved in a Juju-native way, but it would be painful to have to
update the charm every time we added a new plugin.  And it would be
bad if people ended up forking the charm just to adjust the list of
plugins.

We could bundle the plugins in a single tarfile, but then updating the
tarfile would be annoying. For plugins, it's best if each plugin is
its own file and there are no restrictions on the filenames.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWvquhAAoJEK84cMOcf+9h/k8IAMtadIceMAUOibSXSuw96WqM
n3jv6Vd6/UzorzieA66yCrquW+gkscnnDuLedEoRCFLn5lJZT2cWpPcnI/tdonB6
l3bF5ViIrrebvf+wWvc7r3Ep3Y/3NBKYtznwbjfHJuJoZcDWTKR/6lgflD5GAomX
gZyZhP6U/+dE0TfhFBoG3hsqkRludBSI7fzIlw8X32mBclvJlTtvWikuhnwbvhI/
ao+9VCR7iFumUX7wfDksNrRKLrA9rxitlKRhTxVUsgEbtGImwu6B/G8eOZ58kFIy
C9QuO5MwW3BCwgJ9NyiQTCXUcOtbSyRHSfnb/BwbbI3A9i5DABDwIcCrIKc9Zmo=
=R0j6
-END PGP SIGNATURE-

-- 
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

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 2016-01-20 10:30 AM, Gabriel Samfira wrote:
> The auto-retry thing was created to overcome situations in which
> the machine is rebooted, or chashes during a hook run
> (independently of juju). In this case, the charm would not be able
> to recover automatically from a transient situation.

If the intent was to handle reboots, couldn't it be written to restart
any pending hooks after a reboot, rather than when the hooks fail?

Even re-running just at agent-startup would be a lot clearer.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWn6pLAAoJEK84cMOcf+9h3mIIAMbumuMlehhMELNAlxMN2bnn
1rYUIZ7P/n2CagdMnjzysZXeUkRSHOjdklE4XKJUzhxzaknRgJXNZ8Ab5R7XMU1F
f4GnOXhskmw4mAae9beve5I4vF2WINxUQcxRaRen6Ov6VRQqRxVnMnZ6S85o4tPY
lMQRh+WP40JTzDkUWcCyKpQ5JgBqP9IQwn21y9v/LiXAfbkzrzqR04hvk7HrMM5W
lRBnTUldj3GHiI8Gjq6TVx6Th76PalfPUHoBlF7cmqEEVXydmuOjzr1C3fZR8VO5
JeXif92z5sR6z4TjoxnT7ixyfoz1Rvu6pKhIPJbi1cptXjDv5wU43MJsNqT6KpQ=
=Igdi
-END PGP SIGNATURE-

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

Re: Upgrading minimum Go version?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-30 10:36 AM, John Meinel wrote:
> Given how often people still use "--upload-tools" for things like 
> private clouds (and is definitely the one used for local provider),
> I'd really worry about having a jujud on your local machine that
> wasn't built with the same toolchain as the one you get from "juju
> bootstrap" in other cases. Very easy to end up with hard to
> understand/reproduce bugs.

But you understand that we've been doing that for ages, right?  The
- --upload-tools jujud is always compiled with the toolchain from the
local machine's series, and non-upload-tools one is always compiled
with the toolchain from target machine's series.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWXG6dAAoJEK84cMOcf+9hfiQIAIv4jOSITt/vFXxlb1sY1MiQ
5OTtpdFOzPmY4X2grUPLEW8PYXMDqT53V0dWuHQic6OcDcnvSc5W06sMqLbfDz7V
dIxCfY5Lt6MpjI9UfS3ec9BVuSC3QT9klVf5ELrQ1HzKzkZK6NE3XzA1rlDJ/+0v
Z3rKymKt8M1kNbZiG3WNODpamyqp6Gt9ie28SOFcBIyaiM+vHhPIog7vjjshtUTh
UwSSWqfBPMUIFLJttH1Nl+XnGPeJD/p5fTSt/2CCs4VUT9q2fEIR1Ur3IcC6JPAK
Vw1Dcuuso9fLZkkFCCRBLMwRCQn8mghtsXQ8qpdFUiF87sWYDDdVI8A101YHc30=
=XP/V
-END PGP SIGNATURE-

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

Re: Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-27 11:10 AM, Marco Ceppi wrote:
> Okay, but I've added the LXD daily/stable PPA which installed `go 
> version go1.5.1 linux/amd64`. My question is, are the LXD features 
> locked to an Ubuntu release or is it dependent on checking
> platform ability at run time?

It's dependent on what compiler was used to create the jujud binary.
AIUI, the Ubuntu policy is that nothing goes into a distroseries which
cannot be compiled with the tools in that distroseries.  Thus the
jujud for Trusty is compiled with the version of Go provided by that
platform.

> My point being, I have a trusty machine which has a more recent
> version of golang and the latest stable LXD software installed. If
> Juju won't work simply because it's trusty then I need to file a
> bug before 1.26.0 lands.

I recommend contributing to the "Upgrading minimum Go version" thread.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWIMlAAoJEK84cMOcf+9h/GEH/0ftpREnqycLI0MM2bw7VjmM
LZw2dNfiyhnKQNYWlupjMOEYDJoTRwVrvI7fd0mpMTbM83060Jk66caMMsUF64Da
9pMBU9B5G8jIcrHc4JApSStfJOcHPX7rtnYcuCVET0XOEXSimLdpg+06jzU+3zYB
ByM5mCjWNGX33RUzbI96mJypyLy1nqPuJS0d7MXFSGu1U3LTniiCBZIlRJtXtnNt
9QRf86J7ERLLoH2fbL2DBPk5yN9s5X44/izDySBsxDYzzhqNpg6QPReQthRU1Ovh
QyJSFx4lVlaQMhGgrOEz4X+3LzU6A0MFIybivZ60LDWnJ1wvOKrKBC12lxjzIsg=
=xMRG
-END PGP SIGNATURE-

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

Re: Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> - Running Wily (LXD is installed by default)
> 
> 
> For the LXD provider, I have the latest LXD installed on trusty,
> will that work or is it hard-coded to wily+ ?

It will not work.  Only platforms with Go 1.3 will work, because the
LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
version" in juju-dev for more discussion.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
=dYa5
-END PGP SIGNATURE-

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

Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

# juju-core 1.26-alpha2

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


## Getting Juju

juju-core 1.26-alpha2 is available for Wily and backported to earlier
series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.26-alpha2

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 stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.26-alpha2.


## Notable Changes

* Native support for charm bundles
* Unit agent improvements
* API login with macaroons
* LXD Provider
* Microsoft Azure Resource Manager provider

### Native support for charm bundles

The Juju 'deploy' command can now deploy a bundle. The Juju Quickstart
or Deployer plugins are not needed to deploy a bundle of charms. You can
deploy the mediawiki-single bundle like so:

juju deploy cs:bundle/mediawiki-single

Local bundles can be deployed by passing the path to the bundle. For
example:

juju deploy ./openstack/bundle.yaml

Local bundles can also be deployed from a local repository. Bundles
reside in the "bundle" subdirectory. For example, your local juju
repository might look like this:

juju-repo/
 |
 - trusty/
 - bundle/
   |
   - openstack/
 |
 - bundle.yaml

and you can deploy the bundle like so:

export JUJU_REPOSITORY="$HOME/juju-repo"
juju deploy local:bundle/openstack

Bundles, when deployed from the command line like this, now support
storage constraints. To specify how to allocate storage for a service, you
can add a "storage" key underneath a service, and under "storage" add a
key for each store you want to allocate, along with the constraints. e.g.
say you're deploying ceph-osd, and you want each unit to have a 50GiB
disk:

ceph-osd:
...
storage:
osd-devices: 50G

Because a bundle should work across cloud providers, the constraints in
the bundle should not specify a pool/storage provider, and just use the
default for the cloud. To customize how storage is allocated, you can use
the "--storage" flag with a new bundle-specific format: --storage
service:store=constraints. e.g. say you you're deploying OpenStack, and
you want each unit of ceph-osd to have 3x50GiB disks:

juju deploy ./openstack/bundle.yaml --storage
ceph-osd:osd-devices=3,50G


### Unit agent improvements

We've made improvements to worker lifecycle management in the unit agent
in this release. The resource dependencies (API connections, locks,
etc.) shared among concurrent workers that comprise the agent are now
well-defined, modeled and coordinated by an engine, in a design inspired
by Erlang supervisor trees.

This improves the long-term testability of the unit agent, and should
improve the agent's resilience to failure. This work also allows hook
contexts to execute concurrently, which supports features in development
targeting 2.0.


### API login with macaroons

Added an alternative API login method based on macaroons in support of a
new charm publishing workflow targeting 16.04.


### LXD Provider

The new LXD provider is the best way to use Juju locally.

The state-server is no longer your host machine; it is now a LXC
container. This keeps your host machine clean and allows you to utilize
your local environment more like a traditional Juju environment. Because
of this, you can test things like Juju high-availability without needing
to utilize a cloud provider.

The previous local provider remains functional for backwards
compatibility.

 Requirements

- Running Wily (LXD is installed by default)

- Import the LXD cloud-images that you intend to deploy and register
  an alias:

  lxd-images import ubuntu trusty --alias ubuntu-trusty
  lxd-images import ubuntu wily --alias ubuntu-wily

  or register an alias for your existing cloud-images

  lxc image alias create ubuntu-trusty 
  lxc image alias create ubuntu-wily 

- For alpha2, you must specify the "--upload-tools" flag when
  bootstrapping the environment that will use trusty cloud-images.
  This is because most of Juju's charms are for Trusty, and the
  agent-tools for Trusty don't yet have LXD support compiled in.

juju bootstrap --upload-tools

"--upload-tools" is not required for deploying a wily state-server and
wily services.


 Specifying a LXD Environment

In you environments.yaml, you'll now find a block for LXD providers:

lxd:
type: lxd
# namespace identifies the namespace to associate with containers
# created by the provider.  It is prepended to the container names.
# By default the environment's name i

Re: Upgrading minimum Go version?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-26 04:31 PM, David Cheney wrote:
> Martin: Can you setup a unit test job that uses Go 1.5 ? I will
> apply the same process I did for the -race job, to get the build
> voting, then reenable the tests that were skipped.

We already have one for go 1.5: run-unit-tests-wily-amd64

You can find the most recent results here:
http://juju-ci.vapour.ws/job/run-unit-tests-wily-amd64/

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWV3x0AAoJEK84cMOcf+9hXX8H/1w8hkU8EP4atsvefT3jn81Z
LqVWcDmGnZf4o8m6bFKC6HsI+aER9Fq56rrYBekfLJjj7Gr/ciKvd4PVFOuD0ZlO
/oiBk9mVAlvm8Gz+AcRiPbL7feaRfYSXeXAyZCkKdEZYC6wmrXt0CB5TKoOXYyXJ
nG+XJmqot/2c8oZZaGEgYvyV9+OyW4G5iv6bRE7CFl12zML0Igg4STPZHuu+J1Jw
BBLQXXL1SlZ7lZTJRekP+GXSetBry2BjbLli8B7HO4ENi8Mwx3GeBBqA69lEtXFM
p2eUFkTEn7BXYB+o8gRytuc0Ed8xnNevzKQ3EumNVCbeigkB1eWiHipIqPQFJes=
=XgV7
-END PGP SIGNATURE-

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

Re: use --upload-tools when bootstrapping the LXD provider

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That may be true, but the LXD provider branch has a stale version
number.  Once the version number is updated to 1.26-alpha2, I imagine
the lxd provider will no longer try to use the released streams.

The stale version number is also causing builds to fail:
http://reports.vapour.ws/releases/3272
http://reports.vapour.ws/releases/3277


On 2015-11-06 10:18 AM, Eric Snow wrote:
> If you are using the LXD provider, built from the lxd-provider
> feature branch, then make sure you use the --upload-tools option
> when bootstrapping.
> 
> Since the 1.26-alpha1 stream has been released, Juju will download 
> that instead of the juju you built from the lxd-provider feature 
> branch.  That means that the machine agent on new instances (e.g.
> the new controller) will not know about the LXD provider.  Note
> that this is the same as any other provider.  Just a heads up. :)
> 
> -eric
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWPMogAAoJEK84cMOcf+9h96AIAL7K/ZORFnApxE501biVAyG4
NYZvl0E8JR+pXU8e0Zl/WUSuxwyxfFRczgrg1+WFSVUDcZmuMSIQdtG9O+zvc4lH
QIe5aBKbRTdYy3s3HQo4wXTYZ5osaGQhdp2tSdEnEJpoWSKFMvLHoX+SJaxV0BfY
OfspXLiHR4g9iQb7A+6bvnl1hoq5051iMgLreAq0AVMT1NfDioZNDjTMY19HvMm2
GNcOdhW3lrliUUZvpdVx1FCqBO5e5FR1BfozzoAchCjv16o/EdVyrIxfcF3D9HVQ
VbTf2DJmKp/n6Ed/cL8swQ8wXRWwrBeHkk3LpxnFh/ZLD6eDCYr1+TIpMGLI5mE=
=mQEb
-END PGP SIGNATURE-

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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thank you!

Aaron

On 2015-10-26 09:22 PM, Tim Penhey wrote:
> On 24/10/15 04:05, Aaron Bentley wrote:
>> bzr has a similar feature, but the problem with such a feature is
>> that it can break scripts that expect the normal behaviour.
>> That's why bzr provides a --no-aliases option, which all scripts
>> calling bzr should use.
>> 
>> The same applies to Juju.  If "status" gets defaulted to "status 
>> --format=tabular", most of our test scripts will break.  This
>> isn't likely to happen on our test machines, but could easily
>> happen when devs run our test scripts.
>> 
>> Could you please provide a similar --no-aliases option for juju,
>> so that we can ensure people don't break our scripts by
>> specifying surprising defaults?
> 
> http://reviews.vapour.ws/r/2999/
> 
> done
> 
> Tim
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWL9XGAAoJEK84cMOcf+9hLTgH/A7/kn27kdD6X7u2YxzX8cuW
27DjAktjFT6Jg2yi21KFl34FsOrTJc88AJXykPyX5lk69x9v/1mSV3ObO2U45Mxj
UiqS19xhUzZGJH01slZusyM9CFWEoYvtAOxlSXSgn33TrimwY6Yd3tPIS5WUw65t
bsl5ay1I4TvHB9dsbfHRKFjbW381DEgAnVT4j8Gs5JgyqabwFImPAQMkBHzRsEiz
qTzgKXDPpShN23wLxpZwgYQIuY/iYHQZvHLKIkXBzIspzgPD4WkbIvEj5xV58A3Z
+Tmj9mBtOuVJrlxd+XKO5bXxGd47yi3/hfGIY8WtZZ6KPojTJVgHJ4jbZZQIrZw=
=s4eS
-END PGP SIGNATURE-

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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Aaron Bentley]

bzr has a similar feature, but the problem with such a feature is that
it can break scripts that expect the normal behaviour.  That's why bzr
provides a --no-aliases option, which all scripts calling bzr should use.

The same applies to Juju.  If "status" gets defaulted to "status
--format=tabular", most of our test scripts will break.  This isn't
likely to happen on our test machines, but could easily happen when
devs run our test scripts.

Could you please provide a similar --no-aliases option for juju, so
that we can ensure people don't break our scripts by specifying
surprising defaults?

Thanks,

Aaron

On 2015-10-23 12:12 AM, Tim Penhey wrote:
> Hi folks,
> 
> I scratched a personal itch yesterday and added the ability for
> users to specify their own aliases for juju commands.
> 
> There are two primary use cases that I was trying to address.
> 
> Firstly, the ability to specify default flags for commands: status
> = status --format=tabular
> 
> I could never remember the right environment variable to set to
> get tabular by default.
> 
> The second was to allow quicker iteration around playing with new
> CLI structure.  As most people are aware, the 2.0 CLI is going to
> be somewhat different to the current one, and I thought it would be
> good to provide a way in which we could "test drive" the new CLI
> with the existing codebase without having to actually code
> anything.
> 
> The aliases files lives in JUJU_HOME, and is a simple text file.
> Each non blank line that doesn't start with a '#' is considered to
> be an alias. The format is expected to be:
> 
>  =  [...]
> 
> So we can do things like:
> 
> # stat is like two whole letters shorter... stat = status
> --format=tabular
> 
> # list tests list-environments = system environments list-users =
> user list
> 
> and so on.
> 
> Tim
> 

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

Re: Making logging to MongoDB the default

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> The main issue I can see is that once rsyslog based logging is
> turned off we lose the all-machines.log file which some people and
> systems no doubt rely on. The logs for an environment can of course
> still be retrieved using the "juju debug-log" command.

all-machines.log is one of many log files CI stores so that failures
can be debugged afterwards.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWKO+lAAoJEK84cMOcf+9hOZQH/2fK8vGs21NKFw4Q/FZ0covp
Fb+Gjyla1wCVqmimzfxM4sXzBO84HJbBU35B6lAjtPSLdOfC9ywzD/6+Q9r51DLH
9r2MplY1NkqbaGNiqMG7bd8NU94HnhHj+/E8DfAOiYblpE+uVa2ve4bou5FHdMq3
wxfw9DfFcmVCJMabAJDKF9ix07iWF/wl5eKNLwUxiidFh//FT8ij14Ra6a00xBA4
Au45hIIbZdjvIell/YfngZrEocqxj2/9aaW2KzByfVYmIMp0xbjje6+lZMnKFBN4
ozpt5tMVsN6sg7k9j7QA7EelCSnShVbR2DbnpyyFMSLIbcCmvPL1WENGWIZYRss=
=YyCF
-END PGP SIGNATURE-

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

Juju 1.25-beta1 is released

[Aaron Bentley]

# juju-core 1.25-beta1

A new development release of Juju, juju-core 1.25-beta1, is now available.
This release replaces version 1.25-alpha1.


## Getting Juju

juju-core 1.25-beta1 is available for Wily and backported to earlier
series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25-beta1

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 stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.25-beta1.


## Notable Changes

This releases addresses stability and performance issues.

## Known issues

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


## Resolved issues

  * Cloud-init fails when deploying centos with juju.
Lp 1492066

  * Unit agent upgrade steps not run
Lp 1494070

  * Juju status oneline format missing info
Lp 1464679

  * M4 instance types not supported on aws
Lp 1489477

  * Tabular format does not give enough details about machine
provisioning errors
Lp 1478156

  * Cmd/juju/storage: "volume list" yaml/json format is non-obvious
Lp 1495338

  * Config-changed error does not cause error state
Lp 1494542

  * Juju action-set skips values with underscore in the key
Lp 1465844

  * Failed worker can result in large number of goroutines and open
socket connections and eventually gets picked on by the oom killer
Lp 1496750

  * Juju get incorrectly reports boolean default values
Lp 1496639

  * Azure: units fail to attach block storage
Lp 1498746

  * Error creating container juju-trusty-lxc-template; failed to parse
config
Lp 1485784

  * Upgrade in progress reported, but panic happening behind scenes
Lp 1493123


Finally

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

Aaron Bentley

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

Juju stable 1.24.6 is released

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

# juju-core 1.24.6

A new stable release of Juju, juju-core 1.24.6, is now available.
This release may replaces version 1.24.5.


## Getting Juju

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

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

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

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


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * Regression: juju ssh dies with (publickey)
Lp 1472632

  * Juju bootstrap fails to work due to incorrect identities
restriction.
Lp 1486074

  * Cpu-power constraint conflicts with with instance-type when trying
to launch a t2.medium
Lp 1489142

  * I/o timeout errors can cause non-atomic service deploys
Lp 1486553

  * Switch default instance type from m1.small to t2.small/m3.medium
for ec2 provider
Lp 1373516

  * Juju status should show if an upgrade is available
Lp 1464633

  * Juju bootstrap failed - cannot dial mongo to initiate replicaset:
no reachable servers
Lp 1468579

  * Storage/provider: managedfs fails to create fs on full disks
Lp 1483086

  * Provider/maas: volume source won't work for physical
machines/disks
Lp 1483082

  * Upgrade fails if no explicit version is specified
Lp 1447899

  * Juju upgrade from 1.24-beta2 to 1.24.5 broken
Lp 1493444

  * Cannot remove an environment user with upper case characters
Lp 1467037


Finally

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

Aaron Bentley
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWAuv5AAoJEK84cMOcf+9h8lYH/39Lb/6prxTYTg0TsPLRp375
QM+B+T4hjpM+aTFylVJ2Wa4soMK7opqyfLjXGmIE0hk6wM9JshVPk27nCp8vPspN
0SE/LttpUJJr2efpgddhWdr178BTlcX3E0TMf/dHqGPvpUCMsKxsLuC5Sf3lUzXh
QHZU5e8GsWdQkcSCSc+ZZ7CKRwUhtrVlT0vj4y+EwXXxMywj15AuR5tOesyxg59x
BlKsNzDkxps1moxZqZGLPVIHrjuAtjNIH0A9lV+dRDg070hx6/3aMaqqA3WmiiIk
ktjeT1GYGiSMhWnmFesL4yUKsHs66v3soFQhQt1reZxpLk+Oto4BCCQyyaM=
=QOoG
-END PGP SIGNATURE-

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

Re: Will Cloudsigma be fully supported?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I think that makes sense.

I don't think that there was ever much risk to non-cloudsigma users.
I assume the reason for flagging it was to let people test it without
asserting it was production-quality.  But everyone's had plenty of
time to test it now.

Aaron

On 2015-09-02 05:36 AM, John Meinel wrote:
> I would think it is something that doesn't interfere with other 
> providers. Thus if someone is using cloud sigma then they are using
> that provider, but otherwise it isn't in the way. So we can just
> drop the feature flag without impacting others.
> 
> Thoughts?
> 
> John =:->
> 
> 
> On Tue, Sep 1, 2015 at 12:21 PM, Aaron Bentley 
> mailto:aaron.bent...@canonical.com>>
> wrote:
> 
> Hi all,
> 
> I notice that cloudsigma is still behind a feature flag in master,
> as of revision-build 3024.  So far, it has been feature-flagged in
> both 1.24 and 1.25.  Is there a plan to promote it to
> fully-supported, without the need for a flag?
> 
> Aaron
> 
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> <mailto:Juju-dev@lists.ubuntu.com> Modify settings or unsubscribe
> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV5wCmAAoJEK84cMOcf+9hfgIIAJVSUavYNiJhOI79oV3g9AVI
ALG6F4tGCcpuPYFO2UdZAZhm/S+DLh1z5kzPcKFYZwa/BZzaXLBKukCFFw1yz3Go
aEFUAWSQqQThVsYTQDzV2R0axtQyNbr2jtZIg3ZvxewTqEvaTMea/L9hiJLSa7V8
t/kfvdcBrPiftm2MfTmicBhSpq2dSKyxRyFaL20EoU5MNlH79lZwJaYyDR8PQEKe
MhdIW+S7ssZF8ZWjSvAl5D61twLmAdQj3Cz42D4OoU+Yo+URsD4c1mDo+ii6LBMu
QkSqFCFT31QhC/szYasC+F120R4CvC8YijHVotidk8CafoS+3KaE5+fqCEoHkek=
=1YDc
-END PGP SIGNATURE-

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

Will Cloudsigma be fully supported?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

I notice that cloudsigma is still behind a feature flag in master, as
of revision-build 3024.  So far, it has been feature-flagged in both
1.24 and 1.25.  Is there a plan to promote it to fully-supported,
without the need for a flag?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV5d6uAAoJEK84cMOcf+9hpSkIAJ2KgGKjobf8FvuY8xRGas8N
hO4JZSmJvtFIpmuxj1HnzkbrGihzwrggR/zrBv44s1rbV9mIGJ703xVIpMUdexLz
kKZBkzrAs6vP8vB0HUdzXoVzeqIfQiLX2XYHXToc2KKt8TmSe2QlvcXL264F8/AY
2wRwl+Fd64hWgWOmsqSEf56cBZS+mM9zuJlIiBSLd33OtdlWWpfvqhp9pWSCSL6R
moVo1pDnGA5QtJNEOm3qvoVX47WU/L2vzSH8TR1KSrzPo8u0H/RRHwYGoeJf94w8
coCVKhFitS3hKGDZDIbeu6S1RfR+ofEFIMOwp+6NmFbkZYvol9k2r9oBivPjQz8=
=vwyu
-END PGP SIGNATURE-

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

DRAFT 1.25 is branched

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We created the 1.25 branch based on master a8ee96a
https://github.com/juju/juju/commits/1.25

Make fixes to the 1.25 branch and forward port them to master. If the
bug only has a single bug task in the affected table, you need to add
the 1.25 series, and milestone, then change the first task to 1.26-alpha
1

Happy hacking!

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV4K40AAoJEK84cMOcf+9h+5EIAMZokdibes8lrjJChfpXS7Ff
TEKElA96QgFbTBGeZKvSOoIlyUtin3ZUBqqDPk90KQmTWlktoZoXDvACvVbUI4bv
uzpnHXlSPWi9mpmOXV+0bHsC3NXumgKPvK2dKwXlA91tGYBK6bOQ2I9ezUEtg30b
szBotuvsY0X4aJwg3UkyROtrJ5v6SBeolyo3CvWSU0RJkMhI/4Y8dv4yUZhhVWZu
z9kB6WFNg+BtZR02aiH/rLTPYL18ccCTgW/3a8d2RVO/4+HptGcyUq7oKL4rZ2aF
UMCzoOOWYUE7heKVhPsTuw15jX7CsWkjJWfCf2T42T0S8xwSf3u/zFgjngv0tBI=
=ntCd
-END PGP SIGNATURE-

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

Re: Blocking bugs process

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-07-14 10:02 AM, Nate Finch wrote:
> I agree that if a blocker is found in an earlier minor version,
> that upgrading to a new minor version with the same blocker doesn't
> make anyone any worse off.

I think of this argument as "No use closing the barn door after the
horse has bolted."

I don't think it's entirely true.  For a given user, we don't know
what version they're upgrading from.  They may be getting their
updates from ubuntu, in which case they may have skipped the version
that introduced the regression.

e.g.

1. Ubuntu packages 1.21.0
2. Juju releases 1.22.0
3. Bug #37 is discovered in 1.22.0
4. Juju releases 1.22.1
5. Ubuntu packages 1.22.1
6. Juju fixes bug #37
7. Juju releases 1.22.2
8. Juju releases 1.22.3
9. Ubuntu packages 1.22.4

So here, we have users living with bug #37 until 1.22.4 is packaged by
Ubuntu, because we did not fix it for 1.22.1

Or maybe Ubuntu considers bug #37 a regression and refuses to package
any version containing it.

1. Ubuntu packages 1.21.0
2. Juju releases 1.22.0
3. Bug #37 is discovered in 1.22.0
4. Juju releases 1.22.1
5. Juju fixes bug #37
6. Juju releases 1.22.2
7. Juju releases 1.22.3
8. Ubuntu packages 1.22.4

Now, the users missed out on 1.22.1 and had to jump from .0 to .4.

I believe the number of users using juju via Ubuntu is significant, so
I wouldn't consider "the horse has bolted" until the bug is in
Ubuntu's juju.

> However, if we don't make it a stop-the-line, then we need some
> other way to ensure that the bug actually gets fixed ASAP
> otherwise it could just tag along minor after minor and not get 
> addressed.  I don't think it's unreasonable to just make such a bug
> a blocker, just to get it addressed ASAP, even if it is not
> strictly making things worse than an earlier version.

Yes, and often if we react quickly, we can often roll back the commit
that introduced the bug within hours of it being introduced.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVpR09AAoJEK84cMOcf+9h+ZgH/2yt3VbuyogMnK6zKsEFj7wI
ZRkHrQPxOptJwezwzUZRyX6JJmKbYj++Ed/B6npLFY9X6rAzrUl+bSPrr8a39KH7
fznSAOKKHXVuy+IVpNwHZ05J2xVwbvUgz/M1FnNd249xe1+5YVU8W8ZReX/lbY7g
RVrMHZUdgpDnFgS5iZxAMcnjBSLhdHj9WYKpoEpU+/KihmuDJXFTYRSKbe5DHESc
AzpfrTMGrSKRUtqW5vbYZTHw3VYlG7Mp26CTZ7ypugTw5y8rrk1ZJH7A6L1sHRRj
pR6nh7+ldcQ56MvxdIe5gBS2PQDCzty91cX37zrc4UFHI+ZLReDq3FmXNb/9kGM=
=BHlj
-END PGP SIGNATURE-

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

Re: Blocking bugs process

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-07-13 07:43 PM, Ian Booth wrote:
> By the definition given
> 
> "If a bug must be fixed for the next minor release, it is
> considered a ‘blocker’ and will prevent all landing on that
> branch."
> 
> that bug and any other that we say we must include in a release
> would block landings. That's the bit I'm having an issue with. I
> think landings need to be blocked when appropriate, but not by that
> definition.

Here's my rationale:
1. We have held the principle that our trunk and stable branches
should always be releaseable.
2. We have said we should stop-the-line when a branch becomes
unreleasable.
3. Therefore, I have concluded that we should stop-the-line when a bug
is present that makes the branch unreleasable.

Do you agree with 1 and 2?  I think 3 simply follows from 1 and 2, but
am I wrong?

> Depends on the changes. I think we should be pragmatic and make
> considered decisions. I guess that's why we have the jfdi flag.

It's true that the particulars of the bug may matter in deciding
whether it should block, and that's why there's a process for
overriding the blocking tag: "Exceptions are raised to the release team."

I think JFDI should be considered a nuclear option.  If you need it,
it's good that it exists, but you shouldn't ever need it.  If you
think you need it, there may be a problem with our process.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVpQ3pAAoJEK84cMOcf+9h4wYIALzMezSmErdb8Gjuq89aRVU/
CKXZGJ7fWDrsogmsBDOdNhjmtOiIkUIQiZhd3UW5+2WlC+8eix5weJGBWKIo21gx
1hLvR6p6SnZ4zlfxV0RV0pbnfq6RqySEV9agnXzM//H/iqDwZp74ELCgR/1mLkXh
yr19JH1TVx35emqNgO6yFqFVUU6khLPM4JyJ47cjcrDip5f0qLj4gf0nRRE+rasa
uL1bJc47P0HnLr9xKxBWAioo4OMMb2RAUsgApznXWlqu/P3+TVk1eMQf7Vk1XHV8
DbqZgMLz5iJHFpI5T6IUPeeo6BOBz+zhfse6MCqOcOavpsJTzrysMLiqrCpUYt0=
=KeYb
-END PGP SIGNATURE-

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

Re: Blocking bugs process

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-07-09 06:33 PM, Martin Packman wrote:
> == Unblocking ==
> 
> * All bugs tagged "ci blocker" will be marked fix-released when
> the branch has a blessed tip. * QA will mark all other blockers
> fix-released when they determine them to be fixed. * Exceptions are
> raised to the release team.

I'd like to add "The blocker tag should not be removed except by the
person who added it or through raising an exception to the release team."

Aaron

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVo+k7AAoJEK84cMOcf+9hX1kH/i3HwwiBts10NGrNQEYN2apT
dXFMfxd5MfaynjQrxJmL9hkh2zGq9M5KgxjgQKcwifcvh3RL/MWIu2N9Gtxnxee4
AO7sIrrGc0g9ECQ7WXLteGVSzqkyoRd+Q2N0h6e5P+1RrMMOU7rV/WtbnZ74BqXJ
/NmXN+cy/2Pkfef8DjPFFyj13sQud/fh1RDqCXa9Pml7UTTI7zhQYgQrbjmhgKZD
FdcrWzBYa5hNvThR5XX0rIAu0OhS1wySEH8KMwlav9IMCMSSoEI61d59jN3spdeW
apl+6ODI59eX6lxiwctFwSfkAf/1tKALyk0uNPPFmcTGYZ1Mq3BYfN65tRfLkFE=
=Nv+Z
-END PGP SIGNATURE-

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

Re: I'm concerned

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-06-18 12:12 AM, Tim Penhey wrote:
> The certupdater worker was making the mistake of trusting a
> watcher. It was blindly getting the addresses and updating the
> certificate.

Is this relevant?
https://bugs.launchpad.net/juju-core/+bug/1466514

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgsvpAAoJEK84cMOcf+9h9NkIALXSGVmmQu3qjUMwYsqRrk1+
Rh/qKh0oZqxkv6dn7N82IrB8rrMh5Rai1/ZZd49AR9X30U35V2yUnXt3Lx2nT28N
7x7ffJpD4wnD/J2FIjD5bTUX99j79oFinmI8sq4xkAt3X8XBr2T6RIzcjno8ofWr
bwmS1TfExkhYZHwd95Ul8b/unyqE9zcSgp9gYHKrJ/OJNnMRZrnAJxS+y5L+3PS5
e1vRIcxhg+5EHJ751IsbEBZBviT9WaPB3ZIUoFfJYI8hupYusk0yFu69DfaXfP+X
D69Q8d4hEdDaryxDgxjnPhIBOFqpQprdxplwNQz+q8XBprnclj5X+RMRsj3WNJk=
=58uf
-END PGP SIGNATURE-

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

Re: Rule #2 should die

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-06-04 11:41 PM, John Meinel wrote:
> Could it just be a lower priority catch-all rule and have the
> other rules evaluated first? It does seem useful to have a backstop
> against bad behavior when we introduce a new failure method that
> didn't get caught.

Actually, a too-generic match means that a more specific one is
unlikely to be found, because it won't be listed on our "unknown
outcomes" page:

http://reports.vapour.ws/releases/unknown-outcome

So I would rather just rip out the rule or dramatically reduce its scope.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVcavQAAoJEK84cMOcf+9hRIoH/0C7ghhQrXR3p8Mvd7aDTWMH
HXGQyjAAAbS3L4WyIX2LQLBdsGTjNYRa7oeJ4fPrIVEL8QsBCthiFay0z6SvQD0T
PbKsvYLhKphBpOvqjzPVIhMh7pPOvGwBUvH8jeAJp4iPZfUsKz461ebO44N/fyq3
/L9rHntplMuNhOgw4Eu/mYZnP015Cl+Ovvhsw1PXmevWm1o+YVuUtv1v3zBGGvN1
vJT5D3YDDzW0NaKQWwJ8FLkuYxFLUNo46HcCNeJ+aB+FGvuwPjO6N4PlKsWVdHUg
D+Z2uNxT13n0ojFsRdNOTXhMPY01sZbfBeVmJFmxlb5+zPqaDRZXVmUPrp3r07U=
=MQxa
-END PGP SIGNATURE-

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

Re: Rule #2 should die

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-06-04 05:42 PM, Martin Packman wrote:
> Currently juju-reports has a rule matching on failures where our
> CI harness interrupted the test because it took too long:
> 
> 
> 
> This seems too generic a symptom, generally if a test is not 
> completing within the time we've allocated for it, there's another 
> indication in the log, often the final `juju status` output, that 
> makes it clearer why juju never finished its work.

> That all the recent matches for the timeout rule have more useful
> and specific matches (some unfortunately needing to look at other
> log files for all the details), suggests we want those as rules
> rather than this.

I agree.  Now that we can see which attempts matched an issue, we can
see that
http://reports.vapour.ws/releases/2571/job/hp-upgrade-trusty-amd64/attempt/2878
was the first match, and probably motivated the rule.

In that case, there's no greater indication in the main log of what
went wrong.

But I would be happy to change the rule to handle that narrow case.
Something like:

Bootstrapping Juju machine agent\nTraceback \(most recent call
last\):(\n|.)*KeyboardInterrupt

What do you think of that?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVcasgAAoJEK84cMOcf+9hwMYH/13Ky/MWQgzBHQvQlM/tjjZs
ZZ7tqZTlEJv6mfEVoRGKLfeC8ktHh4J4VYB2nNVMkxovHTNB3LAZQmrnNtQLCrbU
rk3hc5VmLefsNAcUoct3E9OPBJJZRiW4p2mPJ1rId65bkTOKI9MW43WcQsgO58Ai
0/CO21DO2GbQY9IeZZqybiSGPTQqoEFwFq+3ODvlqhin/PgsX/kTCG2Qh0FeseRv
zaM6niHEjfW3bi9zZCy982p1nVWB9UssUf9CQPHsOIfzWfqAR0FCZXdhDtGF0Xaw
PSpGkmsmQOd0c9TntGGKbbj95Kip1p2svl1akYx8LhJY7uVR698P/mPLbGR5eKU=
=hF6+
-END PGP SIGNATURE-

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

Re: Running CI tests locally.

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-05-19 09:47 PM, Jesse Meek wrote:
> Hi All,
> 
> tl;dr bash script to run CI deploy job locally: 
> https://github.com/waigani/juju-scripts/blob/master/ci.sh

Cool.

> ci.sh currently only runs the deploy job (bootstrap, deploy two 
> services, add relation, destroy environment). From what I can see,
> this is the only job currently in the juju-ci-tools repository.

There more tests.
assess_bootstrap.py
assess_heterogeneous_control.py
assess_recovery.py (which includes tests for backup/restore, ha, and
backup/restore + ha)
industrial_test.py
test-restricted-network

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVXKYCAAoJEK84cMOcf+9hKccH/1DWBetXHJ+4nJEal31y3qo2
YuJZlAuPb+a2Pfe/hBwyJP+Ub9Pez25lSr0ImZ1U2W49fI10TOZ+LXvIFe801Ufx
WLxtSzLtyg688SpUpykiGzCCsZtciRK5txUHZac/eOMQgNvluXqqV9t2ZXcN/OlL
GvG7IYv0l/nlsZMww2i0MLXhAL1Vi/GmSKmhBY2Z69gyrudV+yudx5ccpaMG3N9G
FQLi+MCJoTBmdUWVWnl+1vfziKRye8hiZIz7YDcFmQC+tCMWJ7Lxp9DFOpMjVHt+
dxwaKHhnlTmzoQTy4/On02vt6ngOEHDKgXYahH9Y9PBE1uKWKU7wyyEuFCwHcfQ=
=DS3H
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-29 12:31 PM, roger peppe wrote:
> FWIW I seem to remember some command line flags being deprecated 
> (with a visible warning message) and then removed. I wonder if that
> might be another possible approach that could let us avoid
> unbounded code cruft accumulation.

No.  You can deprecate a flag.  We'd rather you didn't, because our
scripts use the most compatible commandlines, and deprecated flags are
typically more compatible than their substitutes.

But you can't remove a flag.  That would be "Doing It Wrong".  "Thou
Shalt Not Break Compatibility With 1.18".

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVQTDfAAoJEK84cMOcf+9hE68H/3kl9ETOJI0ggxFAHCg53R5A
kc9oYV5H/9cX74dQ1MQTCs7/wMviw29gW8N3qosxVG80Wq0fkkehAvIlsS4VoG9K
NZZ/7Sv7NzPthr3Ty9Xfu362bssyoWIFAgcBq11UgobZr236N+R1qi914RuhWH2d
w7vbQj9fghNcR+C63cRb8zIOrkO6mNMICEm50wYVtRFVQxq4NphjjyKdY5jqnmqh
lK2mlPTxnpkL1EkSAka05bQDLsPF2Ovf+wyYEorMHxKcbl1+FKNGNIrUAgKC61bU
mOzcDczLhWWVJYqQbqFdCf2Ea6c+Zf+VU+VElN9OpbYHdiD1SXssvPzc3ACAL5E=
=/WpE
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-29 10:43 AM, roger peppe wrote:
>> Once Trusty EOLs, then I think we would be able to drop
>> functionality that 1.18 itself used only for migration.
>> 
>> For example, if juju 1.18 had automatically created .jenvs from
>> the environments.yaml instead of using environments.yaml
>> directly, then when Trusty EOLed, we could drop that
>> functionality.
> 
> OK, this is interesting. So if we do actually want to get rid of
> this feature, the steps would go something like:
> 
> - implement code in current juju-core so that when the juju command
> needs an environment and the .jenv file doesn't exist, the .jenv
> file is created.
> 
> - release that code as part of Ubuntu 16.04 Juju.
> 
> - for the 21.04 release (when we no longer support 16.04 support), 
> we can remove the fallback feature.
> 
> Is that about right?

Yes, I think so.

> Or is even that not possible, because the automatic .jenv creation
> is a feature in itself that must be maintained?

As long as nothing that comes out of $SERIES-updates contains a change
that stops things from working that previously worked, I would be
content.  IOW, I think migrations are a special case.

> Out of interest, how does this apply to command-line flag
> compatibility, where there's no possible automatic migration?

There's no wiggle room.  As William said, "if you're removing or
changing an API, or removing or changing the meaning of a command line
flag, you are Doing It Wrong."

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVQQJnAAoJEK84cMOcf+9hI/0IALneo7jxfiPzy7Sw5xvDlIiV
yFJ/MMoYvuSPzniC8WCOeBabCw8tdLOR2CFmyv8llmNk9XsmBtB73OH8cztRho5V
v7cAw2slAaZhBxynARvXls7r/+jaI5BI/6cccojYYYoslMroRwFG/YZT1pVwHCgt
eZOXSQ1xRX+6ZkkcFL7D8deLeaGAtgesV8gOP7kw1hqPGGXdJCQgMkJ+vxMt5XH9
93QGU0onP3u7rs/Yy6wvSPafsO3e0yu7oRAQ23yJjfFT0CgbA0APN6qi4i2orfhu
RbS6sYZmRaOca0W8dvRsKkcGgNTwJ0VUxbTrfcOWtt2u46MHnPF9Di+IioQFxIk=
=oYGu
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-29 09:41 AM, Nate Finch wrote:
> I think you're missing roger's point.

No, I understand his point, and I think that his extrapolation is
incorrect, and I explained how.

> 1.18 has some fallback code to support 1.16.  However, we don't
> support 1.16 anymore.  But because that fallback code is a
> "feature" in 1.18, we have to support it in 1.20. But that means
> that even when 1.18 is EOL... 1.20 still has the "feature"... and
> thus we have to support it in 1.22.  And even when 1.20 is EOL...
> etc

Right, if 1.18 supported it directly.  But if 1.18's behaviour was to
migrate, rather than support directly, then when Trusty was EOLed, we
could assume that everything had been migrated, and drop support for
the migration.

> Once Trusty EOLs, then I think we would be able to drop
> functionality that 1.18 itself used only for migration.
> 
> For example, if juju 1.18 had automatically created .jenvs from
> the environments.yaml instead of using environments.yaml directly,
> then when Trusty EOLed, we could drop that functionality.
> 
> The other thing is that Juju 2.0 will not have this requirement.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVQOFLAAoJEK84cMOcf+9hgsoIAMFNwJxD2muYhpp2CeD8knLx
LDQtoyQoYgHWh3xlJS20uYyjzCLEJg7V3392GOLC6mqhltaMtNcSjTXGakJD2mVj
LUHUINfcOQZPm/LLftSfYSgk3MFFlvYtU1es6lzSCgBTFJ0U2mZ1wEn/dXnWlotm
XUuR8QVT4PCUMivjEjLefevY+bpetRWB7AlspOOuyfJxO+/4O2h4iBnHKeP8yUlV
HJnQWskdg7Vi7vIaPGONYbcIg3uaBsWFPpc2AEEMWIsmqlf3NyXtgHmK/EHMdG0W
w+GOTzvch8XCZ6AnzqQbo64W5Hb55al4bmN1jQGm4czTJ2W8E45vBnrAny3Fm88=
=NPEr
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-29 04:10 AM, roger peppe wrote:
> On 28 April 2015 at 19:32, Aaron Bentley
>  wrote:
>> On 2015-04-28 11:42 AM, roger peppe wrote:
>>> The .jenv code was introduced prior to 1.16. How far back in
>>> time do we need to preserve compatibility? (genuine question)
>> 
>> We need to support every mode of operation that 1.18 supported.
>> Juju has a special exemption that allows minor releases, rather
>> than micro/bugfix releases, to added to Ubuntu.  But in order to
>> use that exemption, new versions of Juju are supposed to be
>> equivalent to a micro/bugfix release in terms of their
>> compatibility.
> 
> So in general version 1.n will need to support every mode of
> operation that version 1.n-1 supports? By induction doesn't that
> mean we can never remove any features at all ever from Juju,
> because every version will need to support every mode of operation
> supported by *all* previous versions?

No, only as long as 1.18 is in a supported release, i.e. until Trusty
EOL.  But as William said, "I tend to abbreviate this in casual
conversation as "forever""

Once Trusty EOLs, then I think we would be able to drop functionality
that 1.18 itself used only for migration.

For example, if juju 1.18 had automatically created .jenvs from the
environments.yaml instead of using environments.yaml directly, then
when Trusty EOLed, we could drop that functionality.

The other thing is that Juju 2.0 will not have this requirement.

>> We had our own IS people upgrade to juju 1.20 from 1.18 and find
>> that juju no longer worked.  That's terrible.
> 
> Would it have been so terrible if the release notes had said "to
> upgrade to juju 1.20, run this tool to transition your existing
> local environment store first"?

Yes.  People can upgrade from 1.18.4 to 1.20.11 using apt-get just by
having the trusty-updates repository enabled.  They are not supposed
to have to read release notes-- trusty-updates is supposed to be
non-breaking changes.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVQN35AAoJEK84cMOcf+9hs8cH+gMNGV4Glnp2gfqdomKPlzGd
q92ukPLFFw8LL745OjGczn4Cy0BKqLT8kafMINKptx17MiC+vEHbuxnTNoHfrMKQ
vqlUqzb7lwZMEc6s9j0iguFGJ/IjpF0tUeYOIZQst6lwPKlqUlA6KXhkCcvg3mh0
IpBkCQDlkSUfgP8xLZLdIq0OyZls6WPBsrZmywT0+rfnimMNlJSc82gIs8HFmnfN
blisw8Y721VywJyja+gvhhPM9ylwi4SvAaJ/s9+yVk8bEUmQe3YM567+LVqrf2Hz
v3s46q5597BR0ECddUCIQYxATtDkSeU45RwdawHAHChosdJwXIVGGoSt9Ner5B4=
=B7QT
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 2015-04-28 11:42 AM, roger peppe wrote:
> The .jenv code was introduced prior to 1.16. How far back in time
> do we need to preserve compatibility? (genuine question)

We need to support every mode of operation that 1.18 supported.  Juju
has a special exemption that allows minor releases, rather than
micro/bugfix releases, to added to Ubuntu.  But in order to use that
exemption, new versions of Juju are supposed to be equivalent to a
micro/bugfix release in terms of their compatibility.

We had our own IS people upgrade to juju 1.20 from 1.18 and find that
juju no longer worked.  That's terrible.

> If transitioning to the new scheme is really an issue, it would be
> easy to write a very simple tool that would allow a .jenv file to
> be created from an existing environments.yaml entry.

No, that's not the issue.  We have workarounds.  It's not supposed to
break in the first place.

> Or is the issue perhaps not just one of backward compatibility,
> but that people are actually relying on this (ostensibly
> only-for-compatibility) functionality even for environments
> bootstrapped since 1.16?

I don't know what "ostensibly only-for-compatibility" means.  Yes we
need to be compatible, and yes we need to stay compatible.

Juju needs to be compatible with 1.18.  As William Reade said, "Thou
Shalt Not Break Compatibility With 1.18. We Are Stuck With It."

https://lists.ubuntu.com/archives/juju-dev/2014-July/003073.html

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVP9I7AAoJEK84cMOcf+9hYDwIAMXShmggDItLppDY3r4sKom3
6dyv2A3/vUHrRn2oeKeg1OdKnQpjxp0K7Tun4Q+QDSglEdA3w8Alm3vXPHXO2w73
YbYhdRxu5uEbGENtgokI8VPvfyD1eXJqLkpEHLs5NdR6G4ub/ws/kCQra1q8IyeK
3Msm68S1Xt6mUCRFVSOxJ5oIRCPaZKJCdUm4rsoZgkzxidMg77APOeChF39TMwbs
sPAHiqEUf8tw0/LQJH972OaEuRAdiZRK/VVtHc8E/TTH4PoIy9xaN6zPpuxP6Xxq
mEmIArIgyUPzKtQwudDfprxXo77TI6J9FvQSz4HWhmmMteQWnFU9U6jkJDdGDNI=
=q20K
-END PGP SIGNATURE-

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

Re: previously valid amazon environment now invalid?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-27 05:30 PM, roger peppe wrote:
> That fallback code was designed to be around for only a short time
> - I'd suggest removing it.

We have bugs about the fact that the fallback code has been removed:

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

Juju is supposed to be compatible back to 1.18.  Please do not remove
compatibility code in the future.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVP5sBAAoJEK84cMOcf+9hPSgIAKUn90cMRb3rAvKRhIgXNlLp
I9mOtqLWBo2APwW0RqXPM9XJyK4nn7Im394ORXLdYZv2/0BfJtHNys8M8Tq7gk9B
LBN3NdrI0g/LJQsuUa/6ciZ+P07fG8Xd7OMakr2evUDFPuneZ8foAi8rK7NCWkO5
TXYBh8FmRl8n0m5u9yAkEAHC9i16Dm20/hTuWPJBknqv2u/r6Y2JymnKuPCJa7ye
/CQcTAuK1xpFk40fMYwGZ1AJLT6ZP0xTEpGAp3BPZrSZra9sAfwRcCPblXvKo8pG
JzfGHTgVHCvXq/7SoJJ3glWpWMg+dcAG08mAN47Y8PNpI7R8IGyBpW0Pz4jJIOs=
=YmBa
-END PGP SIGNATURE-

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

Re: Feature flag for a provider?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-23 12:27 AM, John Meinel wrote:
> Thinking it through a bit more, I wonder if that is the best
> option. Because if someone is already bootstrapped on CloudSigma
> you really don't have any reason for it to not support CloudSigma.
> It is just broken if it isn't working.

In other words, if they are using a CloudSigma environment, they have
accepted the risk of using the 1.24 version of the provider.  That is
true currently, but it won't be true in the future, when 1.25 is out.
 Presumably 1.25 is production-ready.  If 1.24 isn't production ready,
then if they switch to a different juju (e.g. switch from a desktop to
a laptop or use a team-mate's machine) they could be surprised by a
not-production-ready experience.

Of course, if 1.24's version *is* production-ready, then there's no
reason to keep it behind a flag.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVOPzhAAoJEK84cMOcf+9hFCQIAJoy+WpBhXYUDrrfQcuMbJFQ
2WxGgW1+Nu5Ro1hTgON7Kfxs4ZxSZxlUOZ6TbLFWhXgLgGSyaDh3xc/Mevmn/niX
VS2Ig8W/oMYEpumZ+n4950curoTClgwjA6v3BqipefLyljHZNfz95STgPoYOa8Qy
ydUKehum5FziqVg3+jy/EJZgktXrzA6BhZ+pa4PHp7ZMzhPhTedgR50rXsc841vs
EDYkEb4BxbqWlIJbOZ6Ul9tZb9Ve2CoOE7IBh9ykWCUGWCscIh4axdLGqODn1Obz
USlp4jzk8fYurSKcnnB5z7DiFcKzhwbR2V0PyN1gEf50LFbYWkbd5mLbE8P6Pyk=
=5xZY
-END PGP SIGNATURE-

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

Re: Need advice on my juju plugin

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Any insight on what I'm missing is appreciated. Another note is I'm
> not quite sure if there is an alternative to getting the current
> running environment other than doing a `juju switch local` then
> running the plugin pulling in envcmd.GetDefaultEnvironment, seen
> here:

`juju switch` (aka `juju env`) will tell you the current environment.
 Your plugin should accept -e/--environment to override it.

I wrote a g+ post about plugins recently:
https://plus.google.com/+AaronBentley/posts/45FA3LDkcv8

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVN7kcAAoJEK84cMOcf+9h6UoIAKa1o3TMqvbfJgWZUMmkP9EN
5EzFtQ3tOxHWETa2cctoJazR7sXTzYtkgLznmHxmnBaASkWZ9ro0wjOfPzzq7NEL
m75c6ypmRraqZ/gQQMrsiVMvTE3djAoVUVB/slJ0zXqAD8tMsQ/DjwWzcPfv5xWX
ZWEV9EOnobVaSss7eqsHj7Hc7BZ7QmnrCdX803qj/7Sh1S+sN1650u87j949gfw5
w93mIhdBLTyMjKMhJaybozlMJZ8HFsMGcnnmqstBKulJS3KMLaBEbwlXuU09YBrV
zBIdP9DWs6ZBYmRqrD923EVkkB4k+A49RhSt9Syv16ViZyVJA23zPCahFZVSqfc=
=tjm2
-END PGP SIGNATURE-

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

Re: Feature flag for a provider?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-22 09:00 AM, Wayne Witzel wrote:
> I've been told to place cloudsigma provider behind a feature flag,
> but the result of that is that the provider is not registered
> unless the env variable for cloudsigma is set.
> 
> So after wrapping the registration of the provider in the feature
> flag (see: 
> https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82),
>
> 
the tests no longer pass, since there is no registered provider for
> cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma)
> from the Suite and/or Test setup methods doesn't help since by that
> point the "init" for each provider has already been run.
> 
> Looking for suggestions? My thought is that the flag isn't needed
> since by nature providers are contained and their code is only
> called if you explicitly use the provider.

I think there's a potential quality issue.  I don't know anything
about the state of the cloud sigma provider code, but since it's being
kept behind a feature flag, I have to think
a) The code is not yet production quality or
b) The API isn't stable.

Say you're using Juju 2.5, in which the cloud sigma provider is fully
production quality.  You create an environment.  Then you go to a
machine that has Juju 2.4, where the provider was not
production-quality, and try to perform an operation on that
environment.  Does Juju break?  Does the environment?

Because you weren't paying attention to the Juju version number, you
may be surprised by poor behaviour.  Instead, it would be better if
Juju said: "CloudSigma is not production-quality in this version of
Juju.  To enable it anyway, set JUJU_DEV_FEATURE_FLAGS to $FOO."

So to avoid surprising users, I think a feature flag makes sense.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVN6FkAAoJEK84cMOcf+9hXR8IAKoenxmb8797B7xaNB842ZkH
tlwwvsc/joO8Cy73OPFyNg1NQ14g4FVCUJJ6q0qgj51ubIrB1725a0XwilUYSme5
uQGqEebZx6o9Q1SCP7uxOAZ4SEH7KftjIiqKG7kTzV93ZSeJtyK3Y7K7IuKw18UL
VvOdhxrAie/dBnxhx16CqqbJcSj21RqLmd9osgL+gWTPtZ+UkAwV5nDqunAfaqt4
9DeoYloYVeqaFlQoTsyMB0hxd3Z63S+gHcjGWSRfAqdXCOZFjMntdbq8+dOMDMvB
FkL0GBKliC7tPio2/w7OF4UW8AGMxQvMGddJflOFFt+CNAGwaLtxf6mHuA9jRGw=
=VdEM
-END PGP SIGNATURE-

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

Juju stable 1.22.1 is released

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# juju-core 1.22.1

A new stable release of Juju, juju-core 1.22.1, is now available.
This release replaces 1.22.0.


## Getting Juju

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

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



## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

* Juju cannot deploy when distro-info-data gets a new series
  Lp 1427879

* Juju backup fails when journal files are present
  Lp 1423936

* Copyright information is not available for some files
  Lp 1435974

* Juju restore failed with "error: cannot update machines: machine
  update failed: ssh command failed:"
  Lp 1434437

* Unit test failure:
  testnewdefaultserver.n40_github_com_juju_juju_cert_test.certsuite
  Lp 1437040

* Certsuite.testnewdefaultserver failure
  Lp 1435860

* Apt-http-proxy being reset to bridge address
  Lp 1437296


## Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVJXggAAoJEK84cMOcf+9hlrUIANedDZIx+jzu+4GhL0a8YFI1
9PCmiOcH07AWgLe+dKRXRntFt1YZqxpy+VNAMM7+0B6JoIT09sLV/WYwSyJcpUj8
cdMKVZZ/QLc45DTvD6BulhmRlfmNf+yRvy2fDZVVpJRMyVpazv8DGxV0AGmDeJ6P
BU/gShlsLg4vNAxlr/m7cPqk0ApLQgJFka73mQ+khYJO4IB/mj/SyQ9GqOfnqHuh
QLkqWvXGMKJXAdLP0hFGGIHrizD42giEEV1JDtZtGQwfaLXuujumQrjiIp9AwCIy
onQ5Q0H9jO4eNzLrkfIK1rOzW8bAxogdBsUxVNcX7xGwzMIapd07hxNbKiYBFW8=
=gbsn
-END PGP SIGNATURE-

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

juju 1.22.1 is proposed for release

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# juju-core 1.22.1

A new proposed stable release of Juju, juju-core 1.22.1, is now available.
This release may replace 1.22.0 on Wednesday April 8.

This is not an April Fool's joke.


## Getting Juju

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

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

The proposed packages in this archive use the proposed simple-streams.
You must configure the 'agent-stream' option in your
environments.yaml to use the matching juju agents.

agent-stream: proposed


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

* Juju cannot deploy when distro-info-data gets a new series
  Lp 1427879

* Juju backup fails when journal files are present
  Lp 1423936

* Copyright information is not available for some files
  Lp 1435974

* Juju restore failed with "error: cannot update machines: machine
  update failed: ssh command failed:"
  Lp 1434437

* Unit test failure:
  testnewdefaultserver.n40_github_com_juju_juju_cert_test.certsuite
  Lp 1437040

* Certsuite.testnewdefaultserver failure
  Lp 1435860

* Apt-http-proxy being reset to bridge address
  Lp 1437296


## Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVHDmjAAoJEK84cMOcf+9hlr8IALRi+ymPJZyS4Nf/Mk5gBP8T
udHONzJ1S9Wx7FExIhbfFLVUotblENaUE+ITMDpd1kj0/9zpYCHgiBiRiHzALYi6
PTTl1ilK1TlrNdAJzV2S47nIS+1Y7Pr2jFEm1CS1qtoLv2xVV61LjhI0OBp5v0T9
WrtM7YaUCKq7AFJ48dlOFBKk7beTe+2pZEXkqqaoufiWBOELnK/fI6MqCibF76N/
EE0Kru4ylVLfsk4+FQJVF59E2VWCFVQ/piCW1rmue2ap85M87SJQiXOxLNvI78fu
LT2LlH86jGGVNHFtk/JimLd8eoM78I33eyDwFPXr/JoNf5jJ6LNS5ff+4UOpG0E=
=ZXWS
-END PGP SIGNATURE-

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

Re: Juju devel 1.23-beta1 is released

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Correction: The PPA URL should be
https://launchpad.net/~juju/+archive/devel not
https://launchpad.net/~juju/+archive/development

Sorry about any confusion.

Aaron

On 2015-03-23 03:27 PM, Aaron Bentley wrote:
> # juju-core 1.23-beta1
> 
> A new development release of Juju, juju-core 1.23-beta1, is now
> available. This release replaces 1.22.0.
> 
> 
> ## Upgrades from 1.22 are broken
> 
> As seen in Lp 1434680 1.22.0 environments cannot upgrade to
> 1.23-beta1. Upgrading environments from earlier versions of Juju,
> such as 1.21, should work.
> 
> ## Getting Juju
> 
> juju-core 1.23-beta1 is available for vivid and backported to
> earlier series in the following PPA:
> 
> https://launchpad.net/~juju/+archive/development
> 
> Windows and OS X users will find installers at:
> 
> https://launchpad.net/juju-core/+milestone/1.23-beta1
> 
> Development releases use the 'devel' simple-streams. You must
> configure the 'agent-stream' option in your environments.yaml to
> use the matching juju agents.
> 
> agent-stream: devel
> 
> Upgrading from stable releases to development releases is not 
> supported. You can upgrade test environments to development
> releases to test new features and fixes, but it is not advised to
> upgrade production environments to 1.23-beta1.  In particular,
> upgrades from 1.22 are broken.  See above.
> 
> 
> ## Notable Changes
> 
> * New Blocks * New Style Restore * Addressable LXC and KVM
> Containers on EC2 and MAAS * Improved Proxy Support for Restrictive
> Networks * New Charm Actions * New Support for Google Compute
> Engine (GCE) * Service Leader Elections * Support for systemd (and
> Vivid)
> 
> 
> ### New blocks
> 
> You can now specify block message when you enable a block. For
> example, you can add a message to 'destroy-environment':
> 
> juju block destroy-environment "Don't destroy this environment" 
> juju destroy-environment ERROR Don't destroy this environment
> 
> You can list the blocks enabled in the environment like so:
> 
> juju block list destroy-environment=on, Don't destroy this
> environment remove-object=off all-changes=off
> 
> The Multiwatcher now has information about blocks. There is now
> block client capable of switching blocks on/off as well as listing
> all enabled blocks.
> 
> 
> ### New Style Restore
> 
> You can now restore a backup with the new 'backups restore'
> command, which is more reliable and fast. New restore supports
> backups generated with the deprecated Juju backup plugin and with
> the recently added 'juju backups create' command. You can restore
> from a local backup file like so:
> 
> juju backups restore [-b] --file 
> 
> Which will optionally bootstrap a new state server, upload a backup
> file and restore it. The -b flag will fail if there is a running
> state server.
> 
> You can also restore from a backup stored on the state-server:
> 
> juju backups restore --id 
> 
> To obtain a list of the existing backups in the state-server you
> can use:
> 
> juju backups list
> 
> 
> ### Addressable LXC and KVM containers on EC2 and MAAS
> 
> The Juju EC2 and MAAS providers now support starting LXC and KVM 
> containers with statically allocated IP addresses from the same
> subnet as their host machine. This means workloads inside
> containers have the same network connectivity as workloads deployed
> on machines. Nothing special is needed to benefit from this
> feature, as Juju detects whether address allocation is supported
> and handles the necessary steps automatically. Example:
> 
> juju deploy wordpress --to lxc:0 juju add-unit mysql --to kvm:1
> 
> Once the container is provisioned and started, you can see in
> 'juju status' it will have an address from the same subnet range as
> its host. On MAAS, the juju-br0 bridge device is no longer created
> at initial boot so that containers can acquire IP addresses via
> DHCP. Instead, depending on the container type, the default lxcbr0
> (LXC) or virbr0 (KVM) will be used. This also solves a number of
> issues with more complex networking.
> 
> There are a few known limitations at this stage, but most of them
> will be resolved in time for the 1.23 stable release:
> 
> * EC2 Ubuntu images Juju uses typically does not support KVM
> extensions. * EC2 has limits on the number of additional IPs a
> certain instance type can have. If you plan on starting a lot of
> addressable containers, please make sure you select a larger
> instance type. Juju will eventually expose information like
> "address limit exhausted&

Juju devel 1.23-beta1 is released

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# juju-core 1.23-beta1

A new development release of Juju, juju-core 1.23-beta1, is now available.
This release replaces 1.22.0.


## Upgrades from 1.22 are broken

As seen in Lp 1434680 1.22.0 environments cannot upgrade to 1.23-beta1.
Upgrading environments from earlier versions of Juju, such as 1.21,
should work.

## Getting Juju

juju-core 1.23-beta1 is available for vivid and backported to earlier
series in the following PPA:

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.23-beta1

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

agent-stream: devel

Upgrading from stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.23-beta1.  In particular, upgrades from 1.22
are broken.  See above.


## Notable Changes

  * New Blocks
  * New Style Restore
  * Addressable LXC and KVM Containers on EC2 and MAAS
  * Improved Proxy Support for Restrictive Networks
  * New Charm Actions
  * New Support for Google Compute Engine (GCE)
  * Service Leader Elections
  * Support for systemd (and Vivid)


### New blocks

You can now specify block message when you enable a block. For example,
you can add a message to 'destroy-environment':

juju block destroy-environment "Don't destroy this environment"
juju destroy-environment
ERROR Don't destroy this environment

You can list the blocks enabled in the environment like so:

juju block list
destroy-environment=on, Don't destroy this environment
remove-object=off
all-changes=off

The Multiwatcher now has information about blocks. There is now block
client capable of switching blocks on/off as well as listing all enabled
blocks.


### New Style Restore

You can now restore a backup with the new 'backups restore' command,
which is more reliable and fast. New restore supports backups generated
with the deprecated Juju backup plugin and with the recently added 'juju
backups create' command. You can restore from a local backup file like
so:

juju backups restore [-b] --file 

Which will optionally bootstrap a new state server, upload a backup file
and restore it. The -b flag will fail if there is a running state
server.

You can also restore from a backup stored on the state-server:

juju backups restore --id 

To obtain a list of the existing backups in the state-server you can
use:

juju backups list


### Addressable LXC and KVM containers on EC2 and MAAS

The Juju EC2 and MAAS providers now support starting LXC and KVM
containers with statically allocated IP addresses from the same subnet
as their host machine. This means workloads inside containers have the
same network connectivity as workloads deployed on machines. Nothing
special is needed to benefit from this feature, as Juju detects whether
address allocation is supported and handles the necessary steps
automatically. Example:

juju deploy wordpress --to lxc:0
juju add-unit mysql --to kvm:1

Once the container is provisioned and started, you can see in 'juju
status' it will have an address from the same subnet range as its host.
On MAAS, the juju-br0 bridge device is no longer created at initial boot
so that containers can acquire IP addresses via DHCP. Instead, depending
on the container type, the default lxcbr0 (LXC) or virbr0 (KVM) will be
used. This also solves a number of issues with more complex networking.

There are a few known limitations at this stage, but most of them will
be resolved in time for the 1.23 stable release:

  * EC2 Ubuntu images Juju uses typically does not support KVM extensions.
  * EC2 has limits on the number of additional IPs a certain instance
type can have. If you plan on starting a lot of addressable
containers, please make sure you select a larger instance type. Juju
will eventually expose information like "address limit exhausted" so
such cases will be easier to detect by the user.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI
  * Statically allocated addresses are not yet released on container
shutdown, but a solution to this is already in progress.
  * At this stage, Juju does not guarantee every container will have a
static IP at launch, but will make a best effort to do so. If
allocation failed for some reason, every step of the process is
logged, but the container will still come up with a host-local IP
(e.g. 10.0.3.x for LXC and 192.168.122.x for KVM).
  * Workloads inside addressable containers can be exposed behind their
host's public IP address, but port conflicts are not detected or
handled. This means for example, if port 80 is take

Re: Testing on windows

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-03-19 06:07 AM, Michael Foord wrote:
> Do all tests pass (or skip) on Windows now? Do we have a CI job
> running them?

We do have a job.  It does not gate merges.

http://juju-ci.vapour.ws/job/run-unit-tests-win2012-amd64

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVCtFEAAoJEK84cMOcf+9h51UIAKNZX9movxP0zL/BMdeDz9B4
sZvmbaNBH4kt/Uu8K4rzToPd2eY5axGBByDFSIOL1cnqdzNNcCYoslrjTI7JnUEZ
CEBKSrTeMvvJYwdmRVcrYFx1H3npN3KNS4/gl3TgMJVchYe9ilG/kn/XlXM3JZVC
lN7hkKM1sJKDyMuoO/GMFLoNuP7q9+5PoTrI1oN+19c09jVjuZG1IgVoIKn+xGcV
7X3HWo10x1Mu49mUxC/dsT5IsgysMUlps35G5TsSOP+IuaRz2anxhtIsx/s9ONl9
+dLQl7SncOYbWec9oU0hPS+9w3q+wMB4gnzGw8oqcRtXE8UbhH/Dv98a9m0v8xI=
=LR+k
-END PGP SIGNATURE-

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

Re: Trivial bugs hurting progress

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2015-03-04 08:53 AM, Dimiter Naydenov wrote:
> If it's about catching map ordering issues, let's use go 1.3+ as
> an extra step, rather than gccgo, which is buggy and slow and
> randomly segfaults. It's likely we'll slow down merge gating
> considerably.

It's not just about map ordering issues.  It's about complete
compatibility with GCC Go.  For example, there are issues with test
doubles that have had to be worked around in the past.

When a GCC Go incompatibility is landed, we sometimes spend days with
an unreleasable Juju before it gets fixed.  It has been 3 days since
master was releasable.  Even though GCC Go is slow, it's worth it to
avoid three days of being unreleasable.

My 2¢.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU9xieAAoJEK84cMOcf+9hDg0H/j6TYPNbI92arsWimT21bxve
1TOBvXtlGJCAwsiZOU//mEKwHXmChrm/a8F2YeWlMDAvk4+Uw4Wid5EViucZiNK9
+IhrpCqG835PMhyxVRbOVzSYoxsjrn1E1Kb5Q+tcOWqrjntoj4JrFMKeCIuANTVj
yi56sl1jNNtOKV0SpmGnILuNNrFVXpy0i4P0Iz462V5sbQ5VtSXwtRc1rtK5OJA6
b47cv346z+DqPJahWNknG+yt2RaGQWzOfTST46B3kiU9CEKsH/U4P3nY9Ixx6hBz
uH8FHpQpfHByK2FPTs9+thnViD30YUaPdFNUnT8FfRnEaNjpqaDEs4jgOafI8LE=
=4tUi
-END PGP SIGNATURE-

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

Re: m1.small rapidly becoming a scarce commodity

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-11-20 02:49 PM, Nate Finch wrote:
> We need to change the ec2 provider to request something else
> instead

Isn't Juju 1.21 switching to SSD instances?
https://launchpad.net/juju-core/+milestone/1.21-alpha2

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUbk3LAAoJEK84cMOcf+9hRQMIAJzynA/kBMyXob7pWoCAqbgo
vPXehu5Ngclh0vxf3L3LyXF7aX8RAg51hFUfxrU2DuHhlQX6yM5KOekDD+NDVpso
rJ6wAeg3DT1LmiuSQldFveBXaQVjB/rF6ukLLYVMBu8Lj8sdNN4tuSEegauztedx
GkiU7cpZO2zRuwZdFYyxnVTCFm0uwmjlURZAQ2YQqrpSS9O4L7baY60tMG7TyVVA
vHKeAWYrQxFif5r7jso7YSp+F2WW+/4TfuoWjmiSsqfogv16FNYAIgae8ZoExJLP
9xxSSsUGZOW1MG0uK6RgrcOHQ2TqK/boIzxe6NEF2b+UASKFfQzrK7eCsnOKmZA=
=zTY4
-END PGP SIGNATURE-

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

Re: supplement open--port/close-port with ensure-these-and-only-these-ports?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 2014-11-01 12:58 PM, John Meinel wrote:
> I believe there is already "opened-ports" to tell you what ports 
> Juju is currently tracking.

Kapil says that's in 1.21 and I was using released juju, so I didn't
see that.  Cool.

For stateful charms, I think opened-ports is the second-best solution.
 It's possible for a charm to handle ports in a stateful way, but it's
more work than ensure-these-and-only-these-ports, and I think it's
work that any stateful charm would need to repeat.

> As for the rest, "open-port" only takes a single port (or range), 
> which means that if you wanted only 80 and 8080 open, you would 
> need a different syntax. (something that lets you specify multiple 
> ports/ranges to be opened).

That's what I meant by "open-port would need to accept multiple ports,
not just ranges"

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUV5MpAAoJEK84cMOcf+9hXC4H+wYiz3XmR8k1d6WO+ZOMPjUb
p/HbvK2yqhxllzxBndmgLiZCWMEAg5au3TBueJwqN4YQHUV13M725gcIEtaPlyyG
bzY3EYlpgvtch4RSNOeGyNZt8UqrFpnvuo73sVKEU9JfLE0d+8pO37YfO8tElWwm
U1hKM1wJHvtVVo3Xl7M6x/pb7Gwija7QaTf6qUOIim5WN6xqZTRT4zAlC4R9jUdt
52zHW9woIhM3iMKL2iFIkYrSm7DV8jCK0e4yP1yMQtipFVul15iVcZ5Elx37nbmU
jDbXajMBrFPhqs4M/KrzrSBym/O/jbF917Lz6g76Kvu43sOo/wvBqwEnqpW6ldc=
=gpIq
-END PGP SIGNATURE-

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

supplement open--port/close-port with ensure-these-and-only-these-ports?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I take a stateful approach to writing charms.  That is, my charms
determine what the target state is, then take whatever actions are
needed to get the unit into that state, paying as little attention to
the current state as is possible.

open-port / close-port require knowledge of the current state; if I
know that I want only port 314 open, then I need to know whether any
other ports are open and close them.  In most cases, a charm only
opens specific ports, so I know which ports to close.

Right now, I'm writing an update to the Apache2 charm that would allow
the user to specify which ports to serve http on, which means that
when a user changes the port, I may need to close the old port and
open the new one.  If I want to use close-port / open-port, I need to
track what ports are open.  But juju already knows this, so I
shouldn't have to track it separately-- that violates DRY.

The smallest change would be to provide a way to list the open ports,
so that charms can close any open ports they no longer want open.  But
that leaves a bunch of work for a stateful charm author.  What they
actually want is a command that ensures specific ports are open and
closes all others.

ensure-these-and-only-these-ports was the first thing I thought of,
but we could extend open-port instead.  open-port would need to accept
multiple ports, not just ranges, and it would need to accept a
- --close-all-others flag, that would close all open ports not listed.

Does that seem like a sensible change?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUVOo3AAoJEK84cMOcf+9h2acIAL5ogJIy4O23TKa/RiWUcv0E
wX9NHpNj9r7P8LoEHwUN/0nIeLi0UPQtDMN/w2orKGK01oXsPvvoVy/SPmMH+8G+
yjOWQY1ppjB42vFsdLlP1d6VFutI94hiLEFgfT1ss9JSbPZXteakoKmhG3Og+W4e
pZSrvVjccZPp3IhSsGclfVxVJLD+lMYxXL7NA/x4ji74YMiUE8pH3OCbCeOjderw
oHlDMPClItugqvgAtCiHpr/n79yB75y1FARalsbXelXullgBLpiRxTQHgBq/yfn+
o22d1uCmp+xqIveyUS433RffEzMDDt61UaZTuyui8ZG9n4/Jy9xOpKN9wGDhhvE=
=gzrL
-END PGP SIGNATURE-

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

New regression: set-env no longer accepts empty values

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have discovered a regression in juju set-env.  I have filed a bug
accordingly:

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


A recent change to juju broke set-env, so that it no longer accepts
empty values.

In old versions this worked:
juju --show-log set-env -e kvm-upgrade-trusty-amd64 tools-metadata-url=

In new versions, it gives:
error: expected "key=value", got "tools-metadata-url="

Revision f81cc435 is the first version that our tests show exhibits
this bug. We also know that 289da217 did not exhibit this bug.

This is a regression because
- - It breaks commandline compatibility with other juju releases
- - It breaks CI
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUU4Z4AAoJEK84cMOcf+9hXB4H/2gonXpLZnEvwhQRegF4khM1
s8r6VL7siQO6N2NeVWqH0tNzCHT8F2yOWN1bPJuiql0QsOtCe/ejqTDDOiyE5qjY
6SyZ4Gp9MPLxED/dplUsYeaIRSa6EJOmLPNG6KP+IQmT8hPE0bv5ZACk1qDDXPGh
JZW2Wr4Xr1L/13xzY8UdUc2J6hZ3lsTkwCLLjsvSIJ0SjIGn9lVUR29PNRu/1GxT
ETdpdTeYy1blqT+B/O5lLJS7LGdG5+Xlc4xKjOv3gvXPjMHxw0mU8mSleAOWEohY
5y/HTOGZgYDCSTVLaZIAaiTQIaZEsqikZnivtXvNh8pSW7nl/zUxERsY111JQHg=
=umDh
-END PGP SIGNATURE-

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

Re: Juju Actions - Use Cases

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-09-10 01:29 PM, Charles Butler wrote:
> There's nothing that says the hook cannot call config to make it 
> reproduce-able

But if it's a config variable, then config-changed needs to be able to
handle changes to it.  If config-changed can handle it, then you don't
need an action.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUEI0+AAoJEK84cMOcf+9hVIsH/0sFpC4hpnTEFMBfi20tMqaI
JUgvhIUIczzb3tq8wYWhzJ4ivmiSWZPCP1VBrfjSOPIu01KjqHlnp64AGLP0xuXD
tchUws3xhQxNkh8kP68aUMUUa2SWNwlPsb5HIvYmzztHvcd7nZ0oY51tU3K4vmNa
US36fxbt9brNeNyf9rma8o0ftXsuuZ+6zVzVW03nmTxTikgInvr0jC5QegL+LKY+
HxDbpAvplha/RNgGXq2aRq0QMsmD7ea57n323ayQRs3dKqTCxxQ94dvGmLzYwEUG
Ff2fhQoqO23EQNcYR643Ndi53AdyiHsWRgMxIoWeA+qSKkBjjBheeGUKStiDdEg=
=8TV7
-END PGP SIGNATURE-

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

Re: Juju Actions - Use Cases

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-09-10 02:56 AM, Charles Butler wrote:
> o as an interesting aside, we are kind of brute forcing this with 
> config... which it really appears that an action would be better 
> suited to this task for things like, say, CI

We would never use actions for this.  We want our sites to be
reproducible, so we want the revision to be specified in the config.
This would be especially true if we were using multiple units.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUEHVOAAoJEK84cMOcf+9h5ekH/juAFKg9G2JbySBqCMq0Gtzx
GIOEN1rNa/LDWNqmwicYrudnCg/GPiiUmVAXxDqdpq0gidvO6TJBLU4XwUwFDxP6
gY5aWMmCunbknxtIaEEPnqCpJWaywZ1i17sS8qjk3q0v5cE8dU8My/zAfBFHU/Zk
o66I+4fjxjiwIAlJJj3lQjmQOOUtgnAQR0EkT0AaO1wknjuH+dnVmhUNtxHzzBcb
AcO/EcfCg2TguwONaC6GNLjs+fgwYc+WIE9KtaTkKbdCPPd29aWm1kF5CQDoY7UE
WqlJb7lu6AlDWPfRzdkyN8OR7odHnJcIj83PkBwoRNqClIFxARHfJprN8xNiD+8=
=blKd
-END PGP SIGNATURE-

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

Juju stable 1.20.7 is released.

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

juju-core 1.20.7

A new stable release of Juju, juju-core 1.20.7, is now available.
This release replaces 1.20.6.

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

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


Noteworthy

This release contains various bug fixes.


Resolved issues
* --keep-broken bootstrap option to keep failed environments
  Lp 1362923

* LXC was not created, no errors, no logs -> pending state.
  Lp 1354027

* Juju status still returns private IP in 'public-ip' field
  Lp 1364419

Finally

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUCNcWAAoJEK84cMOcf+9hOEcH/0cH7b8M8/3AdEsA+BJLVjIf
IfWUNjeeIPaENBgj8ItsOU0c9fWcUMKI3V1uaziYNvr5R2lsm2ENicfoBKNw6yZQ
6Jc+T/7JG9UEopxjcmm6QdXgN5acfIrYctiFJMaFj9wyUtSMvAGsgDMe7T2q6Jkp
g90QyPHtt5bP8w1zN26U7C6bhsTG8P6Qg5NGSX/XX+Co+Z/z/yDKoxNrMOQ6PkVG
IRcj6vqUowDt5DAFhY+bzvAB3IDQDVushotynEx1vv40ET9jy9TjtQuisqY32doa
PbsPUJemfCn1yGGxgPC3V8G0M7zPd67WgySZDzDR2VWNIdUNP9gAMOPOfM3dytw=
=Kkd7
-END PGP SIGNATURE-

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

Juju stable 1.20.6 is released.

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

juju-core 1.20.6

A new stable release of Juju, juju-core 1.20.6, is now available.
This release replaces 1.20.5.

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

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

Noteworthy

This releases addresses stability issues, particularly with LXC.

Resolved issues

* arguments no longer passed to plugins if you don't have an
  environment set
  Lp 1359170

* ERROR Nonce already used
  Lp 1190986

* Juju status returns private IP in 'public-ip' field.
  Lp 1348287

* juju status  nil pointer reference.
  Lp 1357482

* lxc containers created, juju can't seen or communicate with them
  Lp 1357552

* cannot get tools from machine for lxc container
  Lp 1359800

* Tools download can fail and is not always retried
  Lp 1360994

* Containers not starting on machine
  Lp 1362360

* Update the add machine api to accept both environment name and UUID
  Lp 1360063

Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUAMh2AAoJEK84cMOcf+9h1sEH/A8jCI1SX7ZIDOY0orw9QXc2
E9L9pvazW4AhMgLHXrSPsF9xGWJFfbOupwKxYK3ItDAQgjRQlxTTgAr1PdeRIzIG
4ZpjbsyXrzOZHN6M7FFlhBL3A2lz1MN2mL6a5PqwK4yQ0HeDgbNAghEn1fEd/OyM
z8nWkfmrSbTFrKInk6B2EQSBAM5vBwS6JaS3A0lw8tgrnCLtUDChvq/x7LG2Hqls
iAWhHztgXv3XvytMN4wCjLVSrcM4pvzGtfOZ9q5iPmf2s+2h9p7KhQIpdZriPHN7
fg/UYqHJV3ai+gfSmmeUF7Zlr/vOsRnIIDU/od59jtF79JAX5TmulMRUdF3m400=
=nZdE
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-20 10:50 AM, Nate Finch wrote:
> If the special hook file is called "default-hook", it makes those
> single-script charms seem like less of a hack than if the single
> file is called "missing-hook".  It would also makes more sense to a
> new charm author, I think.

The idea of a hook called missing-hook makes me think of that painting
of a pipe with the words "Ceci n'est pas une pipe."  How can it be a
hook if it's missing?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT9MXCAAoJEK84cMOcf+9h72AIAJb6AqCFmulhTQb+EXqYFrwY
iu+3BeBaDR5EleRSSddOCXIRCEntpj3DPUZnrajEFoBwX7vm0y9eUKzT1PXKO5n1
1FJ6CLjFhFqY5iiyF0jS0DPmTyiRU3ZWIOLLAcY6Qzjb2JFwB/ipcoarS27xGrcP
AABdgJzcUp6vxm6bh2PSgHlr8ZHGz3UaVbZjUXWbWSmKHTDdoohBc6AUiRvYpsxC
TRJMG2N3lYX0OS2IRh6dp274rH4oIjQv+MNpWdBPmz15VUadJ97NB/L3aGuzce4V
I6sMhi6vE/iI+pQDcZ6LjFuRW8hZuxfR85S/jN9rRA5+zRYR9XIlmQ7Td8P3fYY=
=H+bZ
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 14-08-19 12:46 PM, Gustavo Niemeyer wrote:
> On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley 
>  wrote:
>> True.  At that point, the pattern is not a win, but it's not much
>> of a loss.  Changing the web site relation is extremely uncommon,
>> but operations which do require server restarts are quite common.
>> So making an exception for the web site relation can be seen as
>> a micro-optimization.
> 
> Restarting a process and killing all on-going activity is a big
> deal more often than not, for realistic services.

Sure, if we *were* to optimize this, we'd want to restart only on
certain kinds of changes.  But I'd argue that it's better to optimize
that in the application domain than based on hook names.

For example, changing the cron interval does not require restarting
the web server, but changing the http port does.  Both use the same
hook, config-changed.

Instead of restarting the web server unconditionally, we could restart
it when the contents of its config file change.  That would avoid a
restart when cron interval changes, and also when
webserver-relation-changed fires.

So I think it's a bigger win to focus on the application domain and
ignore the hook names.

> The point I was trying to convey is not that you can merge or
> ignore certain events. The system was designed so that this was
> possible in the first place. The point is rather that the existing
> event system is convenient and people rely on it, so I don't buy
> that a "something-changed" hook is what most people want at this
> point.

Fair enough.  More evidence would be needed to determine whether I'm
an outlier.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r
0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu
kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR
fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc
mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi
X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE=
=bqp0
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-19 11:41 AM, Gustavo Niemeyer wrote:
> On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley 
>  wrote:

> At the same time, the strictness of redoing everything all the time
> is not necessary, and a good example is still that 
> website-relation-changed hook for instance. There is not, in fact,
> a need to rebuild your whole confguration, including stopping and 
> starting the service, because somebody wants to know what is your 
> address after joining that relation.

True.  At that point, the pattern is not a win, but it's not much of a
loss.  Changing the web site relation is extremely uncommon, but
operations which do require server restarts are quite common.  So
making an exception for the web site relation can be seen as a
micro-optimization.

>> True, I didn't call out the exceptions for the charmworld charm.
>> For completeness, the exceptions in charmworld are:
> 
> Yeah, it definitely depends on knowing the events still.

On the other hand, it doesn't depend on knowing the events for
database relation, search engine relation and configuration changes.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT83cIAAoJEK84cMOcf+9hyu0H/Rr2Qz9hPo+EYuhbhuZH1y4i
yvoR389RepwA493v10EyfS/LX7Yoj4rk1fv0mnv//KdSV4TV8seIbc/ZyOoyDlqq
jFZLKQwV8wX9o4tz0fqi99hsxAZRIs6SoB8lSQtDLaGypkxgdCA2Liz4uL+g//Ge
L/AP874la/Du5G/XfQScoZjuPwIWPkkNDq8j5DWqe5qxmD9dxGSePEP+KjXpk0Hl
ZGiaSOPX/YHY4J/Lov/rjrh334myOudyyjRafy+iBgAz+7Z8fpdkZ8Yl3pFrx4vR
jTecJNkl0D1K6Hb/JXiPndKpvG7c/ZmBTb4D58W0yYCYSFpCuhjXCToOOMhOZLw=
=Knf7
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-19 11:41 AM, William Reade wrote:
> On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley 
> mailto:aaron.bent...@canonical.com>>
> wrote:
> 
> reverseproxy-relation-joined start stop
> 
> 
> (out of interest, if started/stopped state were communicated to you
> any other way, would you still need these?)

I don't think we'd need it.  We would want charm proof updated suitably.

In fact, I think we're not properly respecting stop/start as it
stands; config-changed just starts if all resources are ready and
stops when they're not.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT83LbAAoJEK84cMOcf+9hLPwH/AyxUbvkDhnC9thVN9bhDr4F
O5plYoOHb+yU3EC9h+V2EED7hm4oRaLw44JIssEkfQK6/MDYDIfBIZTwy7kK+ZNA
DjJ35L/ELPVFLEEyU20FXpe3dJoP/cdDHn5G6KnALG4hPB39eG0VmUVmn7r/lNMh
Zk1jA89K0liscdsdm7m8Fvn5/suq2u6j7s/9GJhv253R6Eb642whNHufMsBqyaGd
uXSpHioLjV1po4JFPOSYbE6cfvbSlXHERE5ZxuBcMh3LKfbbQeV5YyHi6UhfStp8
JINIlDzhDc3XTyNI8RDp2YR0FvekoStaE6egxQIU1GtFLwSQGqPfGAbRh2wUFQk=
=Q0pF
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-19 10:36 AM, Gustavo Niemeyer wrote:
> On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley 
>  wrote:
>> On 14-08-19 09:42 AM, Gustavo Niemeyer wrote:
>>> I have never seen myself a single charm that completely
>>> ignores all the action cues to simply re-read the whole state
>>> from the ground up,
>> 
>> The cs:~juju-qa/precise/juju-reports charm follows this general 
>> pattern, but there are some specialized hooks: install, start,
>> stop and upgrade-charm.
>> 
>> config-changed, database-relation-broken,
>> database-relation-changed, database-relation-departed, and
>> website-relation-changed are all the same code and read the state
>> afresh every time without reference to the script name.
> 
> This is actually your website-relation-changed hook:
> 
> http://paste.ubuntu.com/8089398/

No, it's not:
http://manage.jujucharms.com/~juju-qa/precise/juju-reports/hooks/website-relation-changed

>> The charmworld charm is similar.
> 
> This is reverseproxy-relation-joined there:
> 
> http://paste.ubuntu.com/8089386/

True, I didn't call out the exceptions for the charmworld charm.  For
completeness, the exceptions in charmworld are:
install
nrpe-external-master-relation-changed
restart
reverseproxy-relation-joined
start
stop
upgrade-charm
website-relation-changed

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT82ZEAAoJEK84cMOcf+9hGOMH/iwSH3CIuMXWFwba7eAkfF6l
jh8Bn7/XhAcIeESAdOjSOeEkWV3+1YA33J+2b7hThWlnWKMMtpfAfzlKEbB3h4VN
sLfK3OHQtH23pfMVU4UZ6K55PbrhGxkUXJTDFJaqSm9vqFqQr+Z226QlkQGfDmVK
EyzVY813j60T9dE1Mn0EQvyLDOwuASIw1fNQwoGI3PhsBau8LkmwikXjOxEzn6hy
L9TFRD/w5OPByLjAWo9Ti+wEWH9/z/W3y0bYOkZRShwS9HyfeztzQz6X34v6kQhW
SO+D6tlkwzx46UxfIBuhsqS1xF64eu7P5yx42cCiAPfWdOuX/BFALvtxYZKEAQw=
=tBSZ
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-19 09:42 AM, Gustavo Niemeyer wrote:
> I have never seen myself a single charm that completely ignores
> all the action cues to simply re-read the whole state from the
> ground up,

The cs:~juju-qa/precise/juju-reports charm follows this general
pattern, but there are some specialized hooks: install, start, stop
and upgrade-charm.

config-changed, database-relation-broken, database-relation-changed,
database-relation-departed, and website-relation-changed are all the
same code and read the state afresh every time without reference to
the script name.

The charmworld charm is similar.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT81hrAAoJEK84cMOcf+9h8xkH/3wBuryErE0RV6TAnOY4Oi+A
3Oxxt0G0t8oVJEw8VkxV36UyzkOkBtfrcSE0GovVBocDMem2qiQcFPb6mc1N++Q2
tpQedW1bKBvH6iyA8lO/R/h/4ug/ubKFpuHROhfET4qFN2XDr7PYimEycHFD/Wbg
k78P3YufZEezicnAYyzgMuALMP6K90zAXUG/I3+OvO3fcL1/QfwL9H0QflH8llzv
6LTVtkVX9RyJunLOV6P8SfxjKlttqE88j30F9DrXLTqb8fRsh4qet16/Yj4ib/Vl
dnDW8468wt8HOqDIcV6lTIEKbsSEalsDFNHD5cdzUSBj65W01qwLSCwo/eC5uDc=
=D2ZN
-END PGP SIGNATURE-

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

Re: Juju stable 1.20.5 is released.

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Woo-hoo!  Looking forward to these stability improvements.

Aaron

On 14-08-18 04:09 PM, Curtis Hovey-Canonical wrote:
> juju-core 1.20.5
> 
> A new stable release of Juju, juju-core 1.20.5, is now available. 
> This release replaces 1.20.1.
> 
> 
> Getting Juju
> 
> juju-core 1.20.5 is available for utopic and backported to earlier 
> series in the following PPA:
> 
> https://launchpad.net/~juju/+archive/stable
> 
> 
> Noteworthy
> 
> This releases addresses stability and performance issues.
> 
> 
> Resolved issues
> 
> * Juju is stripping underscore from options Lp 1243827
> 
> * Juju api-endpoints cannot distinguish public and private
> addresses Lp 1311227
> 
> * API server inaccessible for roughly 5 seconds after bootstrap Lp
> 1351083
> 
> * Juju bootstrap in an existing environment destroys the
> environment Lp 1340893
> 
> * The jujud on state server panic misses transaction in queue Lp
> 1318366
> 
> * Juju machine agents suiciding Lp 1345014
> 
> * Juju state server database is overly large Lp 1344940
> 
> * Jujud rewrites /etc/init/juju-db.conf constantly Lp 1349969
> 
> * Juju writes to mongo without an actual change occurring Lp
> 1345832
> 
> * Talking to mongo can fail with "TCP i/o timeout" Lp 1307434
> 
> * Bootstrap fails if /usr/lib/juju/bin/mongod doesn't already
> exist Lp 1350700
> 
> * Support the new v4 signing format used by the new China region Lp
> 1319475
> 
> * Azure: secondary state servers do not load balance API server
> port Lp 1347371
> 
> * Network error causes tools download to fail Lp 1349989
> 
> * Maas provider: allow users to specify network bridge interface. 
> Lp 1337091
> 
> * ppc64 architecture miss match for MAAS ppc64el Lp 1349771
> 
> * MAAS provider uses dead instance address Lp 1353442
> 
> * Juju bootstrap fails if kvm-ok not in path Lp 1342747
> 
> * Juju-local needs new dep dbus -- specifically to work in lxc Lp
> 1343301
> 
> * LXC clonetemplate lock can be left stale Lp 1311668
> 
> * LXC deploys broken on precise Lp 1350011
> 
> * LXC template fails to stop Lp 1348386
> 
> * Distribution tarball has licensing problems that prevent 
> redistribution Lp 1341589
> 
> 
> Finally
> 
> We encourage everyone to subscribe the mailing list at 
> juju-...@lists.canonical.com, or join us on #juju-dev on freenode.
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT8l8XAAoJEK84cMOcf+9hMjQH/3XEsAzVIn3KNR7LxciywHi6
5kfOfsN9Axdp9f6RVy6Q5hig/86nUfANSzEun7lj81pkUJLymBSUXcdMNDb40Sib
vp4L0Qhy07kNcHUFfivxAeMeelqLXxAwsI5d4xgysDzoMDR2qz4noOUdURxbJ1RE
ErvZG3MoA2xL6Yip5oMMUUvbic/ttWjed7UfYdUBTPwADkLSts/b/70fruf2yyvi
NSo1jn/u8rhSmf4hrlMZkKCBaQNxSS6OHfMYqyMCBhzSoWM+8b5tJm1UlAqbiuzI
eIPtHMka/Ei1A05Yvx94qyl/bkxcohZEd1dFNEi49vEUU4pXWpjleA7MLwMgApk=
=5XcA
-END PGP SIGNATURE-

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

Re: First customer pain point pull request - default-hook

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-15 04:36 PM, Nate Finch wrote:
> There's new hook in town: default-hook.  If it exists and a hook
> gets called that doesn't have a corresponding hook file,
> default-hook gets called with the name of the original hook as its
> first argument (arg[1]).
> 
> That's it.

Nice!  Thank you.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD
TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G
7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC
5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih
C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ
AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls=
=5YwW
-END PGP SIGNATURE-

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

Re: Reproducing Jenkins

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-05 02:24 PM, Jorge Niedbalski wrote:
> I am working in to reproduce some of the CI Jenkins jobs on my
> local Jenkins installation, but sometimes is a bit hard to
> replicate the exact job configuration.
> 
> I am wondering if someone else is interested in to create a 
> versionable configuration of the jenkins installation, so we can
> just replicate the CI Jenkins environments locally pretty easy.
> 
> I have used the openstack-infra project: 
> http://ci.openstack.org/jenkins-job-builder/ before , which has
> the benefit to bind all the Jenkins parameters and job-dependencies
> on a YAML file, so is a matter of POST this file in the new
> Jenkins installation and the environment gets automatically
> replicated.

It sounds interesting.  We should investigate it further.

We have discussed providing the jenkins configuration as a subordinate
charm.  That might still be needed, since we have to install other
things.  Perhaps jjb could be used in that subordinate charm.

In the meantime, please ping me (abentley) on IRC if you need help
running our tests.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT4oC1AAoJEK84cMOcf+9htpYH/18tDJyRTRxovLs+uUamwJxL
k9po3+iMle6AllQXDnQx9EA1rF9Z6uw9p1BuhdBI5wC2DrNKTPDtIMynoe7rQRXO
42coGkQiOpv5vYCNYQApJxcPnKPKxMlp3i6QZQttD90CnCqFmOjuplrmH6kj7VW+
lITUOCjROMX1d4X7DUJ/5WFb3EEqd9f2LH/lyrTqkWT8cShZwz2ejU2dX1cJRzrS
At0eOd9d77dM/RCSO6t0bi0EXatHWFKEma+fRTxt2Pc+72FOlEcyDZLZOxpG98wN
WL1q44Qm9FrM09pQQNKiEZiVlNhx3tvviceak4jT9KuhY4l/YHFvmPXGJF1YHfc=
=XhSJ
-END PGP SIGNATURE-

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

Re: getting rid of all-machines.log

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-08-06 10:11 AM, Nate Finch wrote:
> all-machines.log seems both redundant and a ticking time bomb of
> disk space usage.  Do we really need it?  Can we drop it and maybe
> later schedule some time to use something like logstash that is
> both more featureful and is cross platform compatible (unlike
> rsyslog)?

all-machines.log is one of the files juju CI captures for failure
investigation.  If switching to something else, please ensure it is as
informative and all-machines.log and that you coordinate the switch
with us.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT4ntlAAoJEK84cMOcf+9hJsUIALsJSTPtPo0JmDqqiUb81DsO
/OVNobQLiW47yTLlp8aCPXJTH6tswK+vgMhSFbYPqcD2pVY4zZGgwSRapZbOi1x9
SFnNB50onMTej+QKOiOYbLlvy9MzZGNnV8e7KAFnkQ6rZ9r8twChf1IuBl57nWJV
oqmWnbVdVmkjvHCCrEmK2xNfG4Y18pP5sLYLbqN3GinNz+LhNLzuDczYjN2gHZBG
GptDTWui6P+yxdkL0UTKs2JvisQWHYD2zBG2A8dwhdK864bVA1HJig5ryBhbP+AX
RkY9bkE0NP4D6R+SecLMlROrAdZasJh5KGHKq5c6VCy6ZvnI2d0DtqZ/epAW9xU=
=py/M
-END PGP SIGNATURE-

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

Re: Charm store API proposal, new version

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-16 03:00 AM, roger peppe wrote:
> On 15 July 2014 21:07, Aaron Bentley 
> wrote: FWIW, it would be easy to provide a bulk endpoint for
> charm/bundle metadata in addition to the existing path-based
> calls.
> 
> We could define:
> 
> meta/$endpoint?id=$id0[&id=$id1...][$otherflags]
> 
> to be equivalent to the aggregation of the results from:
> 
> {$id0/meta/$endpoint$otherflags, $id1/meta/$endpoint$otherflags,
> ...}
> 
> for id0, id1, ... across all the ids from the original request.
> 
> The additional amount of code to implement this should not be
> great.

That would suit my use case just fine.

Rick said bulk access was eliminatated to "limit the
complexity of the api".  To me, having both bulk and non-bulk APIs for
meta operations is more complex than having just a bulk API.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxoQpAAoJEK84cMOcf+9h6qMH/0v7T1goyrGFDis19w2GW4wA
Ii8+Bzuynx4Nz6KO3pjOg2TSot4wrq8LN9rBcXbFEX9b11DLl6Shq2vIAH0gRm7X
2SH5D1hjo+D9LZuMbLl0mdbVsx6u7bnKhJmq7FT0DGDF8sMsrYIcMCOYOUfu0+ks
JFTJN+qbBl1D5ZVgIUevWFx3rUQxrkt44zwJeLhB389IcdPb0ysJKo7rCCLR9Iua
8DQtAHf45WYDf0zrae7208tF/PVKzVHPLcXqWg3FJOdRj+D5e3uGFaf5KYtEHIGI
BzGfjEBrXlWRlIxkoX+9jesupp0+GwnuAXZhX9aSRP7xfsOpdu+2dYXXmQrjF0w=
=Nvt7
-END PGP SIGNATURE-

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

Re: Charm store API proposal, new version

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-15 06:05 PM, Richard Harding wrote:
> On Tue, 15 Jul 2014, Aaron Bentley wrote:

> What we lack is your specific use cases as no one working on the
> spec is knowledgeable about how you're using the api.

I'm happy to participate in any discussions you may have, especially
about major changes like eliminating bulk access.

>> We need to provide the statistics that show adoption rates to
>> Mark Ramm and Mark Shuttleworth.  We cannot forsee exactly which
>> questions will be asked.  We need to be able to add new
>> statistics without friction, so we need our own copy of this
>> data.

> What specific metadata do you need?

We currently need only publication dates of all revisions, but we
cannot predict what we will need in the future, so we need to be able
to synchronize our own copy of the data (at least the data which is
available through the public API).

An API that only gave us access to publication dates would not be
acceptable.

> Given that data, when you get the latest version of a charm, you'd
> get a list of previously published versions to facilitate the
> upgrade/downgrade UI. It seems this would help you with the publish
> counts?

If the search is only listing previously published versions, without
providing their metadata, that doesn't help.  Given tip, we can
already predict previous versions.  If we know that tip is, e.g.
cs:precise/mysql-5, then we know that the previous versions are
cs:precise/mysql-4, cs:precise/mysql-3, etc.

> Most of the other data around revisions and bugs we'll do our best
> at, but will be sacrificed information so that users can publish a
> charm or bundle from any vcs. What other metadata should be make
> sure is addressed?

It wouldn't surprise me if we'll be asked to generate information
about charm owners and uploaders, but we have not been asked to
generate any statistics about this yet.  With our other stats, there
is particular interest about whether participants are members of
Canonical or external.

>> Search provides results for only the most recent revisions.  It
>> can stand in for step 1 & 2 of our algorithm, but in order to
>> implement 4 and 5 efficiently, we'd need to do multi-id queries.
> 
> With the previous rev metadata we're missing but also required by
> the juju-gui I think we can resolve this with the current api
> implementation. Let me know if there's more we need to address.
> 
> Thanks for reviewing the doc and providing feedback. We're very
> much hoping to build out a strong consistent api we can use for a
> long time going forward.

If you want an API that is somewhat future-proof, then I strongly
suggest supporting bulk operations.  We went down the path of
single-object operations with the Launchpad API and it was a big
mistake.  It's great for simple operations, but for sophisticated
operations it is slooow.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxoDlAAoJEK84cMOcf+9hmLIH/0PKoWbqM2pRsy+/SmKxeipD
0krB7Kf0LguODQ3HuBp42fzCcbIGua9H0xHyf+n16bC4xES2BSeSfvPb82KJJnXd
mKewd0QiBEFai3qkrvzDyVeJ/XrzWdPC5vvLsM2Nf2LH4hNywAqhiW86zY38i7Bc
AVvWAx3tV4+VFEJDVTXQfVuLWTIdoCbRpbszJP5LPN7ln5VjEsRMtAH9cAhUGZsx
AHFbi5km9orHpWXeUg632vvvaS/QDaZ3QsyXA6euP6QyRfFT3zFXToJusE6434Jk
NS4aHd8YBa21GDW6gwVmt7ULP+yQdMsCI27GxT/XpjQ1tamHJfgbS0ujOAQ0qys=
=hgLs
-END PGP SIGNATURE-

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

Re: Charm store API proposal, new version

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-15 11:43 AM, Richard Harding wrote:
> On Tue, 15 Jul 2014, Aaron Bentley wrote:
> 
>> On 14-07-15 10:17 AM, roger peppe wrote:
>>> The most significant change is that all endpoints refer just
>>> to a single charm or bundle, rather than being "bulk" calls as 
>>> they were before.
>> 
>> That sounds like the opposite of what juju-reports wants.  Does 
>> it really mean that we would need to make N requests to retrieve 
>> info on N charms?  What was the reason for changing this?
> 
> The change is because we went through the known clients and could 
> not come up with use cases where some client had a known list of 
> charm ids they wanted data for, but they knew those ids ahead of 
> time.

I am surprised that juju-reports was not considered a known client.  I
certainly made many comments on the first draft of the original proposal.

> Aaron, I'd like to see if we can get your full use case details
> and make sure we address them.

Our use case is we want to be able to synchronize public data from the
charm store into our DB.

We need to provide the statistics that show adoption rates to Mark
Ramm and Mark Shuttleworth.  We cannot forsee exactly which questions
will be asked.  We need to be able to add new statistics without
friction, so we need our own copy of this data.

One way to do this would be to have an API that accepts a timestamp
and returns the metadata for all charm and bundle revisions created on
or after that timestamp.

Right now we do this instead:
1. Retrieve a list of all charms from charmworld
2. Determine the tip revisions of all charms from the charm store
3. Determine which revisions exist but we haven't seen (including
non-tip revisions)
4. Determine the revision ids of all the new revisions
5. Use the revision-ids to determine the publication dates of all the
new revisions

Steps 2, 4, 5 use multiple-id queries.

Right now, we're showing number of charms published here:
http://reports.vapour.ws/scorecard

We'll need to do the same for bundles.

We've also been asked to display the number of running environments.

> You had requested an all charms/bundles api call in the last 
> revision of the doc and we're looking at addresssing that through 
> search results.

The doc doesn't say that search can be used to list all charms and
bundles.  If you meant it to be used that way, please say so in the
doc ;-)

Search provides results for only the most recent revisions.  It can
stand in for step 1 & 2 of our algorithm, but in order to implement 4
and 5 efficiently, we'd need to do multi-id queries.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxYnvAAoJEK84cMOcf+9hr04IAM9SwL4xZv0Dez33KiA8/SJf
ahApZSuiWfDKR5h2DSKuuW+ZgzMwHOJwtMUd+wmFu6s5W4+2rI5IU60EQBd2M+3u
JG2ZkK3C0qvibxnlDwY0gyy/atwdEnOf4X5/5sx/gI08ZtqnmpMpUohDMGMFHTHc
191i9ZZJVz/FvC+FxIzyd0p79veAZf1lvEWK2tDunX+H5VTwhGvfGnnjjraNxXTE
bzFNwIUV8uuRiIETGKDNBbgncdMfNW48bw76TB+sQoy4ElL3Nl9pnA4o/i9zwzX/
HcvA6W3DlknLgfH6odHL+Ot70txt8v9DObRSMifGSlXMYHuox3gZT/bs4XRVRS4=
=GRZs
-END PGP SIGNATURE-

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

Re: Charm store API proposal, new version

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-15 10:17 AM, roger peppe wrote:
> The most significant change is that all endpoints refer just to a
> single charm or bundle, rather than being "bulk" calls as they were
> before.

That sounds like the opposite of what juju-reports wants.  Does it
really mean that we would need to make N requests to retrieve info on
N charms?  What was the reason for changing this?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxT04AAoJEK84cMOcf+9hTY4IALfbWrq6VydINsAzHha6Az1+
RhtpJpS74VBbnBSzFK3LgeHk1uLGLNa73VklKYqibKcSHe6TPUhfwpSldxHoSrXR
KGq86SdjojCnFXMxUw1QBXqd4QXv6h19znO89AwgDK8Crw14IB3ZrQvmfNbyZWex
WmJjlgtvcuImVLrzBntF1UQcHzzz5ycXI2nzzhVEGTlD+z2Eg+8SfSoagbMuZ6Zv
q4I0gNEJcktnoHoYGYvx98umN57td5nj9u9R79c500ZQz7kIE7f4y07Hy7MxK714
gEzoFo4rnbgZJBCdoI3FiH4BqxP5uzWoj2iAG9UiMlPN6nFZUsJnZKjjcvS+nvM=
=6gFz
-END PGP SIGNATURE-

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

Re: Devel is broken, we cannot release

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-14 11:48 PM, Ian Booth wrote:
>> 
>> * FAIL: managedstorage_test trusty ppc64 from 2014-06-30 which
>> had a secondary bug that broke compilation. 
>> https://bugs.launchpad.net/juju-core/+bug/1336089
>> 
> 
> This bug brings up another issue. The code concerned has now been
> moved off to a juju sub project - blobstorage. So the juju-core
> ppc64 tests will no longer fail.
> 
> Martin is in the process of setting up Jenkins landing jobs for all
> the sub projects (there are several). But there won't initially be
> ppc64 variants of these jobs.

Is there anything blocking ppc64 variants?  We already have a ppc64
slave set up.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxSpFAAoJEK84cMOcf+9h2C8IAJdD+SOYJxQKwDv/6iKZjA3v
Q98S7Z76PIt0J5Q++eVUwK8uMWGa9XCtM6Ou36rjyjA8KsEpn52Vwg40LGPfOFp5
AVs7gzGCHNAlhNMMIxdSXxxL0cNKBs1bW7CsjjZ7vjzmVUwnlhF9j340EB0d1tS0
Jq87y+8FdD2yfYqZnQ0o8Ls2yLEGmfRGe3Jb2P4//9RrR+kOZNWYxZtfg+xzMr20
05NSXI2DAU1LgB0IuTcy9ri4Pv9ACuebmPZEuWK5nLRofjRyy0vG4fsdJ1DMji68
lhiwwLVBXnTyKSL2U4z7iKE2kXna230iW5ReUBewyN5JZZBozsHVfpQ6nO48mEA=
=NLEv
-END PGP SIGNATURE-

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

Re: Devel is broken, we cannot release

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-14 11:42 PM, David Cheney wrote:
> Who is 'we' ?
> 
> Is some automated process going to manage this moratorium ? Do we 
> switch off the bot, or perturb it's access ?

No, we don't want to switch off the bot, we want to limit the kinds of
branches it will accept while a regression is present.  One possible
implementation is that the bot queries Launchpad for open regressions
before attempting to land each branch.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxSlTAAoJEK84cMOcf+9hdSsIAMFANcgc0PIvbg53LMt+dYR2
W2ADjNwoBab45SAWoOTIJ5pKVWaFc66AGsgwDpITs5F+6U1htLaJLCl2IU8vARMO
pzYw1bqpYuwsPShgWiK1zZLOkrv7pkUQu81K3ohLiAPEaNg+zPFhWCqPeiC1zb9O
AHR8TCm9+hsRS+95rRt/PfE0FunHjFwG0siWFuY4rNd+pFkouhxaMZ19SJgaQU6j
vMVhdZLc1wk2ellb+AU5zus4qI/OFvmeVVehFBsY1zgcbB8Brd4/zwZg/pt7h5af
hfpYnbF00sykwh+c4B1Kve6y1hH8eUigxJ+JgV+zViGQfIlleSHGubjhLLXDat8=
=5oMZ
-END PGP SIGNATURE-

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

Re: Devel is broken, we cannot release

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-14 11:38 PM, Ian Booth wrote:
>> I propose a change in policy. When a there is a regression in CI,
>> no new branches can be merged except those that link to the
>> blocking bug. This will encourage engineers to fix the
>> regression. One way to fix the regression is to identify and
>> revert the commit that broken CI.
>> 
> 
> Agree in principal. However, we have seen some issues on CI whereby
> the unreliability of the underlying cloud has caused failures. So
> long as the issue identified indeed has a root cause that we can
> fix in juju itself, then we should block landings to trunk until it
> is fixed.

It's true that CI cries wolf, but Curtis is talking about bugs that CI
found, Curtis confirmed and determined were regressions.  I don't
think we need to worry about cloud glitches there.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxSiaAAoJEK84cMOcf+9hT4wH/ipEUlTpjVApsF9y1qzglsUY
VaDn6AHsZKDLwX9zEMYdWIoN1CFU0KQrngN5D5/S2FAxZ+C8/Z+B17nRffSSB25r
LNEH9XOdZz9qaTZV5kz3kR3jYgUkvHe0QAHMRLnU+qOBzQjhsy4sWkHp17862pjz
QnIIRpvkd4P2tgnCEFslhQuMCPCbcx26cUkkzKDN8qEj346aP2Mj7Gf0yAdi8jTB
G2JXa1XKa251NIWHGonJa8jMpKrq7FJWF31QDuYFmjseUV0HMZn49pavVBL/NLh4
krfOJTk2Fr8Pu4aX9ofniPRF1KzwLEvRKH+jkTWK4H5yl2ZuUgR/CaGL6Zt/Tas=
=fxgZ
-END PGP SIGNATURE-

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

Fwd: [Canonical-juju-qa] Cursed: #1583 gitbranch:master:github.com/juju/juju fa76c995 (build-revision)

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It appears that either fa76c995 or d668b6e0 broke the build, and my
money's on fa76c995 because it's about extracting state/txn.

Aaron


-  Original Message 
Subject: [Canonical-juju-qa] Cursed: #1583
gitbranch:master:github.com/juju/juju fa76c995 (build-revision)
Date: Fri, 11 Jul 2014 17:36:20 + (UTC)
From: CI & CD Jenkins 
To: canonical-juju...@lists.launchpad.net

Build: #1583 Revision: gitbranch:master:github.com/juju/juju fa76c995
Version: 1.21-alpha1

Failed tests
build-revision build #1583
http://juju-ci.vapour.ws:8080/job/build-revision/1583/console

- -- 
Mailing list: https://launchpad.net/~canonical-juju-qa
Post to : canonical-juju...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~canonical-juju-qa
More help   : https://help.launchpad.net/ListHelp


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTwCO2AAoJEK84cMOcf+9hIz8H/1Zwyj5jOMF+TUUIbT1Taw8s
s0wmjqBq0VDCRTv5kLchQG3iPDxNZJ6HNuFWW2v+3Tya2i1Xat6+lyfYN46gLlSx
LN2JTzadyZn1oJg4ZmS+JHTFTu9yiAGl0C+QvEJSNLF93Tqq6q/c+zuGOemCLAJa
eCh3rdaOP2KEUEGG0bzitq3kkEz+h+A1u2BizzokUTrE7yzdoDmC0Lx9QkpHHWrh
HHDJt9A/SivNRfGDAVN0BnYv+IEbhFley1TCazOaeaAJO3sLCq4Ls1OwSfBADdIg
qRXUu9y6OJ2tQ8z1cM837ze5CJYfrHD6HX+LiKagsxPh455Zcgzzyl6zB8rnjQ4=
=m2up
-END PGP SIGNATURE-

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

Re: Proposed new charm store API

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-07-09 11:16 AM, roger peppe wrote:
> If we need to provide backward compatibility, we could do that in a
> separate name space without changing the proposed API.

The existing charm-events endpoint requires a revision-id, so it will
not work when uploads are done directly instead of being ingested from
a VCS.  Similarly, the "digest" field of charm-info would not be possible.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTvV6RAAoJEK84cMOcf+9h0D0H/A6zOWDlWqZ1Zq4EMfdYODhV
dOMC8f23MEGile29hA48J2ElIA6s2YmHnlt+t7H1N8xyoMnKbejMoGE/8v7FMRTk
QaGBlr6XlLX/TWxyDpzjlW4oZQ5oUSsF+ofVRsoXfsfz0Id67uaNpOW/mPdwNI1h
YQfaXWdZ4NE1rdNLT3IwDU/QRX+gUbe3ZsdhbuJIaM5dF2Wxqx5f+Zq7+nKEu18H
yq76iL+WmAiUNnLJdIbqlSUTfI10HAJJQQLveruj04dd5wy/cpXmvIaK3vwrRS7U
W+kto1/7rYTkqMhVeXKfpogXfORSWmBAVAHkHClzEa8ujUAoSFXCN+rYKfKGYjA=
=Y3AZ
-END PGP SIGNATURE-

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

Re: Proposed new charm store API

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I haven't gotten a response on this.  juju-reports needs to generate
statistics across all charms, like the "published charm revisions"
shown here: http://reports.vapour.ws/scorecard

How will it get data on all revisions of all charms?
stats/counter/archive-upload:*?list=1&by=week ?

Aaron

On 14-07-07 11:04 AM, Aaron Bentley wrote:
> Thanks.  One thing juju-reports needs is a list of all the charms.
> I think the API spec doesn't include that.
> 
> Aaron
> 
> On 14-07-07 05:14 AM, roger peppe wrote:
>> Francesco Banconi and I have produced a possible specification
>> for the new charm store API, combining features from the existing
>> charm store API and the charmworld API.
> 
>> Please take a look and see if it correlates reasonably with your 
>> own needs.
> 
>> https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc
>
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTvG1uAAoJEK84cMOcf+9ho9IH/jj80t/tMzRvcnsBiFhaFIFH
doOiaZ5EKmNRl/quDRVetKctgwarElsaoCbRB5jMIoeAIEMT4+IQH0PcnThYYqlc
jOCSooph5AKR15sx3cl0Q6NgOGtu+D03/fjPH3PgHBnMNq+aaRJEkRXn4oo2QWWR
lVoJvmw3DYfcP3N42jkzD7dzmdxPrNl+Nmwu9kd8wAcRB1gvl0VQ+unfUQd1xV2N
sfSgqyBS0lm6Wzya9dQM9QtMEtDkPFY+gBXHfs9sz4DcJ5PfHcwEkoDEqbpGhKzY
BEtRQst+8LZkMAqUW2HiUaVFJ33JEPJ7yuyW/GMt5D6GHAmlXBXD/d+zM+KZzP0=
=0Ds7
-END PGP SIGNATURE-

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

Re: Proposed new charm store API

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks.  One thing juju-reports needs is a list of all the charms.  I
think the API spec doesn't include that.

Aaron

On 14-07-07 05:14 AM, roger peppe wrote:
> Francesco Banconi and I have produced a possible specification for
> the new charm store API, combining features from the existing charm
> store API and the charmworld API.
> 
> Please take a look and see if it correlates reasonably with your
> own needs.
> 
> https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTurcZAAoJEK84cMOcf+9hJSgIAMn7PRLNHrAkDn8iR7bMxDIL
4Vme0NWcDx3WuBJE02WjMhhCI+i1yXdx+C+IpgEkJygOKMdDXMlfZbPGsbci1Plx
qQArdXlk5pA2Qs4b/ctHUyN8Fzl/ZHj4/KhSdhukosVn0JVi9MWgJpsxIJR18mtq
Ve5vtFTw5eDTiUqoZLVP8T/LoG+cKWehNmgxai9OINAiztuEPU3QgGbHO7b5nMVY
I8aI0DoVdA1eqyIPFrm/D4Re37LIdGNLDFavUWXmaQuhaqaSwFrFb8zTsb6OBljc
oLUCd8Uy2U++4864bdzqF/jx/yAdbXqTMhMlNOEHIbdNMjaPkaUBYL1lPcedfMs=
=XnK9
-END PGP SIGNATURE-

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

Re: Possible CI affecting change

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-05-27 02:55 AM, John Meinel wrote:
> I just proposed this branch: 
> http://code.launchpad.net/~jameinel/juju-core/login-returns-env-tag/+merge/221021
>
>  This will make it so that we end up caching the environment UUID
> into our ENV.jenv file, and passing it up when we try to connect,
> and having it validated to match the running environment.
> 
> I believe CI uses some infrastructure to avoid having Juju
> automatically generate a bunch of the fields in .jenv files (CACert
> and control-bucket come to mind). Environment UUID is going to be
> one of those things that gets generated during bootstrap (it always
> has been uniquely generated, we just never actually tracked it
> before).

Thanks for the heads-up.  I don't think this will be a problem for us.

Basically, we're taking the cloud-city environments.yaml and writing a
temporary copy, with a few values (agent-version, bootstrap-host)
updated at runtime.

When .jenvs were introduced, we started copying everything from the
.jenv into the environments.yaml, but now we just pass .jenvs around.
 We try to keep our environments.yaml minimal now, so we no longer
have ca-cert, and we keep admin-secret + control-bucket only for
Canonistack, where their removal may have broken our accounts.


> Some of this is moving us toward multi-environment state servers,
> where we can tell what environment you want access to from your
> Login request. And some of this is a general desire that we've had
> that when you run a command you know that you're actually
> connecting to the environment you thought you were. And the
> official descriptor for an environment is its internal UUID.

+1

> However, this would mean that if you bootstrap, and have a .jenv
> file, then someone out-of-band destroys that environment and
> bootstraps it again, you'll now refuse to operate with this new
> environment that no longer matches the old one.

That is already true (due to certs and other values), and we would be
upset with anyone who re-bootstrapped without sharing the resulting .jenv.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThJL2AAoJEK84cMOcf+9h+eMH/3EEEq/hbO4Sgzdk30tV7l9+
OmzDFFc7J/PHuA296Z9qwRmGOTTLirk94V0gA0gVVy8SbLs680y94pv1HtK9S5Oq
OqJt9D6ruJVhLlDLnOUplHtr4e90X5rWQXeENntsUEYTiOnUZTfOuPOrz0vupBUd
sI9wXILoHVdqeU7P3wFdT+7sNoxELwpAkjU2gm/V3Oy68/QePl+D2y2xC+xfhOWc
gYXDtV2V0447Vy4A7mtFu5WWipJ316F+nwmQ9z9D41TMOPwq2im9ZVzVmgtiVF6N
18VgicrkPdJRnt4yOMX0uy9P0I4UBBW/0KQbM5RDClwxdINm1HXM2SrFm5kLwRk=
=wJTk
-END PGP SIGNATURE-

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

Re: Heads up: migrating juju-core to github

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-05-26 06:23 AM, Ian Booth wrote:
> Most impacted will be the CI guys who also package the Juju 
> releases. Curtis, will you be able to accommodate the timing of 
> this change?

Curtis is out today (US holiday), and I can't really say whether we'll
be ready.  The main issue I see is that bits of our scripts depend on
revno (not revision-id) and there's no equivalent in git.

It would be helpful if we could test our work against actual git
repos.  Do you have any that we could use, or should we convert our own?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTg1HRAAoJEK84cMOcf+9hlX0H/At3PH76sT18W4aVWrQVJ8N3
4wzcpock5YuQRsSHoVkwe5xhFQVY4ZEGBaRgwEtHovDc7TAxD7FWZtCpKUaFRoLA
WG61OEp4vAn7or0vuRLFZe4uaHP3+gkt4THdDS/r5mRT8d9ooU378rCmCSLnBeOm
Hm23OjFF0rOUfSAWlXMVCnLKVrgDs1v6kqWj5mLyvg8F7WysCJyAJ8hPUqdOX8K/
OSzG2mFYHV2k1gqVM0bW1VsXyG87FMmgOmdWLU+htCeTRl4+yC/A3oqaLa5uPomM
t63kWXoaqu54TJ80H7iuwnaslGg29BfGKjpghgGjUhpOR3Adcr31vNcVbvp5vKk=
=A0KF
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-18 11:53 AM, Kapil Thangavelu wrote:
> I think that users should upgrade their clients in order to get
> bug fixes.  I think that users who don't upgrade their client are 
> expecting to get a lock-down experience, bugs and all.
> 
> 
>> And how does that work with multi-user environments? Divergence
>> is inevitable.

>> For stable versions we should be compatible across micro releases
>> and testing the same, --version still seems good for users who
>> want exact behavior/reproduction.

You make a good point, and we are going to look into testing across
micro-releases.  That said, I don't know whether we should expect a
lot of diversity or a little.  People who upgrade frequently and
organizations that use Landscape to manage upgrades may not see much
diversity.

Aaron

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTVYH3AAoJEK84cMOcf+9h2fIIALlfa2jL/aQtI9cCsLuQblwK
akzhaN+hlnaVfWNcvuVW6tB84CP23H9hNK259g+wJYgL+j0BAzisZMFrUvb4revg
QQpLhUHHCkGxBCGBir8mhDq+NPGPHdgR+S58CJDcKhF3w5hRBSrhSc+2gHighr1S
NaoqdO/KBo7nOqm1zjsOBXnoPdaEPPnXUbi7PC5sAGQB5hJY1JlyIG06x1JkahcU
Rhujug8Chvqd6BACvNsOm44l0xoAwD+wOh9HsemNjY/eMcn+RRxJTt91M6J08xvT
8MBQP9x18cYyq+js/Re4DD5cUmdw5TaUjloiYczlI7b8hiSmMfO+xTwyXotu9mc=
=Qsul
-END PGP SIGNATURE-

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

Re: lp:juju-core/trunk r2644 broke 1.19.1

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-18 02:04 PM, John Meinel wrote:
> I did eventually manage to run the CI tests, though there are some
> oddities:

Sorry about that.  The top-level 'upgrade-job' and 'deploy-job'
scripts were never meant to run locally.  Originally, we entered these
commands as configuration parameters in Jenkins, and then we extracted
them to scripts to ensure they were consistent across different
substrates and different Jenkins deploys.

But please try the deploy_stack.py script.  It is much more
user-friendly.  It takes options and arguments, not env variables.

> 2) You have to set LOCAL_JENKINS_URL to the ec2 instance

That was because on Canonistack, instances can't access their own
public IP addresses.  We might be able to get rid of that now that
we're on EC2, but we'd still need JENKINS_URL.

> 3) You have to set WORKSPACE, but you *also* have to have $PWD
> already be in WORKSPACE.

Per Jenkins.

> 4) If you made a mistake with $PWD it also has the nice properties
> of rm * -rf, which wipes out wherever you were running it.

Unfortunately, Jenkins doesn't have the option of starting with a
clean workspace.

> 5) Even though I've set JUJU_HOME to $HOME/dev/juju-ci/cloud-city,
> the first thing it does is override JUJU_HOME with $HOME/cloud-city
> (or for manual source $HOME/cloud-city/ec2rc.)

Sure.  This is needed on Jenkins, and we do it here so we don't have
to do it in every job configuration.  I think it would be fine to
change it to only override JUJU_HOME if unset.

> 7) It uses a special SSH key which comes in cloud-city. But by
> default the file is rw-rw... which is too open for SSH to let you
> use the key.

This is an unfortunate consequence of managing cloud-city with Bazaar,
which doesn't support full unix permissions.

> You can probably change the environments.yaml to a) not include a
> key, or b) include your own key, or c) ssh-add the existing SSH key
> from cloud-city.

Really, cloud-city is only if you need to use our credentials.  If
you're not trying to use our credentials, then you wouldn't need it.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUoXHAAoJEK84cMOcf+9hXfUH/AqS5BMgvDcMEPp/JWJI0KTD
kgsNCpaH0LtDEyyE8kbz0c167EOzauKpw31+YKbBEeORElbMbnsiycnx0HMTso1B
hzSVjeamK7S1woST87c0eLg+mJLW0ufQoFWnWsZ9TrAEpFYl8bOCn51viiPM7WF2
1sRJ09WgoJQZmxKTsQA8BE3XwWfwokoWhSkzmLCESrzcYLpFJZz+Lc6i3JTl88/K
sZWS1jLiaZbPVfbksBwhYJW5w2xtuciK8lgru2iJ/y8Tp4NStDSOSTKomUf3Xusv
kCHLm+IM610nxydnN9hRkOiYEHDE7jTQ6FcHGk2unr71LPsyPR6J3YtJ9N2fNbU=
=DHBU
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-18 06:28 AM, William Reade wrote:
> As for automatically upgrading: it's clearly apparent that there's
> a compelling case for not *always* doing so. But the bulk of patch 
> releases *will* be server-side bug fixes, and it's not great if we 
> generally fail to deliver those to casual users.

I think that users should upgrade their clients in order to get bug
fixes.  I think that users who don't upgrade their client are
expecting to get a lock-down experience, bugs and all.

I don't think it's a good idea to default to deploying untested
software combinations, especially when using a tested software
combination will give a superior experience (i.e. client-side bug fixes).

Even though you don't intend to introduce incompatibilities with old
clients in patchlevel updates, we're human and mistakes happen.  CI
found lots of compatibility-breaking mistakes in the 1.17 series, and
I'm sure there were many more that were caught by code review and
juju-core's unit tests.

The way to be certain we don't introduce such incompatibilities is
testing with every patchlevel of the client, and that scales an
already-big workload linearly with the number of patchlevels.

There is value in using the latest patchlevel of the agent code.
There is risk in using untested client/agent combinations.  It is hard
to weigh one against the other, and I say we don't have to-- we can
get the value without introducing the risk by upgrading the client.

> I'm inclined to go with (1) a --version flag for bootstrap,
> accepting only major.minor >= client tools and (2) a --dry-run flag
> for upgrade-juju (with the caveat that you'd need to pass its
> result in as --version to the next command, because new tools
> *could* be published in the gap between the dry-run and the, uh,
> wet one). Aaron, even though this doesn't promote your use case to
> the default, I think this'll address your issues; confirm?

- --version would be an improvement, but we have a workaround, so it's
not /that/ important.  It's really the users I'm thinking of, the ones
who care about reproducibility.  I'd honestly rather have
- --bootstrap-host, because the lack of it is making our testing of the
manual provider a bit weird.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUUYPAAoJEK84cMOcf+9h1l8IAJTlK7+6bhoAGSmD0uVvFjmN
XjqO26yQcQT+YNBLK5cNt2L6/nFmUUjLg9B1XA/y4rX6zTGUKKk9Ge1iyrfWRXf7
ZQwWHgsMIKxTmVak9x12ack/0PQQ4/D8qoXcM5mVRDCyXJx+zVDnGSw7Cfq+5Td7
cL79xrJb9Eakhw4AUzDnW7MGMIlQQIFbkMpRoO5YBhSLN+DCf8mpXRapCKGVwxf6
oLBarulsDGuolE8641wz39vraYbOpVWZG6NVtK7hYSVjyF689rt1uitJD79ebDGc
zhoKNBdGQQbDceORfK9wxQcK5072XwzZpIQTaQAPioqJ7BJQ+SL7RWksZdraVTU=
=Fb/3
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 14-04-17 12:03 PM, John Meinel wrote:
> If you bootstrap, you are installing juju onto the remotel machine.
> The reason we created a *patched* version is to give you
> improvements (bug fixes, security fixes, etc).

Sure, but if the user doesn't upgrade the client, they're missing out
on a lot the improvements, anyhow.

> I honestly think it is good policy to give updated versions when we
> get a chance to do so. We aren't trying to cross Minor versions
> during bootstrap, and we intend that patch levels should be
> perfectly compatible.

Yes, intentions are fine.

But you can't prove that 1.18.1 and 1.18.6 are compatible, whereas I
*can* prove that 1.18.1 and 1.18.1 are compatible, because I've run
tests.  And I don't think it's worth the effort to test 1.18.6 with
all previous patchlevels of the client before we release it.

I think that certainty of compatibility is worth more than the
patchlevel improvements, because it is trivial to upgrade the client.
 That way you get both the patchlevel improvements and the certainty
of compatibility.

(And in environments where the juju client version is locked down, I
expect that they would want to lock down the agent version as well.)

> I do understand your point, and we can bring it up to wider debate
> in Las Vegas.

Do we really have to?  Isn't Mark Ramm's recommendation that we do it
my way enough?
https://bugs.launchpad.net/juju-core/+bug/1247232/comments/6

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUAdPAAoJEK84cMOcf+9hbGMH/2dRtCI5z/1OpApt2wFBJjMw
ZxhtqUW9ggeABDShkVWzLF3YKmOgCFDylyUFXEEBoZrdnv5NfTm23jnublPuA6oj
4f0uONhmfbD1TCZaXjrhQnbZunhzzE30XquJbaszz4tVt4mhXc5IfAWA7WbK+6Z7
YmjS6BWg4jjq3+dvpGtDNONYtggxAtgJQPdJBJzIY8O1h7OAjvuAC1Prrp1vDdYZ
fOL6vIGjvz1FOUpNwqSpNVTHcwzb7ujhnUk8zaQtg8Csi7WKB2g8tmWHWZ1YE+Yr
tCK7uONmKb3Xg7dgv973oVMxfRD6pgkuSUBo0GVVR1PsDfB4x8ENc2OKvBnQxEg=
=c1H0
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-17 11:48 AM, John Meinel wrote:
> FWIW that isn't what you get if you do "apt-get install foo"

That is fine *if* you do apt-get install foo.

But the user isn't doing apt-get install juju-core.  They're just
doing juju bootstrap.  They should expect to get exactly the same
thing they got yesterday when they ran juju bootstrap.

If the user wants to upgrade, that's great.  They know how to do that,
and from then on, bootstrap will select the latest-and-greatest agent.
 But don't take the choice to upgrade out of the user's hands.

> I don't have a problem with "juju bootstrap" growing a "--version" 
> target (same as apt-get install foo=1.2.3). But I think our policy
> of giving you the best version we've released that matches is
> reasonable.

Any version that hasn't been tested with the client is NOT the best
version.  We cannot support what we do not test.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTT/mQAAoJEK84cMOcf+9haPIH/2os5BBsmHzSk6bhilKC7h8E
XJqWUKPX1mpD49voAl5S2evA0nEi4yO8NtgrUCheHYO3QtlAF2Pn3oSJiypIK/M4
83dSlvVIeMyZWOx3qnQyPXJ3uBy94jiP+oLYMIRTKWulm82h8mBCLPKr1ffJCkvV
ZmKsemBCdVJICFJ8GksWSznigzLqCF0se6q9m9SBOLkFwAqjMFFMnfdKQIKr8bAh
G1UtYJSzUfHODMoQNNy0TcVVTCKq1LsjeS1rYmTvQD0CmsPxGd1T9KaMhuLq+275
WyedeZwItTSwnqmCDrUudFlzc8UxHiFbLiNckbZbdQ+nChGJwY982Z6ILQ/Mjrc=
=+1cM
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-17 08:40 AM, Andrew Wilkins wrote:
>> Okay. It's possible to do what you want too (see below), but I
>> don't think it's sensible to make that the default behaviour.

I think that using a tested combination of client and agent is the
most sensible default behaviour.  We test that client 1.18.0 is
compatible with agent 1.18.0.  We don't test that client 1.18.0 is
compatible with 1.18.1, 1.18.2, etc.  I don't think that's worth the
resources.

(We do, however, test to ensure that upgrades work when the client is
upgraded first.)

>> If you're bootstrapping 1.18.0 and you don't want the machine
>> agent to upgrade to the most recent patch level, you can override
>> that behaviour by adding this to environments.yaml:
> agent-version: 1.18.0
> 
>> Is that a reasonable solution?

I don't think that is reasonable.

It is the wrong default.  Users should be able to expect that juju
will always behave the same if they don't explicitly upgrade it.
Installing a different agent runs the risk of incompatibility or
changes in behaviour.  The default should be a consistent experience.

It is the wrong configuration method.  bootstrap should support a
- --version, like juju-upgrade.  In order to specify agent-version, we
would have to rewrite environments.yaml every time our desired version
changed.  Since we test both the stable and devel series our target
version changes frequently.  We could potentially rewrite it for every
test run.  We might lose the comments or formatting in the process of
rewriting.  Constantly rewriting environments.yaml is risky and gross.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTT9cgAAoJEK84cMOcf+9hRm8H/1l7g+L8ZPWkbXrBEzyvEm52
cL6CBPz3cYqVzbK1YrihyuiqrVYeJy4Dh4sPJX1dRtpOx0aZHOFx8C/sV7QDx2M0
EEJyvTRfNGLvq6+rpmEYj5cH0jWjove2a0bTky/dDd/7hFRZWXIeMZLtazQTmnZq
KkLp+60/pQ5Zxo1ojRrtf4mSxEDC+FBst6m+iwvayllOsC62ViPQehPDEApxUMCI
HFRv45ROSpZM+MprjZJOVla3wUajlbNYGHtkfAU45kZsP7Lfm/U5Zbj1wuqVdlGe
JP7gHwKbCBRIakRsxxIyg9theIpqjhZaeYQ99TNYO0dR/INKNXAQzzDFP9Trvm8=
=itpS
-END PGP SIGNATURE-

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

Re: What happened to pinned bootstrap

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-17 06:34 AM, Andrew Wilkins wrote:
>> Bootstrap will continue to set agent-version to the most recent
>> matching major.minor, so the machine agent will immediately
>> upgrade to that when it comes online.

I don't understand this-- I don't know what the impact of setting
"agent-version" is.

It sounds like you're talking about automatic upgrades.  We do not
want automatic upgrades.  We want to deploy a tested configuration
(i.e. one where agent version matches client version), and keep that
configuration until we explicitly upgrade to another tested configuration.

For example, if I bootstrap with client 1.18.0 and it deploys agent
1.18.0 on the bootstrap node, but then the bootstrap node immediately
upgrades to 1.18.1, I would not consider bug #1247232 to be fixed.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTT8isAAoJEK84cMOcf+9h2PQH/RY/US33w8uqhltogjZCtyQu
EZzSS6wwc209UjtutZzn6Di/sNMaGOpu/x+0UtVmh2CbnjIHwwfmph9uBWgslBTp
kPTafLEjI8s990NwlSFRo3CYlyG1QHgwCk6AZ1xImYLBvrwV/5vC5/FpVV+beFuu
yk9SQh7TgDQ8/diil+x8PUHkJ6i2tGoiUdjwGM6aBbvNZ1JHThXUF1C6a5IBoMg0
8Fz8T6Iyxg0rFWDQejY53hHTbaRHKmA95o4uAn6TAPWGB+vU3hv5IEd8v0i6rdfz
JMv63qS/cZ23I7V7Fl3DLSvqZ3Ol9FWDykxMfKU2kQ7OFzPtD4KujzTW2FlAV6k=
=2OkY
-END PGP SIGNATURE-

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

Re: CI hates juju, maybe the feelings are mutual

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-10 02:19 PM, John Meinel wrote:
> So Juju would certainly let you run an older binary, and it would, 
> indeed, switch to that binary.

Phew!

> I would be ok with allowing downgrades within a PATCH level, but I
> think it still holds true that downgrades are very untested, and
> downgrading across a MINOR version is almost definitely always
> going to do something bad.

Downgrades within a patchlevel are *very* tested, by CI :-)

> That said, I think for CI getting bootstrap to target an explicit 
> version is far better than bootstrapping to the latest trunk, and
> then downgrading.

+1

> I would be willing to compromise in the short term by adjusting the
> "refuse to downgrade" to only refuse to change Major.Minor 
> versions. It still fixes the existing bug, and would let CI
> continue.

Thanks.  That seems like a good short-term solution.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTRuNGAAoJEK84cMOcf+9hQfwH/1ApaODdPKLYHtihRNsGkpLT
fGqp1bf5FGAfQEa+EOipQ6zVRq2eFO/cGFkYMfRE8ifo9EbkS275I0FWfNxZY7K7
L6hfPLcRhWCyjMmAw32pdH6VJD0SwI9F6UBg1ILGODs062ILOAvej6cnmJmSZYJi
vW/xoB7Uhif27Zqu/8YPaQZLQQAW8raT46eIeVLRvfzonrdlnmkENZhcsDYVfS07
2Pd0ftXiocUh5S70GtlhTTqkfDYvBnaugjtDKSfZJ9n+uhuyvGSVSoZFOMAEBUPo
LXnOWZm8JOO+wzo2zpfB2pSCBYil3O7EJaz9/QODp93ngO0dNQiX0M6H+gbWPmk=
=HlFF
-END PGP SIGNATURE-

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