I like Rog's suggestions about switch being all about environment names,
and nothing else, and juju env being about only printing local info about
an environment. Keeping it away from the network is a good thing. If they
want status, they can run status.
On Fri, Jun 6, 2014 at 5:34 AM, roger
I've been wanting to get a few minutes of spare time to try out
reviewboard. It's python based, has a charm (though it's outdated) and is
supposed to be nice to use, though I've not used it in any anger yet.
http://www.reviewboard.org/
Rick
On Fri, 06 Jun 2014, Menno Smits wrote:
If we're
On Fri, Jun 6, 2014 at 9:49 AM, Nick Veitch nick.vei...@canonical.com
wrote:
sounds much better. Is there some way of throwing in whether HA is
enabled in there too?
I'm not sure that's very closely related to the purpose of the command. HA
status is variable, and not a useful differentiator
As a user of juju swtich/juju env, I'd be sad to see it's very basic and
straightforward operation go. For instance, I can run:
$(juju env)
at any time in a shell and know for certain what environment I'm targeting
(and know immediately). It unwinds the mess that is env variable, default
On Fri, Jun 6, 2014 at 4:50 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
I've gotten a bit closer to figuring out what the deal is. Even on the CI
machine, local provider works with HA enabled, but only if you use the EBS
storage. If you use that machine's ephemeral disk (as your
That is awesome. I presume that means we can re-re-re-enable HA on local
provider? At least Michael has all the code to do so now, so it should be
quick this time.
Very nice work, Andrew. I'm not sure it ever would have occurred to me
that the storage type would matter.
On Fri, Jun 6, 2014
I think this is an edge case for the local provider. I would expect
special support for ephemeral disk
Oops, I mean is *would not* expect special support for ephemeral disk.
--
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui
--
Juju-dev mailing list
Hi William,
On Fri, Jun 06, 2014 at 07:40:47PM +0200, William Reade wrote:
To restate your point, I think: you want to be able to keep seeing and
reading simple names for the contexts you have available to work in.
Yes. Agreed.
Do the following use cases express your needs (even if you
On 06/06/2014, Nate Finch nate.fi...@canonical.com wrote:
As for ditching go get... yes and no (mostly no). go get is not really
intended for use in contributing to an external project. It's a download
and install this application. If anything, we should be making our code
*more* happy
(Resending since the list didn't like my screenshots)
https://twitter.com/beyang/statuses/474979306112704512
https://github.com/juju/juju/issues/43
Any tooling that exists for go projects is going to default to doing go
get. Developers at all familiar with go, are going to use go get.
People
just as it fails for many other projects.. etcd, docker, serf, consul,
etc... most larger projects are going to run afoul of trying to do cowboy
dependency management and adopt one of the extant tools for managing deps
and have a non standard install explained to users in its readme, else its
go is the default build tool, and the vast majority of go projects work
out of the box with go get. If we cannot make it work, that's fine, but
looking at other projects that cannot get it to work is no excuse. If you
guys can make it work, even if we continue to support godep(s), by all
means do
12 matches
Mail list logo
