Re: High Availability command line interface - future plans.

The answer to how does the user know how to X? is the same as it always has been. Documentation. Now, that's not to say that we still don't need to do some work to make it intuitive... but I think that for something that is complicated like HA, leaning on documentation a little more is ok. More

Re: Windows clients and PuTTY

a major headache. I think for the windows cli the best experience would be to fire off putty.exe, so the user has all their normal putty customization necessary and doesn't have to use ssh though the crippled win32 console. Cheers Dave On Wed, Dec 4, 2013 at 10:40 AM, Nate Finch

Re: Questions about the integration of the Outscale cloud provider into juju-core

There seems to be no compelling reason why we can't distribute more than just juju and jujud. However, I don't think there's anything to gain by splitting out the providers we already have in core. Adding code that enables pluggable providers seems like a no-brainer to let people provide their

Re: arch constraint default changed?

For what it's worth, I agree with everyone. John and I discussed it, and I thought we had decided that we needed to use the local arch because of upload tools, evidently John though we'd decided in the other direction. And Gustavo is right that we should have pushed the discussion to the mailing

Re: Juju on Reddit

I'd be happy to help out, I'm natefinch on reddit. On Tue, May 20, 2014 at 1:50 PM, Matthew Williams matthew.willi...@canonical.com wrote: Thanks Joey, I've added you - if you can work out how to add the flair be my guest Cheers Matty On Tue, May 20, 2014 at 6:01 PM, Joey STANFORD

Re: juju bootstrap error

Ug we really need to clean up our error reporting in this area. rc: 1 is a completely unacceptable error message. On Wed, May 21, 2014 at 6:46 AM, David Cheney david.che...@canonical.comwrote: I am sorry, the bootstrap machine was not able to communicate with the server,

Re: I gave a quick writeup over Juju on Digital Ocean

Nice! Digital Ocean really is super fast my Discourse charm takes 21(!) minutes to deploy on an AWS m1.small and 7 minutes on a DO 2GB droplet, which is 2/3rds the price of the amazon instance. Kapil's digital ocean plugin really makes it all (relatively) seamless, too. I look forward to

Re: request for mirror all charms from jujucahrms to github

The Juju application *has* moved to github. We use launchpad for bugs, but github is the home for the code. On Tue, Oct 7, 2014 at 4:08 PM, José Antonio Rey j...@ubuntu.com wrote: Juju didn't move to Github. Juju charms are only being mirrored to Github. -- José Antonio Rey On Oct 7, 2014

Re: proper way to deploy to one server (lxc based)

The point is - don't use local provider. If you have a single VPS, use the manual provider to bootstrap onto that machine. You can run juju bootstrap from your laptop to bootstrap juju onto the VPS. https://juju.ubuntu.com/docs/config-manual.html On Wed, Oct 8, 2014 at 11:58 AM, Andrew Wilkins

Re: Where is the Juju-gui heading ?

Funny you should ask, but putting constraints directly in the charm's metadata.yaml is a feature we are planning to work on this cycle. Charm authors will be able to set default constraints for their charm, so that if you know your charm needs 2GB of RAM to work properly, for example, you can set

Re: machine state stuck at pending

Definitely the low 1.20.x releases had a couple issues especially with containers. These were all fixed later, as Mark mentioned. Hopefully that'll solve your problems. On Nov 15, 2014 1:02 PM, Mark Shuttleworth m...@ubuntu.com wrote: On 14/11/14 02:39, Sameer Zeidat wrote: Hello, I'm

Re: Lets version lock the docs!

+1 On Jan 14, 2015 12:54 PM, Marco Ceppi marco.ce...@canonical.com wrote: Hey everyone, There's currently quite a few version of juju available [0] from various sources (cloud archive, ubuntu archive, stable ppa, source). While I know the release team is doing a great job in making sure that

Re: What's the future of Juju?

I'm a core dev on Juju, I can answer some, but not all of these questions. First off, as far as long term commitment for Juju - Juju is a huge part of Canonical's long term strategy... right up there with the Ubuntu Phone and Ubuntu itself. The Juju team has been expanding hugely in the last

Re: New Docker goodies

What does this do that just using the juju binary on your local system doesn't do? On Fri, Mar 27, 2015 at 11:49 AM, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, First, if you haven't seen this yet, this is a docker container that let's you just try Juju, with the limitation that you

Re: gocharm or harm.v5 how to get charm dir?

Hooks and actions all fire with the root of the charmdir as the current directory, so in general, you don't need to get it, you're already there. For example, if your charm has charmdir/assets/foo.jpg ... you can just do f, err := os.Open(assets/foo.jpg) and it'll work correctly. On Mon, Jun

Re: Juju Compose

I'm not sure I understand the problems this is solving that aren't adequately solved by branching from a source charm. It seems like the hard part of branching - maintaining changes to non-trivial code - is not helped by this tool. For charms that just need to add hook files or modify charm

Re: Compiling juju on openSUSE

Compiling juju on any Linux is actually very straight forward... however *running* Juju on any Linux except Ubuntu and Centos is not going to work (due to some platform-specific code we have)... but if all you want to do is compile, that's easy: Install git, bzr, and mercurial (pretty sure

Re: Juju on multiple public clouds

It depends on what you mean. If you mean "can I have some machines on AWS talk to some other machines in Azure inside the same Juju environment" then the answer is mostly no (you can use a machine's ssh info to "import" that machine into an existing juju environment, but it's quite different than

Re: Which JUJU_DEV_FEATURE_FLAG were used?

The environment variables are transferred to the server, so getting them from /proc//environ on the server should be doable (someone better at bash might be able to give you a one liner). On Tue, Sep 22, 2015 at 1:19 PM Andreas Hasenack wrote: > Hi, > > given an existing

Re: Need info for deploying Mariadb as xenial

You can use --series xenial --force I don't know if there's anything in the charm that might fail, though. On Mon, Jun 27, 2016, 7:40 AM Rajith P Venkata wrote: > Hi > > I am deploying mariadb5.5 on juju 2.0, I am getting error . Mariadb charm > supports only trusty , is

Re: Sending binaries over relations

I actually don't see why you would ever need to distribute a specific library for connecting to an API on another charm. The charm using the dynamically determined client would still require a static (i.e. backward compatible) API on the client library (otherwise the client charm would have no

New feature for charmers - min-juju-version

There is a new (optional) top level field in the metadata.yaml file called min-juju-version. If supplied, this value specifies the minimum version of a Juju server with which the charm is compatible. When a user attempts to deploy a charm (whether from the charmstore or from local) that has

Re: Unfairly weighted charmstore results

BTW, I reported a very similar problems in this bug: https://github.com/CanonicalLtd/jujucharms.com/issues/192 On Thu, Mar 17, 2016 at 10:18 AM Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Hi Tom, > > We currently bump the recommended charms over the community ones. The > reason other

Re: Charm layers & Windows

At least... according to the core code, but it occurs to me I may well be mistaken about what's allowed by the charm authoring tools and/or charmstore. On Mon, Apr 4, 2016 at 10:16 AM Nate Finch <nate.fi...@canonical.com> wrote: > BTW, I don't believe this is true. I didn't work

Re: Charm layers & Windows

>From what I've read, there's no server-side story to Ubuntu on Windows. It's purely desktop, and in fact, only installs on desktop versions of Windows 10. That could help with tooling for charm authors, but obviously the charm code itself still needs to run on vanilla Windows. The main tricky

Re: New feature for charmers - min-juju-version

fully ignore it? > > On Thu, Mar 17, 2016 at 1:57 PM, Nate Finch <nate.fi...@canonical.com> > wrote: > >> There is a new (optional) top level field in the metadata.yaml file >> called min-juju-version. If supplied, this value specifies the minimum >> version of a Juju

Re: Point people to ubuntu-on-windows instead of the broken juju-on-windows?

Just FYI - running the juju client on Windows is 100% supported and we actively fix bugs on it all the time. I hadn't seen the particular bug you referenced about juju ssh, but that definitely seems like something we should prioritize higher. The linux ssh works so much better because we can

Re: kill-controller, unregister, destroy-controller

This is one of the reasons we always make you type out the controller name for destroy controller. Because juju destroy-controller production-website should ring a bell. Simply adding a long flag doesn't really help you remember if you're killing something important or not, because you always

Re: 1.25.6-xenial-amd64 and lxc containers

You don't need anything in the environment.yaml. You specify that you want to deploy something to a lxc container in the deploy command. e.g. juju deploy mysql --to lxc // deploys mysql to a new lxc container on a new machine juju deploy wordpress --to lxc:25 // deploys wordpress to a new

Re: List plugins installed?

Seem alike the easiest thing to do is have a designated plugin directory and have juju install copy the binary/script there. Then we're only running plugins the user has specifically asked to install. On Thu, Sep 29, 2016, 4:33 AM Stuart Bishop wrote: > On 28

Re: What are the best practices for stop hook handling?

1. The stop hook happens when the unit is being removed entirely. It does not run on reboot (and there's no reboot hook). The docs on the start hook mention this: "Note that the charm's software should be configured so as to persist through reboots without further intervention on juju's part."

Re: Controllers running out of disk space

Resources are also stored in mongo and can be unlimited in size (not much different than fat charms, except that at least they're only pulled down on demand). We should let admins configure their max log size... our defaults may not be what they like, but I bet that's not really the issue, since

Re: A (Very) Minimal Charm

> > > wrote: > > > > On Thu, Dec 1, 2016 at 5:00 AM Adam Collard > > <adam.coll...@canonical.com > > <mailto:adam.coll...@canonical.com>> wrote: > > > > On Thu, 1 Dec 2016 at 04:02 Nate Finch

Re: Hide resources from showing on the store

I'm with Rick... the expected usage is to publish a dummy resource with the charm. Then, when you deploy, you deploy the real resource from your local machine at deploy time. If you forget, you can always add the resource after deploy, as well. The charm needs to take into consideration that

Re: using a bundle with manually added machines

FWIW, I think this *could* work, but it may be that we just haven't coded it up. Just as *juju deploy mysql -n 4* will use existing clean machines in the model where appropriate, deploying a bundle should as well (presuming the existing machines match constraints etc as usual). On Tue, Jan 3,

Re: Clean Code and single character variable names

I don't have time to properly respond, but I'm pretty sure no one on this team is using single letter variables to save keystrokes. Is is a good point that abbreviations may be more common in one area than another. I find both ctx and txn to be completely self explanatory even with zero context

1.14 doesn't actually build

It was just brought to my attention on IRC that, due to a change to gwacl after 1.14 was cut, 1.14 doesn't actually build right now (if you just use the most recent version of gwacl). The error is provider/azure/storage.go:96: multiple-value context.GetAnonymousFileURL() in single-value context

please update goamz

There was an update to support block device mapping that is used by a branch that got merged to trunk yesterday. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Notes from Scale testing

On Wed, Oct 30, 2013 at 9:23 AM, John Arbash Meinel j...@arbash-meinel.comwrote: 2) Agents seem to consume about 17MB resident according to 'top'. That should mean we can run ~450 agents on an m1.large. Though in my testing I was running ~450 and still had free memory, so I'm guessing there

Re: State interfaces

+1 On Thu, Oct 31, 2013 at 8:57 AM, John Arbash Meinel j...@arbash-meinel.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-10-31 16:21, Andrew Wilkins wrote: Does anybody object to converting the public entity structs in state to interfaces? i.e. State, Machine, Unit,

new EC2 instance type price drop on M3's

New instance type, high GPU: g2.2xlarge: 15 GiB memory, 26 EC2 Compute Units, 1 x NVIDIA GRID GPU (Kepler GK104), 60 GB of local instance storage, 64-bit platform http://phx.corporate-ir.net/phoenix.zhtml?c=176060p=irol-newsArticleID=1872208highlight= Also, m3 instances dropped in price:

Re: High Availability command line interface - future plans.

The answer to how does the user know how to X? is the same as it always has been. Documentation. Now, that's not to say that we still don't need to do some work to make it intuitive... but I think that for something that is complicated like HA, leaning on documentation a little more is ok. More

Re: High Availability command line interface - future plans.

life. That's kind of the whole point of Juju, right? On Wed, Nov 6, 2013 at 2:56 PM, Nate Finch nate.fi...@canonical.com wrote: The answer to how does the user know how to X? is the same as it always has been. Documentation. Now, that's not to say that we still don't need to do some work

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 6:34 AM, Gustavo Niemeyer gust...@niemeyer.netwrote: On Fri, Nov 8, 2013 at 8:31 AM, John Arbash Meinel j...@arbash-meinel.com wrote: I would probably avoid putting such an emphasis on any machine can be a manager machine. But that is my personal opinion. (If you want

Re: High Availability command line interface - future plans.

Reminds me of one of my favorite quotes: Knobs are distracting, confusing and annoying. Personally, I'd rather things be 90% good 100% of the time than see 90 knobs. - Brad Fitzpatrick on having more than one Go scheduler.

Re: High Availability command line interface - future plans.

Scaling jobs independently doesn't really get you much. If you need 7 machines of redundancy for mongo... why would you not just also want the API on all 7 machines? It's 100% upside... now your API is that much more redundant/scaled, and we already know the API and mongo run just fine together

Re: Avoiding my $2000 AWS bill

...@canonical.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-01-08 03:25 PM, Nate Finch wrote: It turns out there's a really easy way to avoid this: set up a billing alert in AWS to email you if your estimated monthly bill goes over a certain amount for a long enough time. Note

Re: Avoiding my $2000 AWS bill

Actually, after some digging, it looks like billing alerts are only in a single region. I can't see a way to set billing alerts anywhere except US-East. On Wed, Jan 8, 2014 at 4:42 PM, Nate Finch nate.fi...@canonical.com wrote: Wow, I totally didn't realize you needed one per region. Wish

Re: Avoiding my $2000 AWS bill

, 2014 9:07 PM, John Meinel j...@arbash-meinel.com wrote: Which was sort of the whole point, right? If you had started the instance in your normal region, you would have seen it and stopped it. John =:- On Jan 9, 2014 2:16 AM, Nate Finch nate.fi...@canonical.com wrote: Actually, after some

Re: Local provider - isolating sudo usage

That sounds awesome. On Wed, Jan 22, 2014 at 6:12 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hi folks, I'm working on changing the local provider so that sudo is not needed from outside Juju; juju bootstrap and juju destroy-environment will prompt as necessary. I would like

Re: new dependency

Penhey tim.pen...@canonical.com wrote: On 06/02/14 14:14, Nate Finch wrote: One thing I noticed was that it looked like it wasn't generating an actual stack trace ever. I think that's pretty critical to knowing how you got to the spot where you got the error. I made the default behaviour

Re: new dependency

On Fri, Feb 7, 2014 at 5:24 AM, roger peppe rogpe...@gmail.com wrote: http://play.golang.org/p/Ze_YTCcfzm Note that, even ignoring the doc comment, it is easy to tell by looking at the high level function, ReadPacketFromNetwork, what classifiable errors might be returned from it. This

Comparing Error packages

I propose we make a small sample program that exercises error returns in several typical ways, including the non-trivial scenarios, and then make one implementation for each competing error package, so we can see how they work out in real code. The code can be very terse, since there's no need

MockPackage()

In some places, we have exposed constants that should not normally be public as public variables, purely for the purpose of testing. The reason we need to do that, is because packages can't use code that is only exposed in _test files for other packages (i.e. package foo has a export_test.go

Re: MockPackage()

think this is a pretty good point, so I'll try to come up with a third way that isn't too cumbersome. On Mon, Mar 3, 2014 at 12:35 PM, Nate Finch nate.fi...@canonical.comwrote: In some places, we have exposed constants that should not normally be public as public variables, purely for the purpose

Re: MockPackage()

, Mar 4, 2014 at 7:30 AM, John Meinel j...@arbash-meinel.com wrote: honestly, http.DefaultClient is a case of global state that too many people touch, and I'd be happier to avoid them. On Tue, Mar 4, 2014 at 1:58 PM, roger peppe rogpe...@gmail.com wrote: On 3 March 2014 17:49, Nate Finch nate.fi

Re: Upcoming import change for loggo

For the record, I'm not a fan of duplicating the package name of anything in the standard library. Obviously, sometimes collisions will happen if a new package is added to the standard library, but it seems like a bad idea to do it on purpose. When you're deep in the middle of a file, and you

github code reviews

I like github. I don't like in-line diffs and one email per code review comment, which is all github provides. So I did a quick google, and this came up: https://review.gerrithub.io/#/c/2160/2/roles/packstack/rdo/tasks/main.yml it looks pretty good. http://gerrithub.io/ -- Juju-dev mailing

juju-core tests broken by gwacl

I know some people were working on gwacl, but it seems there were some breaking changes made (possibly for 1.17.5?) The provider/azure tests are failing... I took a look but couldn't immediately figure out what was going wrong... Looked like Andrew was the last one to change gwacl, maybe you'd

Re: I WANT YOU, to give me your feedback (Juju docs!)

+1 Markdown is great. It's basically the only way to write HTML that is actually legible outside of a browser (like in diffs, code reviews, as you're actually writing it, etc). On Fri, Mar 21, 2014 at 1:47 PM, Marco Ceppi marco.ce...@canonical.comwrote: Hi everyone, I'm spreading this

Re: no log tests

wrote: Alternatively you can run the tests with -juju.log ERROR (sent from my phone so unable to double check the extact syntax) On 26 Mar 2014 19:00, Z. Nate Finch nate.fi...@canonical.com wrote: So, I often get failed tests that are so obscured by our log output that I can't even tell what's

Re: Implementing Juju Actions

What's the difference between Actions and Set? If I do juju set mysql admins=nate,bill the mysql charm sees the updated admins, and performs some action (updating permissions in this case). How is that different from something like juju do setadmins mysql nate,bill ? On Thu, Mar 27, 2014 at

fix for 1.18-1.19 upgrade failure

If anyone has some time to do a very quick review, this change lets us upgrade from 1.18 to 1.19. The problem was that trunk was replacing the mongo upstart script of existing environments to start mongo with --replSet, but we can't actually support that just yet. So the fix is just to not

Re: Fixing backup and restore

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.

defaulting to arch of local machine

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

Re: Juju Academy

Actually, init is the main command, generate-config is an alias for init (see juju help commands). On Wed, May 7, 2014 at 1:55 PM, Nick Veitch nick.vei...@canonical.comwrote: Nice work, when it is ready we can add it to the getting started section of the docs too. Small point - 'juju

Deploying wordpress doesn't work on trusty w/ local provider

Deploying wordpress to the local provider on trusty deploys the precise version of wordpress (the only version available), which hits this bug during the install hook: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/969299 The key line is this error from the install hook's code: failed to

Re: Deploying wordpress doesn't work on trusty w/ local provider

the fstat issue? All the best, Charles On Thu, May 8, 2014 at 2:40 PM, Nate Finch nate.fi...@canonical.comwrote: Deploying wordpress to the local provider on trusty deploys the precise version of wordpress (the only version available), which hits this bug during the install hook: https

Re: Deploying wordpress doesn't work on trusty w/ local provider

FYI: https://bugs.launchpad.net/charms/+source/wordpress/+bug/1317644 On Thu, May 8, 2014 at 3:20 PM, Charles Butler charles.but...@canonical.com wrote: Much Appreciated! On Thu, May 8, 2014 at 3:19 PM, Nate Finch nate.fi...@canonical.comwrote: No, but I will. Wanted to make sure I

Re: Preferred wrapping for long function declarations

Personally, I find #3 to be very hard to read. It's very difficult for me to look at the signature and find the return values, and it's hard for me to determine where code starts. My preference is for #1 - let it wrap, and just try to use short names and few arguments so as to avoid it most of

Re: Preferred wrapping for long function declarations

I was twiddling with gofmt, and I stumbled on this format, which is a lot more readable for me, if we want to wrap long lines: func (c *CustomCaller) MethodCaller( rootName string, version int, methodName string, ) (rpcreflect.MethodCaller, error) { } On Tue, May 13, 2014 at 12:03 PM, Nate

Re: [Proposal] Requiring Go 1.2 across the board

+1 On May 16, 2014 3:53 AM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise

Re: (not) using loggo in github.com/juju/errgo

. On Tue, May 20, 2014 at 7:24 AM, Nate Finch nate.fi...@canonical.comwrote: I just noticed that errgo uses loggo for one single debug statement. I think this is a mistake if we want errgo to be reusable by the community. We should strive to make our independent packages actually independent

Re: Ensuring tests pass on gccgo

Although using DeepEquals on sorted lists does make for easier-to-understand test failure messages, the burden on the developer to sort the slices when they write the test doesn't seem worth it to me. We write tests a lot more often than we need to debug failing tests. If it was just slices of

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

I agree with Roger, I don't think a wrapper around Errgo is the right way to go. If we don't like the way errgo behaves, we should change it. It's our package, let's have it work the way we want it to work. On Thu, May 22, 2014 at 10:47 AM, roger peppe rogpe...@gmail.com wrote: On 14 May 2014

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

...@canonical.comwrote: On 28/05/14 13:31, Nate Finch wrote: If you're talking about errgo, if all we care about is transition, but not what the actual types are, we could just record in the list when we mask the type. We could, but that would mean walking the list every time you want to check the cause

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

I propose we change the name of the package to something other than errgo, so that Roger can keep his name, and we can make the behavior whatever fits best for Juju. Yes, we should make it a general-use package, but it should be designed for Juju, meeting our needs. Roger can post errgo wherever

Not logging jenv data

Today I learned CI isn't running with --debug because they don't want to expose sensitive data in their jenv... which gets logged when you run with --debug. However, it also means that we don't get all our really useful debug log messages when something breaks in CI. I made a fix for this

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

What Roger is talking about, is when an error is implementation-specific and may change if the implementation changes. For example, if you have a black box service that saves data, it might write to the network or it might write to a filesystem, but where it saves is an implementation detail.

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

a good thing). On Thu, May 29, 2014 at 3:16 PM, Nate Finch nate.fi...@canonical.com wrote: What Roger is talking about, is when an error is implementation-specific and may change if the implementation changes. For example, if you have a black box service that saves data, it might write

Re: reverting (fixing?) r2814

Talked with John etc. Sorting is really just a lazy man's out. There's no reason we can just search through the list and if localhost is there, dial that one first (actually we decided it should probably *only* dial localhost if it exists). On Sun, Jun 1, 2014 at 8:21 AM, Andrew Wilkins

Re: Being good citizens with our external repos

in the import statement of even a large number of files is not really a huge deal, especially since it can be done programmatically. -Nate On Tue, Jun 3, 2014 at 4:07 AM, roger peppe rogpe...@gmail.com wrote: On 3 June 2014 00:13, Nate Finch nate.fi...@canonical.com wrote: Right now, we change tip

Re: add dependencies step to github readme?

There's an option to pass -copy=false which won't copy over the sourcecode. I don't think we need to keep the external sourcecode in our repo, given that all our external dependencies are controlled by canonicalers (and we have N copies of the dependencies where N = the number of people who have

Re: Backup juju with/without interrupting juju

I'm not sure I understand the distinction, Curtis. Backing up the state data in an HA environment is what I was talking about for large environments. On Wed, Jun 4, 2014 at 4:12 PM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Wed, Jun 4, 2014 at 3:58 PM, Nate Finch nate.fi

naming repos on github

We're making a lot of standalone repos on github so that teams external to core can reuse core's code. I think we need to disambiguate between repos that are generally only of use when working with juju, and repos that are more general purpose. For example, errgo is a general use package that

Re: Backup juju with/without interrupting juju

I guess what I don't understand is, why does it matter which mongo DB you back up? They should all be identical, right? On Thu, Jun 5, 2014 at 12:58 PM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Wed, Jun 4, 2014 at 4:36 PM, Nate Finch nate.fi...@canonical.com wrote: I'm

Re: $ juju switch --format

+1 On Thu, Jun 5, 2014 at 6:16 PM, Tim Penhey tim.pen...@canonical.com 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:

Re: $ juju switch --format

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

Re: Replica sets re-enabled for local provider

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

This is why we should make go get work on trunk

(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

Re: $ juju switch --format

Ha, that's cute. Honestly, that's still difficult enough to type that I can't see people typing that every time by hand. Generally you *know* what environment you want to destroy anyway, and whatever name you picked has to be easier than typing $(juju env). But it's a useful tip for scripts.

Re: Static Analysis on Juju

That's awesome, thanks for doing that. I'm interested to see what comes out of it. On Mon, Jun 23, 2014 at 5:45 PM, Matthew Williams matthew.willi...@canonical.com wrote: Hi Folks, As some of you will be aware the latest version of go includes some static analysis tools in godoc:

gerritt dependent reviews

BTW, Gabirel, the Cloudbase guy I am working with, mentioned that gerritt allows for dependent reviews I thought some on this list might find that worth any other objections they might have with gerritt. I don't know any more about the feature than that, but I figured it was worth looking

Re: Splitting out state/api into its own repo

I think these are the results we are looking to get out of this exercise: 1. Have a well-defined and well-documented API that third parties may consume. 2. Have a clean and well-documented Go implementation of an API wrapper which third parties may reuse. 3. Make both of these easy

Re: move towards using gopkg.in

+1 for stable APIs and versioned import statements. If we're worried about the fact that gopkg.in is run by some random guy* then we're more than capable of running our own redirector on Canonical's infrastructure. Gopkg.in is open source, so we can easily get ours up and running with just a

Re: Dropbox has open sourced some of their Go libraries

I noticed that, too. Their code is unfortunately pretty dropbox-specific, but it is interesting that pretty much everyone doing big projects makes an error package. On Mon, Jul 7, 2014 at 8:04 PM, Menno Smits menno.sm...@canonical.com wrote: Hey look - another errors package! */me ducks*

Re: Devel is broken, we cannot release

I don't think we need to stop the world to get these things fixed. It is the responsibility of the team leads to make sure someone's actively working on fixes for regressions. If they're not getting fixed, it's our fault. We should have one of the team leads pick up the regression and assign

Re: Devel is broken, we cannot release

we've got enough evidence that the alternative really doesn't fly effectively). Cheers William On Tue, Jul 15, 2014 at 9:37 AM, Nate Finch nate.fi...@canonical.com wrote: I don't think we need to stop the world to get these things fixed. It is the responsibility of the team leads

Re: Log Rotation

). This is then handled by our upstart scripts and redirected into a file. I *think* there are upstart hooks for log rotation as well, but I may well be wrong on that. Tim On 18/07/14 08:27, Nate Finch wrote: So, as below, there is a request (again) to do log rotation. For all-machines.log

beware using godeps to generate dependencies.tsv

With the recent addition of npipe (a windows named pipe package), godeps can no longer be relied upon to report the full list of dependencies for juju. Godeps is currently platform-specific, so it'll generate the dependencies for the current platform, but it won't generate dependencies included

  1   2   3   >