API compatibility policy and practices between juju versions

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Arbash Meinel wrote:
 I think that is one of the primary caveats for the we don't 
 guarantee all cross version compatibility is that we *do*
 guarantee upgrade works.

I think we should also support status, so that
1. You can determine when an upgrade has gone wrong
2. When an upgrade goes wrong, you know the IP address of the affected
machine, so that you can SSH into it.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKND8YACgkQ0F+nu1YWqI01OgCfVr0Z4IDlccjuZ6uhJwxPJDCj
LFYAn2fRRF+JffQFgROJMVDuD/XRhCdI
=BoYX
-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: Initial ssh key management functionality in trunk

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13-12-13 03:55 AM, Ian Booth wrote:
 I'm guessing people will mostly use import to pull in ssh keys from
 Launchpad or Github eg juju authorised-keys import lp:wallyworld.
 But for clouds which do not have access to the internet, add is
 useful since it allows a full key to be imported directly.

If lp: URLs are supported, I recommend using lp:~wallyworld for
consistency with other lp: URLs.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKrGCgACgkQ0F+nu1YWqI11lgCdGTQVZmzjeY+8+ZCPdcngMILX
WnIAni7OuD+V+mvz+ijuqMkYJEOKfHVJ
=j/9f
-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: Local provider - isolating sudo usage

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-01-22 06:12 PM, Andrew Wilkins wrote:

 I would like to also prevent Juju from allowing the user to run
 with sudo from the outside. This will allow us to remove all of the
 code pathways that change ownership to the sudo caller, and avoid
 future breakages.

As a user who has to work around the chown bug frequently, that sounds
great to me.

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

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLhIawACgkQ0F+nu1YWqI0x9QCfa/zZu9j67p6KQ+C7T6/4qxvw
Zq0AniDjFTalu0P4RC48htZ+1IX2Z/oQ
=a+OP
-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: Two new bugs blocking CI

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-02-19 09:37 PM, Andrew Wilkins wrote:
 Glad to see that manual is now in CI.

Well... almost.  I am working to put manual into CI but was blocked by
this bug.  I'll look into the upload-tools workaround today.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMGDBIACgkQ0F+nu1YWqI0yjgCaA2Oqr9tJEfBl9SD3JzXd23Fj
KbQAnj3JTGDqssuU80hDh4uVZ3QlwlSM
=LtKb
-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 05:41 AM, John Meinel wrote:
 Well you used to be able to request a downgrade, but it never
 actually worked... :)o

Could you explain that further?

We've done thousands of downgrades and juju reported that it had
switched the agent to the requested version.

We first implemented downgrading in November or so.  Are you saying
Juju has been lying the whole time?

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

iQEcBAEBAgAGBQJTRq6MAAoJEK84cMOcf+9hnkAH/iMBtxxJJkacqq2oM25EA6iv
FbkCClUGBOJweEHVqgWugVNacS/gX9CQjDyOfPF2MVlB7VTxIuw55ysxLn/DyAJI
TVOOi08rEl0G6wUVguMcwrOyuyK35X2CX+BwN/XNDw1deKEN8Qy0c/wfdVPq0pvi
90c09VgS/7VEKb0fC9JYT6vlaB/2u+uHDQQflpdpCQOD2jCFk/KbLUjudN6ivq5n
e69/8k4gUKbJTnEO2DH8X+oKX9/O3yZwXUKcYmz9FpDveTGoaBIqwZjsVxdx7HzS
O80zVVi/opw4qLjwOmpb1mXTSKqL9c61Fdj4+04TQrG5PM9nkNrfTJWrkzk2prk=
=Z3my
-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 08:23 AM, John Meinel wrote:
 Note that copying off the all-machines log seems to be broken, the
 lines:
 
 juju --show-log scp -e test-release-aws -- -o
 'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' -i
 /var/lib/jenkins/cloud-city/staging-juju-rsa
 0:/var/log/juju/all-machines.log
 /var/lib/jenkins/jobs/aws-upgrade/workspace/artifacts/all-machines-test-release-aws.log

 
2014-04-10 03:40:59 INFO juju.cmd supercommand.go:297 running
juju-1.18.0-precise-amd64 [gc]
 2014-04-10 03:40:59 INFO juju api.go:238 connecting to API
 addresses: [ec2-54-86-4-94.compute-1.amazonaws.com:17070
 http://ec2-54-86-4-94.compute-1.amazonaws.com:17070] 2014-04-10
 03:40:59 INFO juju apiclient.go:114 state/api: dialing
 wss://ec2-54-86-4-94.compute-1.amazonaws.com:17070/
 http://ec2-54-86-4-94.compute-1.amazonaws.com:17070/ 2014-04-10
 03:40:59 INFO juju apiclient.go:124 state/api: connection
 established 2014-04-10 03:40:59 ERROR juju.cmd supercommand.go:300
 unexpected argument -o; extra arguments must be last
 
 
 It looks like you have to spell it:
 
 juju --show-log scp -e test-release-aws
 0:/var/log/juju/all-machines.log
 /var/lib/jenkins/jobs/aws-upgrade/workspace/artifacts/all-machines-test-release-aws.log
 -o 'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' -i
 /var/lib/jenkins/cloud-city/staging-juju-rsa
 
 I don't know if -- for SCP ever worked, but it appears 1.18 wants
 a different spelling.

Using '--' to separate commands was the only way that used to work for
juju scp.  Most all-machines.log that you'll find in CI bug reports
were produced this way.

If you passed -o directly, juju would complain that it was not a valid
option, no matter where you put it.  This problem did not happen with
juju ssh.

It's nice that things are easier now, but it's a shame that the fix
broke existing scripts.

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

iQEcBAEBAgAGBQJTRrMjAAoJEK84cMOcf+9hshsH/0338ET9mAJhcAHPd2pBdtzy
9s4nXlARPrEH0/SW2IbmamSvLRRuNHRG/FrP/98fBsT3G9Db7099+ywgYhfzvtvN
ucaE1Tu+1XiSi+ZFWW9CJP00JQP4CyPbpA9wsbHMbBPn3BBUO8+gkkmt2XbW1/1N
MqkAgBRWuQDN7EGMYQLFhjIs6ipxv5wbtIRdEqdcChZbHsoKLNYSfdRQhdpq4ikR
lkwAodnsMOP7KPGTyX8LUEYnNJYf1E516Hf7IaRTw875XC0Hk863fI58wBFG6fe+
1DGM+l0C0H95Do4ExxgEq2xmONhL33/g7FzUVstaRNkm04xPvI4iypHMvZH08+A=
=+ALO
-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

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-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: 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: 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: 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: 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=1by=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: 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: 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: 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: 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: 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-19 10:36 AM, Gustavo Niemeyer wrote:
 On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley 
 aaron.bent...@canonical.com 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 11:41 AM, William Reade wrote:
 On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley 
 aaron.bent...@canonical.com 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 11:41 AM, Gustavo Niemeyer wrote:
 On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley 
 aaron.bent...@canonical.com 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 12:46 PM, Gustavo Niemeyer wrote:
 On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley 
 aaron.bent...@canonical.com 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-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

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

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

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

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

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

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

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: 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: 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 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 04:10 AM, roger peppe wrote:
 On 28 April 2015 at 19:32, Aaron Bentley
 aaron.bent...@canonical.com 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-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-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

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

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

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

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

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

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

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

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

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
> 

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

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: 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
> > wrote:
> 
> On 1 December 2016 at 13:53, Marco Ceppi  > wrote:
> 
> On Thu, Dec 1, 2016 at 5:00 AM Adam Collard
> >
> wrote:
> 
> On Thu, 1 Dec 2016 at 04:02 Nate Finch
> >
> 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

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