Re: lxd and constraints

onstraints aren't satisfied. (but warn isn't failing the attempt) John =:-> On Fri, Jan 13, 2017 at 10:09 AM, Stuart Bishop <stuart.bis...@canonical.com > wrote: On 13 January 2017 at 02:20, Nate Finch <nate.fi...@canonical.com> wrote: I'm implementing constraints for lxd containers

Re: lxd and constraints

y any unit to the host machine, or if you deploy a unit in a container without a RAM constraint. Those units may then use as much RAM as they want. On Thu, Jan 12, 2017 at 3:22 PM Mike Pontillo <mike.ponti...@canonical.com> wrote: On Thu, Jan 12, 2017 at 11:20 AM, Nate Finch <nate.

lxd and constraints

I'm implementing constraints for lxd containers and provider... and stumbled on an impedance mismatch that I don't know how to handle. It seems as though lxd limits (what in juju we would call constraints) are implemented as maximums, not minimums. For containers sharing a host, this makes

Representative tests failing

Seems like there's a likely out of disk space problem with the LXD and windows machines that run representative tests. For example: http://juju-ci.vapour.ws/job/github-check-merge-juju/441/ http://juju-ci.vapour.ws/job/github-check-merge-juju/442/ Sounds like this happens often enough to be a

Re: One instance manual provider

Except you can't expose anything deployed to lxd to the network, right? On Mon, Dec 5, 2016, 5:49 PM Marco Ceppi <marco.ce...@canonical.com> wrote: > A one machine manual provider? Might as well just `ssh ; juju > bootstrap lxd`. > > On Mon, Dec 5, 2016 at 10:09 AM N

Re: Application names starting with digits

r the name of their software is not very welcoming in this day and age. On Fri, Dec 2, 2016 at 10:46 AM Marco Ceppi <marco.ce...@canonical.com> wrote: > On Fri, Dec 2, 2016 at 10:31 AM Nate Finch <nate.fi...@canonical.com> > wrote: > > One thing we *could* do to su

Re: Application names starting with digits

One thing we *could* do to support non-english names that would not entirely open the door to emoji etc is to simply constrain the names to unicode letters and numbers. Thus you could name something 數據庫 but not . On Fri, Dec 2, 2016 at 9:29 AM Mark Shuttleworth wrote: > On

Re: Application names starting with digits

There's no technical reason for the restriction, AFAIK. I believe it's just aesthetic. On Fri, Dec 2, 2016, 5:50 AM James Page wrote: > Hi All > > Is there a specific rationale for application names being limited to not > starting with a digit? I get why they can't end

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

A (Very) Minimal Charm

On IRC, someone was lamenting the fact that the Ubuntu charm takes longer to deploy now, because it has been updated to exercise more of Juju's features. My response was - just make a minimal charm, it's easy. And then of course, I had to figure out how minimal you can get. Here it is: It's

Re: "unfairness" of juju/mutex

Just for historical reference. The original implementation of the new OS mutex used flock until Dave mentioned that it presented problems with file management (files getting renamed, deleted, etc). In general, I'm definitely on the side of using flock, though I don't think that necessarily

Re: Dependencies added for new jsonschema support

Thanks, Katherine, I had intended to mention in the email that this was a request for review by the tech board :) On Tue, Nov 1, 2016, 5:14 PM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Nate Finch <nate.fi...@canonical.com> writes: > > > In su

Dependencies added for new jsonschema support

In support of my PR that adds an interactive mode for add-cloud, we needed to add jsonschema for the cloud configurations that can be inspected at runtime to generate the interactive queries. Unfortunately, the jsonschema package we're currently using

Long tests

I ran the tests serially today to try to get a picture of what tests actually take a long time without worrying about contention. The full run took almost 45 minutes (normally it takes like 15 testing packages in parallel). Here's the full output (sorry for the google drive link, pastebin got

Re: Big memory usage improvements

FYI, this tools looks promising. Probably worth checking out to see if it'll help us track down those memory leaks. https://stackimpact.com/blog/memory-leak-detection-in-production-go-applications/ On Thu, Oct 13, 2016 at 8:02 AM Christian Muirhead < christian.muirh...@canonical.com> wrote: >

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: Reviews on Github

of >>>> the team and not the codebase. >>>> >>>> I just want some consistency until a decision is made. E.g. "we will be >>>> trying out GitHub reviews for the next two weeks; all reviews should be >>>> done on there". >>>

Re: Reviews on Github

iewed and what hasn't. > > -- > Katherine > > Nate Finch <nate.fi...@canonical.com> writes: > > > In case you missed it, Github rolled out a new review process. It > > basically works just like reviewboard does, where you start a review, > > batch up comment

Re: Reviews on Github

r one would miss all the features reviewboard > >> offers. > >> Unless there's a way of doing the same thing in github that I'm not > aware > >> of. > >> > >> On 15/09/16 07:22, Tim Penhey wrote: > >>> I'm +1 if we can remove the extr

Reviews on Github

In case you missed it, Github rolled out a new review process. It basically works just like reviewboard does, where you start a review, batch up comments, then post the review as a whole, so you don't just write a bunch of disconnected comments (and get one email per review, not per comment).

Re: Latest new about Juju master branch - upload-tools obsoleted

Just a note, because it wasn't clear to me - there are a couple cases where the automatic upload tools won't do what you want, if you use a version of juju you built locally. If you're not a developer or someone who builds juju from source, it's safe to ignore this email. *1. If the version of

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: Latest new about Juju master branch - upload-tools obsoleted

Ian, can you describe how Juju decides if it's running for a developer or an end user? I'm worried this could trip people up who are both end users and happen to have a juju development environment. On Mon, Aug 15, 2016 at 11:29 AM Mark Shuttleworth wrote: > On 15/08/16 08:27,

Re: So I wanted to update a dependency . .

to import "gnuflag" instead Also, if there are any third party packages that use one of the same dependencies we do, we'd need to edit those files, too... On Fri, Aug 12, 2016 at 2:31 PM Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > On Fri, Aug 12, 2016 at

Re: So I wanted to update a dependency . .

to keep backwards compatible, then these problems would be minimized. On Fri, Aug 12, 2016 at 1:56 PM roger peppe <roger.pe...@canonical.com> wrote: > On 12 August 2016 at 14:11, Nate Finch <nate.fi...@canonical.com> wrote: > > No other repo should ever depend on github.com/

Re: Let's talk retries

So, in my opinion, juju/retry is pretty good. I think with some tweaking and some intelligent use, it can feel every bit as lightweight as we'd like. If we have common use cases, we just need to write up an API to encapsulate them. If we want a "retry N times or until this channel is closed"

No help Topics in 2.0

Juju 1.x had a ton of help in the CLI, right at your fingertips: $ juju1 help topics azure-provider How to configure a Windows Azure provider basics Basic commands commandsBasic help for all commands constraints How to use commands with constraints

Re: Cleansing Mongo data

It seems as though we should be cleansing all the keys since we never know what queries we might want to make in the future. On Fri, Jun 24, 2016 at 12:04 PM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > > As I have only just discovered the need to cleanse mongo data, I

Re: fslock is dead, long live mutex

> painful field bugs. Thank you for taking the extra effort to do this work! > > Also thank you to Nate Finch and David Cheney for their contributions on > this effort. > > On Tue, Jun 21, 2016 at 2:24 AM, Tim Penhey <tim.pen...@canonical.com> > wrote: > >> Hi fol

Tests do not pass with go1.7

Just FYI, in case anyone was like me and decided they wanted to jump on the faster compile times in 1.7... some of our tests do not pass in go 1.7: https://bugs.launchpad.net/juju-core/+bug/1589350 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

version parsing

a bug was discovered in our version parsing: https://bugs.launchpad.net/juju-core/+bug/1588911 basically, 2.0.alpha10 was being parsed as the tag being alpha1 and the patch being 0, instead of alpha and 10. While correcting this problem, I noticed that we were matching [a-zA-Z0-9_]+ for the

Re: list, show and get (was Re: Fixing "juju help commands")

easily differentiated names, unlike plural vs singular, which actually might be confusing if they only differed by an s. On Tue, May 24, 2016, 6:45 PM Tim Penhey <tim.pen...@canonical.com> wrote: > On 25/05/16 01:49, Nate Finch wrote: > > While we're on the subject... we have list-

Re: Fixing "juju help commands"

If there are things we really don't want uses to run, they should probably just not exist in production builds. If they're just less-used commands, then I don't think it's a big deal to have them in juju help commands. If we want to remove them from production builds, they could either be

Re: natefinch/npipe/v2 does not support the POSIX read/close semantics juju needs

Ug.. I'll look at this tomorrow (12:30 is a bad time for me to be diving into windows API BS) On Mon, May 23, 2016 at 11:40 PM David Cheney wrote: > TL;DR read issue https://bugs.launchpad.net/bugs/1581337 > > Thumper asked me to forward this to juju-dev for

Re: Specifying bootstrap machine agent details using ip address

Hostname or IP address will both work. On Mon, May 23, 2016 at 1:11 AM phani shankar wrote: > Hi, > > I am new to juju. I was following > https://jujucharms.com/docs/stable/config-manual document to do manual > provisioning. While configuring environment.yaml,

Re: Three CI builds in the last 48 hours have failed because launchpad had a lie down

I agree. We should snapshot a known-good starting point and start from there. It's a huge waste of time to do apt update / upgrade / install git, bzr, mercurial, etc every single time we run CI. That's like 1/3rd the time it takes to run the unit test CI job. On Wed, May 18, 2016 at 10:35 PM

Re: Static Analysis tests

1, 2016 at 10:27 PM Andrew Wilkins <andrew.wilk...@canonical.com> wrote: > On Thu, Apr 28, 2016 at 11:48 AM Nate Finch <nate.fi...@canonical.com> > wrote: > >> Maybe we're not as far apart as I thought at first. >> > > >> My thought was that th

Re: adding unit tests that take a long time

On Thu, Apr 28, 2016 at 11:44 PM Anastasia Macmood < anastasia.macm...@canonical.com> wrote: > I understand your desire for a quick turn around. > But I question the value that you would get from running "fast" (short) > tests - would this set include some fast running unit tests, integration >

Re: adding unit tests that take a long time

ts tests behaviour; > static analysis analyses codebase to ensure conformity to agreed policies. > > They all have meaning at different stages of development and to bundle > them based on the running time is to compromise these stages in long-term. > > > On 29/04/16 05:03, Nate Fin

Re: adding unit tests that take a long time

kaggs < nicholas.ska...@canonical.com> wrote: > On 04/28/2016 10:12 AM, Katherine Cox-Buday wrote: > > On 04/27/2016 09:51 PM, Nate Finch wrote: > >> So, this is exactly why I didn't want to mention the nature of the > >> test, because we'd get sidetracked. I'll make

Re: Static Analysis tests

at 11:39 PM Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Thu, Apr 28, 2016 at 11:14 AM Nate Finch <nate.fi...@canonical.com> > wrote: > >> From the other thread: >> >> I wrote a test that parses the entire codebase under github.com/juju/juju to

Static Analysis tests

>From the other thread: I wrote a test that parses the entire codebase under github.com/juju/juju to look for places where we're creating a new value of crypto/tls.Config instead of using the new helper function that I wrote that creates one with more secure defaults. It takes 16.5 seconds to

Re: adding unit tests that take a long time

op, but I do have a question. > > On 04/27/2016 12:24 PM, Nate Finch wrote: > > I just wrote a test that takes ~16.5 seconds on my machine. > Why does the test take so long? Are you intending it to be a short / > small scoped test? > > Nicholas > -- Juju-dev mailin

adding unit tests that take a long time

I just wrote a test that takes ~16.5 seconds on my machine. Since we are trying to *reduce* the time taken by tests, I think it's prudent to give developers a way to avoid running longer tests (obviously things like the landing bot etc should always run all the tests). What I *don't* want is to

two new helpers in github.com/juju/testing

I added a couple new helpers to the testing repo that I think will help us avoid some of the contortions we have had to do in the past when testing executables and output on stderr/stdout. The first is a fairly simple function, CaptureOutput

Re: LXD polish for xenial

Thanks for explaining, John, that makes sense and really helps me understand the reasoning behind these changes. On Tue, Apr 19, 2016 at 11:30 PM John Meinel <j...@arbash-meinel.com> wrote: > On Tue, Apr 19, 2016 at 6:56 PM, Nate Finch <nate.fi...@canonical.com> > wrote: &

Re: LXD polish for xenial

Then I guess I don't understand why it worked fine up until last week. On Tue, Apr 19, 2016, 10:39 AM Tycho Andersen <tycho.ander...@canonical.com> wrote: > On Tue, Apr 19, 2016 at 01:42:08PM +0000, Nate Finch wrote: > > On Tue, Apr 19, 2016 at 7:49 AM John Meinel <j...

Re: LXD polish for xenial

On Tue, Apr 19, 2016 at 7:49 AM John Meinel wrote: > ... >>> >> > >> >>> That's probably the cause of the other confusion in the updated docs - >>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user >>> already has lxc setup in some fashion there's a

Re: Thunderbirds are Go 1.6

Glorious. Thanks so much for all the work, Michael and Curtis and team! On Sun, Apr 10, 2016, 1:16 PM Cheryl Jennings wrote: > Thank you for all your work on this, Curtis! > > On Sun, Apr 10, 2016 at 11:55 AM, Curtis Hovey-Canonical < > cur...@canonical.com>

Re: Unable to kill-controller

to destroy the controller, it will just remove the > > details of it from the client. > > > > (Alternative suggestion for spelling: "juju > > forget-controller". Purge-controller may suggest that > >

Re: Unable to kill-controller

nt 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 back to the provider. I was >> joking when I suggested yesterday in IRC that we sh

Re: Unable to kill-controller

, Apr 6, 2016 at 10:48 AM Aaron Bentley <aaron.bent...@canonical.com> wrote: > -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

Re: Unable to kill-controller

Wait, didn't destroy-environment --force fall back to the provider? I thought that was the whole point of --force On Wed, Apr 6, 2016 at 10:24 AM Aaron Bentley wrote: > On 2016-04-06 08:22 AM, Andrew Wilkins wrote: > > What I would like to see is: *

Re: Unable to kill-controller

just in case, but I > don't know if this extends to other non English speakers too. > > On Wednesday, 6 April 2016, Nate Finch <nate.fi...@canonical.com> wrote: > >> Also +1 to Andrew's proposal. In particular, the difference between kill >> and destroy is pretty arbit

Re: Unable to kill-controller

> >>>>> We should provide a way to clean up controllers without making the >>>>> user manually edit juju's files. >>>>> >>>> >>>> Unless anyone objects, or has a better spelling, I will be adding a >>>> command to do this: &

Re: Unable to kill-controller

ike >>>> kill-controller. It will not attempt to destroy the controller, it will >>>> just remove the details of it from the client. >>>> >>>> (Alternative suggestion for spelling: "juju forget-controller". >>>> Purge-controller may

Re: Unable to kill-controller

This just happened to me, too. Kill-controller needs to work if at all possible. That's the whole point. And yes, users may not hit specific problems, but devs do, and that wastes our time trying to figure out how to manually clean up the garbage. On Mon, Apr 4, 2016 at 8:33 AM Rick Harding

Re: Go 1.6 is now in trusty-proposed

I'll just note that we've had flaky tests for as long as I've been working on Juju, and there's never a "good" time to fix them. :) On Mon, Mar 28, 2016 at 11:48 AM Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2016-03-28 09:03 AM,

Re: Go 1.6 is now in trusty-proposed

+1, don't retry... devs need to feel the pain in order to get proper motivation to fix this stuff... On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Just wanted to say thank you 100x to all involved! > > On 03/24/2016 01:03 AM, Michael

Re: Go 1.6 is now in trusty-proposed

Does this mean we can assume 1.6 for everything from now on, or is there some other step we're waiting on? I have some code that only needs to exist while we support 1.2, and I'd be happy to just delete it. On Thu, Mar 24, 2016, 4:07 AM Tim Penhey wrote: > Awesome

Re: Master is blocked in preparation for 2.0-beta3

May I ask why we're not making a branch for beta3, so work may continue on master? On Tue, Mar 22, 2016 at 1:07 PM Cheryl Jennings < cheryl.jenni...@canonical.com> wrote: > Hi Everyone, > > Master is currently blocked to allow us to get to a stable 2.0-beta3. > While we are working towards that

juju versions are now in github.com/juju/version

For a recent change in 2.0, we needed to be able to reference the version.Number struct from both juju-core and charm.v6. In order to support this, we moved most of the contents of github.com/juju/juju/version to at top level repo at github.com/juju/version. Note that certain juju-core-specific

Re: Diffing string checker

I agree with Horacio, you're my hero, Andrew. I was actually just looking at sergi's diffmatchpatch implementation for exactly this purpose a couple days ago. Thanks for doing that! On Thu, Feb 25, 2016 at 6:09 AM Andrew Wilkins wrote: > On Thu, Feb 25, 2016 at

Re: Please merge master into your feature branches

So uh... how are we going to deliver patches to 1.25 if CI can't run it? On Thu, Feb 18, 2016 at 9:48 PM Andrew Wilkins wrote: > On Fri, Feb 19, 2016 at 10:03 AM Ian Booth > wrote: > >> FYI for folks developing feature branches for

Re: Introducing, juju resources!

One idea is to have a resource type of "directory" and upload everything in that directory. The current code has only one resource type - file. But it's copied to a directory on the unit named by the resource. So it would be pretty easy to jnstsd copy a number of files to that directory. Of

Re: Juju terminology change: controllers and models

FYI, I noticed ServiceDeployWithNetworks still exists as a client and facade method, but it's only called by tests. Maybe it should be removed? On Tue, Feb 2, 2016, 8:34 PM Ian Booth wrote: > Hey all > > As has been mentioned previously in this list, for the Juju 2.0

Re: Build errors

Juju is not structured to work with go get, per se. Please see the contributing document for details on building juju: https://github.com/juju/juju/blob/master/CONTRIBUTING.md On Mon, Feb 1, 2016 at 1:33 PM Neale Ferguson wrote: > I built juju a few weeks ago and

Re: Tags and object IDs

, Jan 25, 2016 at 2:00 AM John Meinel <j...@arbash-meinel.com> wrote: > On Sat, Jan 23, 2016 at 1:28 AM, William Reade < > william.re...@canonical.com> wrote: > >> On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch <nate.fi...@canonical.com> >> wrote: >> >>

Re: Defaulting tests internal to the package

I think the idea that tests of an internal function are worthless because you might just not be using that function is a fairly specious argument. That could be applied to unit tests at any level. What if you're not using the whole package? By that logic, the only reliable tests are full stack

Re: Tags and object IDs

ecause we've already got the globalKey convention; in worker code > it's often justifiable if not exactly awesome. See > https://github.com/juju/juju/wiki/Managing-complexity#workers > > Cheers > William > > On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch <nate.fi...@canonical.com>

Re: Defaulting tests internal to the package

I'm glad to hear Roger's opinion about testing internal code... that's exactly how I feel. True unit tests of small bits of code are easy to write, easy to read and understand, and give you confidence that your code is doing what you think it'll do in a wide variety of cases. If the unit test

Tags and object IDs

I have a function that is recording which unit is using a specific resource. I wrote the function to take a UnitTag, because that's the closest thing we have to an ID type. However, I and others seem to remember hearing that Tags are really only supposed to be used for the API. That leaves me

Defaulting tests internal to the package

[reposting this to the wider juju-dev mailing list] So, I hit an interesting problem a while back. I have some unit tests that need to be internal tests, thus they are in 'package foo'. However, my code needs to use some testhelper functions that someone else wrote... which are in 'package

Re: Copyright headers for auto-generated files?

So, two things: 1.) We don't need to worry about this anymore, since I've removed the need for the generated code. But to clarify, I was using stringer ( https://github.com/golang/tools/blob/master/cmd/stringer/stringer.go) which generates files with String() methods for enums. 2.) There's like

Re: 1st time builder

Usually if there are compile time issues, it's because you haven't run godeps yet. Make sure you've done the steps under this section of the docs: https://github.com/juju/juju/blob/master/CONTRIBUTING.md#godeps go-get by default pulls from the head of every git repo, but to keep our builds

Re: Starting a new CI test

That is amazing and awesome. Thanks, Martin and everyone else who helped with this! Lowering the barrier of entry to writing CI tests can only be a good thing. On Thu, Dec 17, 2015 at 1:00 PM Martin Packman wrote: > I just added a cheaty way of getting started on

Re: Comprehensive reviews & when to do them?

I think that as long as we make it clear what kind of review we're asking for, and make sure that we really do follow up on review comments, that we can have the best of both worlds. I do think that reviewing once all the code is done is kind of fruitless... there's a lot more impetus to just

Re: Be very careful in assumptions in tests

I'll definitely +1 the need for gc.HasLen ... I've seen a ton of panics in tests if the code starts erroneously returning nil slices. Obviously this is less bad, since the tests still fail, but they're really ugly annoying failures. And +1000 to making tests that fail before fixing the code (or

Re: apiserver authorizers

Auth on the api is a big mystery to me. Is there a document on the expected behavior and the functions and types that back it up? For example, you said "an environ provisioner may have wide-ranging powers, but that's no reason to let it see or modify container machines that are not its direct

Re: utils/fslock needs to DIAF

.pe...@canonical.com> wrote: > On 1 December 2015 at 16:43, Nate Finch <nate.fi...@canonical.com> wrote: > > I think half the problem is that someone named the package fslock and not > > oslock, so we're stuck asking the wrong question. > > > > If the questio

Re: utils/fslock needs to DIAF

or bradfitz would > probably be amenable to a PR. > > cheers, > rog. > > On 1 December 2015 at 04:12, Nate Finch <nate.fi...@canonical.com> wrote: > > I'm not a linux expert, but definitely a named mutex is exactly the > correct > > thing to use for Window

Re: lxd provider in master

I guess we don't error out when we see duplicate environment names? Shouldn't we? On Mon, Nov 23, 2015 at 6:47 PM Tim Penhey wrote: > >> In environments.yaml file I added a very simple clause: > >> > >>lxd: > >> type: lxd > > > > found that further down the

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

You're not selling me on this ;) On Tue, Oct 27, 2015, 4:01 PM Tim Penhey wrote: > I can't help but draw parallels to the plugin system. > > There was considerable resistance to adding the ideas of plugins to > Juju. It was added complexity that no one needed and

Re: On Call Reviewer Duties

Sounds good to me. On Wed, Oct 21, 2015, 6:39 AM Matthew Williams < matthew.willi...@canonical.com> wrote: > Hey Folks, > > I propose that on call reviewers as part of their job should also review > the issues list on https://github.com/juju/juju/issues and attempt to > triage anything that's

Re: Pointer Receivers on Error() and String() methods

. On 20 August 2015 at 03:45, Nate Finch nate.fi...@canonical.com wrote: tl;dr: Don't. Use a value receiver. 99% of the time you can just delete the * on the receiver and it'll still work. If you really must use a pointer, please handle the case where you're called with a nil receiver

Pointer Receivers on Error() and String() methods

tl;dr: Don't. Use a value receiver. 99% of the time you can just delete the * on the receiver and it'll still work. If you really must use a pointer, please handle the case where you're called with a nil receiver. I spent most of today trying to understand why my new hook command was

Re: New dependency

Just some context - Ben Johnson is an active member of the Go community, works in Go every day, and has several popular packages in use by many third parties. I would not worry about depending on his work from a quality or responsiveness aspect. As with John, I haven't looked at the exact code,

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 12:42 AM Tim Penhey tim.pen...@canonical.com wrote: Aside from all this work, it is becoming REALLY IMPORTANT that we stop writing terrible, wasteful, full integration type tests when what we really care about testing is some aspect of uniter internals. I know that it

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 10:57 AM roger peppe rogpe...@gmail.com wrote: On 20 July 2015 at 14:11, Martin Packman martin.pack...@canonical.com wrote: The logs are giant, the actual failure lines tend to be non-informative with the real cause several screens up in the log, multiple tests

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 3:05 PM roger peppe roger.pe...@canonical.com wrote: On 20 July 2015 at 19:41, Nate Finch nate.fi...@canonical.com wrote: You should be able to get to 80% code coverage (and near 100% logic coverage) without using anything outside your package. Shouldn't those

Re: A cautionary tale about go test -race -cover

Thanks for the info, Dimiter. That is almost certainly going to bite someone else at some point. On Thu, Jul 16, 2015 at 6:35 AM Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, tl;dr; When running $ go test -race -cover with

Re: Recurring fails on windows tests and the recent CentOS failure

I agree that this is the correct thing to do. However, it is error prone and non-obvious. Having a check that can ensure we do it correctly would definitely help avoid this problem in the future. Not needing to do it at all would be even better, but I understand that changing 100,000 lines of

Re: Recurring fails on windows tests and the recent CentOS failure

the cost of running all the setups and teardowns. Then we can do Roger's suggestion of ensuring that we don't forget to hook up setup and/or teardown. On Wed, Jul 15, 2015 at 3:31 PM William Reade william.re...@canonical.com wrote: On Wed, Jul 15, 2015 at 7:19 PM, Nate Finch nate.fi

Re: Blocking bugs process

I think everyone's agreeing here, but maybe the wording just needs to be clarified somewhere to avoid confusion. It sounds like bugs which are assigned to a release do not block commits unless they are marked blockers. And blockers are determined by we wouldn't want *anyone* to upgrade to a

Re: Blocking bugs process

Can you put this in the wiki? On Thu, Jul 9, 2015 at 6:33 PM Martin Packman martin.pack...@canonical.com wrote: The QA team have been trying to hammer out a clearer process over blocking bugs, and have put together the document below for discussion. We'll be handling bugs as described here

like go test, but faster

Russ Cox has an experimental command called gt, which replaces the go test tool, and caches test output when you run it. The next time you run gt, if none of the files in a package have changed and none of the files of packages it depends on have changed, then gt will just reprint the cached

Re: Reminder: on June 15th, Go 1.4 will stop compiling things from code.google.com.

If you git clone the new repo into the old path on disk, that should just work with godeps etc. On Jun 2, 2015 8:15 AM, John Meinel j...@arbash-meinel.com wrote: What about old releases, etc? It seems like this is potentially an issue if we ever want to build an old release (for reference

Re: Writing workers

Totally belongs on the wiki. On Mon, Jun 1, 2015 at 8:45 AM, John Meinel j...@arbash-meinel.com wrote: This is one of those things that should probably end up on the Wiki. Thanks for writing it up. John =:- On Thu, May 28, 2015 at 5:34 PM, William Reade william.re...@canonical.com

Docs in-repo vs. github wiki

I just created a wiki page on the juju github repo to hold the information I typed up about running and writing CI tests, from my experience of the last week or so: https://github.com/juju/juju/wiki/ci-tests It occurs to me that much of the documentation that we have in files inside the repo

Re: Resolving the same windows test failures again

Sorry for the lack of tests for that part of the code, I guess I added them for one and not the other. Note that I had actually been leaving that PR unmerged because I knew master was blocked. Sorry it got pushed in anyway, and caused problems. On Mon, May 4, 2015 at 7:20 PM, Martin Packman

  1   2   3   >