-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
/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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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
-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:
-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:
-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
-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
-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
-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
-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-
-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
-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
-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
-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
-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:
-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
-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
-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
-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
-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
-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:
-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
-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 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. *
-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
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
-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
inally
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
* 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
-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
>
-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
-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
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
-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
-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
-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
-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
>
-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
-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
-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
-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
-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
-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
-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 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 easil
-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
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
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 wi
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
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
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
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:
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:
-
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,
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
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
76 matches
Mail list logo