The CLI now goes exclusively through the API, so you should be able to
drive it from the GUI as well.
We'll probably need more focused APIs for getting the status of state
machines (right now I think we just put it into Status itself, and we'll
want to have a way to get just that information
Well, there is Won't Fix to close them, or there is set them to Low which
allows for an acknowledgement that it could be fixed, but just not now.
I prefer the Low version myself, as number of Open bugs has never been a
concern for me.
I do agree that we want a better view of what we are actually
I remain strongly +1 on bootstrapping with tools that exactly match the
client version -- the client code near-enough directly drives those tools
as we bootstrap, and if we force pinned versions at bootstrap time we're
free to change how bootstrap works. If we need to deal with variation in
the
My preference would be to convert the scripts into Go executables that do
the exact same thing (to start), which can then start to be refactored to
leverage all the rest of the knowledge embedded in our codebase to do
things like figure out the path to the correct mongo executable, for
example.
-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
On Fri, Apr 18, 2014 at 11:34 AM, Aaron Bentley aaron.bent...@canonical.com
wrote:
-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
I did eventually manage to run the CI tests, though there are some oddities:
1) You have to set JUJU_HOME and SCRIPTS, though that is in the docs
2) You have to set LOCAL_JENKINS_URL to the ec2 instance
3) You have to set WORKSPACE, but you *also* have to have $PWD already be
in WORKSPACE.
4)
We have a bug where Juju is no longer defaulting to the arch of the local
machine, but instead always choosing 386.
Bug #1304407: juju bootstrap defaults to i386 amd64 apport-bug
ec2-images metadata trusty juju-core:Triaged juju-core
1.18:Triaged juju-core (Ubuntu):Triaged
I think prefering amd64 over i386 is reasonable. I know, though, that we
had at least one person on an i386 that thought --upload-tools would work.
The fact that we have upload-tools is a strong hint to prefer
version.Current.Arch.
Also, we used to fix it to amd64 but that broke for clouds that
I'm not sure what happened, because r2655 shows it passing on all targets,
but the actual change was only really related to MaaS.
I'm still going to try and see if I can get the CI tests to run locally. If
I can get the steps to set up pretty clear, then it should be easier for us
to reproduce
10 matches
Mail list logo
