Hi John --
I certainly don't want to get mixed up in *that* discussion.
Getting the plain environment name is generally useful, perhaps my simple
off-the-top-of-my-head-example took this the wrong direction. :)
Sidenote: I also agree that making destroy explicitly require the
environment name w
...
> > Do the following use cases express your needs (even if you weren't
> > hitherto aware that you were specifically manipulating environment
> > *connections*)?
>
> Ah, ok, things are changing, got it. Making sure patterns like the
> following are still easily grok-able (even if it's a diff
To avoid having to type the branch name when pushing changes to your fork
on Github I would recommend setting push.default to "current". You can then
just push with "git push origin" (no branch name required).
Git v1's default push behaviour if you don't specify the branch name is to
push all bran
"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
Yeah, it's definitely not perfect. It would be much better if Github had
native support for side-by-side diffs.
On 6 June 2014 22:10, Nate Finch wrote:
> Yeah, note that it bugs out if you try to expand the context around your
> changes *after* turning on side-by-side mode, so expand what you w
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
vendo
(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
On 06/06/2014, Nate Finch 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 with go get, so if Go
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 yo
>> 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
On Fri, Jun 6, 2014 at 4:39 PM, David Britton
wrote:
> 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 im
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 a
On Fri, Jun 6, 2014 at 4:50 AM, Andrew Wilkins
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 jenkins setup
> does), then mo
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
yaml
On Fri, Jun 6, 2014 at 9:49 AM, Nick Veitch
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 between environments;
On Fri, Jun 6, 2014 at 11:34 AM, roger peppe wrote:
> On 5 June 2014 23:16, Tim Penhey wrote:
> >> Addressing the concerns, can we not:
> >>
> >> $ juju switch [env]
> >> $ juju info
> >> # display env info of env user just switched into
> >
> > OK, here is my proposal, which I hope addres
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 fin
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 pep
Yeah, note that it bugs out if you try to expand the context around your
changes *after* turning on side-by-side mode, so expand what you want first
and *then* turn on side-by-side mode.
Also I wish it were really side by side mode, It's still basically
over/under, just horizontally separated
So, there's no tricking the import logic. The import path has no strict
relation to the package name. The package name is only defined by the
"package foo" line at the top of every file. The import path is only
defined by the location on disk. It is simply by convention that the last
part of
On 5 June 2014 23:16, Tim Penhey wrote:
> On 06/06/14 09:55, Jesse Meek wrote:
>> I have a branch proposed that displays extra environment information
>> when the --format flag is used with switch e.g:
>>
>> $ juju switch local --format yaml
>> environ-name: local
>> previous-environ-name: ec2
>>
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 jenkins setup
does), then mongo is not happy. The fact that it's running Precise has
nothin
>> 5) add a juju info command that outputs:
>> * environment name
>> * uuid - if we have it
>> * api end points
>> * CACert - if we have it
>> * status - [running, stopped, and soon maybe suspended]
>> * username
>>- supports json, yaml, and defaults to 'smart'
>>-
23 matches
Mail list logo
