Re: Juju trunk now is compatible with Mongo 2.6

lly be separate. > > On 15/08/14 11:11, David Cheney wrote: >> Will CI failures using mongodb-2.6 be considered critical and block the >> build ? >> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: First customer pain point pull request - default-hook

Nope, still not receiving you clearly On Mon, Aug 18, 2014 at 7:20 AM, Tim Penhey wrote: > -BEGIN PGP MESSAGE- > Charset: windows-1252 > Version: GnuPG v1 > > hQIMA233D38ktbXXAQ/+OxwEOmqX/SS+lyJGh7WBYOZge3P8G9+bdu0u8v/sGioD > xbPcpRAp4D3GaCyaMS231JTdvWjMgegw9f6AnnaeLiEdcmFi3YBEzvnDCR5+Lfp

Re: The tests now run godeps

Lets' revert this change please. I don't think this change pays for itself; the bot already runs godeps from a *clean* working copy so there is no danger of it commiting using the wrong deps and Tim has identified the make targets for developers to check their own local working copy. On Thu, Aug

Re: getting rid of all-machines.log

Hi Horatio, I don't see a way to resolve the very disparate set of opinions you've highlighted below. It's also not clear from your email who is responsible for making a decision. I suggest reframing the discussion as user stories. ie * As a Juju user with a Windows workstation I want to use juj

Re: getting rid of all-machines.log

On Wed, Aug 27, 2014 at 3:04 PM, Ian Booth wrote: > > > On 27/08/14 14:56, John Meinel wrote: >> My personal vote would be: >> a) Use something that can write directly to multiple syslog receivers over >> a TLS encrypted connection from inside the jujud binary (e.g. don't use >> rsyslog to read th

Re: gccgo internal compiler errors

nah, we have a fix upstream, we just need to get that backported to trusty then this becomes a non issue. On Fri, Aug 29, 2014 at 7:44 PM, Matthew Williams wrote: > As it's something we need to be doing for a while yet is there value in > adding this as a task that gets run by the landing bot? >

State should not depend on the API server

Hello, This is an introductory email to explain my upcoming series of pull requests. The theme is simple: state must not depend on the api server. This is currently not true, state depends on api/params because some of the api types have leaked into the state package and are being directly store

Re: State should not depend on the API server

r for use > in the Agents/Clients. > > John > =:-> > > > > On Mon, Sep 1, 2014 at 9:40 AM, David Cheney > wrote: >> >> Hello, >> >> This is an introductory email to explain my upcoming series of pull >> requests. >> >> The theme is

Re: State should not depend on the API server

Thanks William, On a related note, I'm also planning on moving api/params to apiserver/params; these are the server's parameters, not the client's. On Mon, Sep 1, 2014 at 5:12 PM, William Reade wrote: > On Mon, Sep 1, 2014 at 8:03 AM, John Meinel wrote: >> FWIW I'd favor 3 layers, though it doe

Re: Logger prefixes for api/apiserver are changing

Wow. I'm sorry I broke that, it didn't even occur to me. I wonder if there is a better way to handle this default case of "the name of the logger follows the package path"), ie var logger = loggo.Logger("") // or something, it could be a new method, logger.Default(), or something. which will ins

Re: Logger prefixes for api/apiserver are changing

I'll take thumper's temperature for this feature at the standup and see what he thinks. On Wed, Sep 3, 2014 at 12:30 AM, Eric Snow wrote: > On Tue, Sep 2, 2014 at 5:07 AM, David Cheney > wrote: >> I wonder if there is a better way to handle this default case of &quo

Re: Copyright information in headers

I think this is needless busy work, I vote that as long as there is a copyright header with _a_ year, that is sufficient. On Thu, Sep 4, 2014 at 7:50 AM, Ian Booth wrote: > Hi folks > > The question recently came up in reviews as to whether we should be updating > the > date in the copyright sta

Re: A beginner's adventure in Charm authoring

On Fri, Sep 5, 2014 at 5:04 AM, Nate Finch wrote: > given that we currently use the path, you can't have one charm for multiple > series anyway. For deploying local: charms, symlinks work fine here. > This would at least be better than what we have right now, > and would be backwards compatible

Re: Juju landing tests - good news

\o/ Thanks to everyone for the effort. On Thu, Sep 11, 2014 at 5:15 PM, Ian Booth wrote: > Hi folks > > It's been a fantastic effort so far improving the quality of our tests; so > much > so that this time yesterday I switched off the retry flag. This means that our > landing tests run at full s

Re: ReviewBoard is now the official review tool for juju

Is there a setting to make reviewboard show the diff in a review by the default ? For some reason for me it always requires me to hit the 'view diff' link. On Tue, Sep 16, 2014 at 6:39 AM, Ian Booth wrote: > > > On 16/09/14 00:50, Eric Snow wrote: >> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wr

Re: State should not depend on the API server

On Tue, Sep 16, 2014 at 7:59 PM, William Reade wrote: > On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote: >> I don't see how having different identical structs that are updated >> simultaneously in any way prevents any problems with compatibility. > > If we're updating those structs simultaneous

Re: ReviewBoard is now the official review tool for juju

On Tue, Sep 16, 2014 at 7:27 PM, roger peppe wrote: > On 16 September 2014 09:22, Jonathan Aquilina wrote: >> If i am not mistaken if you have multiple commits in a branch git has >> something built in called git squash. This obviously eliminates the 5 step >> process into one merge and one push.

Re: Doing chained diffs w/ Reviewboard

+1 to that On Thu, Sep 18, 2014 at 7:53 PM, Adam Collard wrote: > On 18 September 2014 10:49, John Meinel wrote: >> >> Has anyone succeeded in getting this to work? >> >> The steps I tried to do were: >> >> git co master >> git pull upstream master >> git co base-branch >> git diff master...

Re: Doing chained diffs w/ Reviewboard

, Sep 18, 2014 at 9:03 PM, David Cheney wrote: > +1 to that > > On Thu, Sep 18, 2014 at 7:53 PM, Adam Collard > wrote: >> On 18 September 2014 10:49, John Meinel wrote: >>> >>> Has anyone succeeded in getting this to work? >>> >>> The steps I tri

Re: Doing chained diffs w/ Reviewboard

and the diff body and push that. On Thu, Sep 18, 2014 at 9:06 PM, David Cheney wrote: > Also, be watchful for the other reviewboard footgun, paged diffs. > > Reviewboard pages large reviews, so if you're used to thinking 'phew, > i've gotten to the end of the page, i&#x

Re: Is ReviewBoard a good thing?

There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt to live with the first issue On the second, github now does nice side by side diffs

Re: Is ReviewBoard a good thing?

On Sat, Sep 20, 2014 at 1:02 AM, Eric Snow wrote: > On Thu, Sep 18, 2014 at 6:32 PM, David Cheney > wrote: >> There were three problem reviewboard was supposed to address, review >> comments are sent immediately, no side by side diffs, and no way to to >> chained proposa

Re: psa pls don't use transactions for single doc unobserved atomic updates

Hi Kapil, I'm sure that the 'put everything in a transaction' pattern is applied unilaterally. Do you have some specific operations in mind ? Dave On Mon, Sep 22, 2014 at 7:46 AM, Kapil Thangavelu wrote: > Its sort of misses the point on why we're doing client side transactions. > Mongodb has

Re: Versioned packages and testing dependencies

John, Roger, This situation right here is why I am strongly opposed to the gopkg.in versioning model. I recommend reverting to the original launchpad location. Dave On Mon, Sep 22, 2014 at 9:56 PM, roger peppe wrote: > That's an interesting observation and I think I agree. > > The general rule

Is there a setting in ReviewBoard to let me see *both* the comments and the diffs

Hi Reviewboard is driving me nuts. Either it can't do this, or I have put it in some mode where it does this, but it can only show me the review comments *OR* the diff, but not both. Is there a setting that shows both diffs and the stream of review comments _on_the_same_screen ? Dave -- Juju-d

Re: how to update dependencies.tsv

Does your $GOPATH include more than one entry ? The make target should probably just expect godeps to be in your $PATH. On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov < dimiter.nayde...@canonical.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > +1, in fact there is already a

PSA: juju/utils/set/{Strings, Tags} cannot be used without initalisation

Hello, If you use set.Strings, or set.Tags, please be aware of this issue https://github.com/juju/utils/pull/84 The underlying problem is the lazy initialisation would not work in all cases and could cause data written to a set to be dropped. Please refer to the pull request for details. The co

Please stop adding dependencies to the state package

Hello, Please stop adding dependencies to the state package. The dependency tree for state must go mgo <- state <- things that depend on state At the moment state depends on things like backups, multiwatchers, presence, toolstorage. This is wrong. Eric, i'm not picking on you here, it's just

Re: Please stop adding dependencies to the state package

This is https://bugs.launchpad.net/juju-core/+bug/1392520 I have assigned it to myself. On Fri, Nov 14, 2014 at 10:33 AM, Eric Snow wrote: > On Thu, Nov 13, 2014 at 4:05 PM, David Cheney > wrote: >> Hello, >> >> Please stop adding dependencies to the state package. &

Re: Too space, or not two space

To quote Butterick's http://practicaltypography.com/one-space-between-sentences.html "> I think two spaces look bet­ter so that’s what I’m go­ing to use. I’m telling you the rule. If you want to put per­sonal taste ahead of the rule, I can’t stop you. But per­sonal taste doesn’t make the rule eva

Re: Too space, or not two space

> I think you guys have more things to worry about than the spacing style for > comments. I'm happy to let this discussion die at this point. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: git clients vulnerability found

Fortunately all of us run an operating system with a case sensitive file system, right ? On Fri, Dec 19, 2014 at 8:32 AM, Horacio Duran wrote: > Heads up people > https://github.com/blog/1938-vulnerability-announced-update-your-git-clients > apparently there is a vulnerability in git client that

Re: separating out golang juju client from

There is no reason for the 130 (at last count) packages that constitute juju-core (not counting the dozens of other packages we bring in as dependencies) to live in the same repository. If licensing is the lever that we use to break up this monolithic repository, consider me +1 On Fri, Dec 19, 20

What are blocks ?

Hello, Can someone direct me to the design documents for the enigmatic 'block' functionality which is showing up in the review queue. Thanks Dave -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Please close your old reviews

Hello, If you have a review that has been submitted, or abandoned, please use reviewboard to make that review as such and remove it from the dashboard. There are reviews at the bottom of the queue that have not been updated for excess of 60 days. Thanks Dave -- Juju-dev mailing list Juju-dev@

Re: What to do about go fmt 1.4 ?

alias jc='cd /home/dfc/src/github.com/juju/juju' works for me On Wed, Mar 11, 2015 at 10:30 PM, Nate Finch wrote: > Maybe the answer is not to use a symlink? I use $CDPATH=$GOPATH/src which > lets me do cd github.com/juju/juju and gets me to the right spot from > anywhere. > > That's not to say

Please, no more types called "State"

lucky(~/src/github.com/juju/juju) % pt -i type\ State\ | wc -l 23 Thank you. Dave -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Testing on windows

It is clear that we need blocking CI jobs for Windows and CentOS -- has this been added to the Nuremberg agenda ? On Thu, Mar 19, 2015 at 10:24 PM, Gabriel Samfira wrote: > On 19.03.2015 12:07, Michael Foord wrote: >> >> Do all tests pass (or skip) on Windows now? Do we have a CI job >> running t

Re: Proposal: move package replicaset to its own GitHub repo

Do it! On Wed, Mar 25, 2015 at 9:22 PM, Nate Finch wrote: > +100, thanks for doing this, Andrew! > > On Wed, Mar 25, 2015 at 6:16 AM, roger peppe > wrote: >> >> This seems like a grand plan to me. >> >> On 25 March 2015 at 08:12, Andrew Wilkins >> wrote: >> > I'd like to move the replicaset pac

Re: please check your spam folders

"Be careful with this message. Many people marked similar messages as spam. Learn more" Looks like this was deliberate On Fri, Mar 27, 2015 at 1:57 PM, Nate Finch wrote: > I recently sent an email about backporting changes to repos that use gopkg, > but I've gotten a report that it got send to

linux/arm64 benchmark improvements

Hello, Here are the results of the work Aram and I did last week on improving the performance of our arm64 port of Go. This is comparing the build from April 06 (before we started) to today (April 16th). http://paste.ubuntu.com/10831430/ Cheers Dave -- Juju-dev mailing list Juju-dev@lists.ubu

Re: Public Service Annoucement

Why doesn't the bot run this hook ? On Fri, Apr 24, 2015 at 9:54 PM, Matthew Williams wrote: > There's a very useful pre-push hook available for juju that does useful > things like run gofmt, go vet, checks we can build etc. > > If you don't have it setup there's some lovely instructions in > Con

Re: Public Service Annoucement

ject the merge if it changed things. (As I > understand it) > > John > =:-> > > On Fri, Apr 24, 2015 at 3:56 PM, David Cheney > wrote: >> >> Why doesn't the bot run this hook ? >> >> On Fri, Apr 24, 2015 at 9:54 PM, Matthew Williams >> wro

Please run your tests with -race

Hello, TL;DR - juju has lots of problems with data races, please test your code with the -race flag to ensure it doesn't get worse while we try to fix the problem. Longer version: In debugging https://bugs.launchpad.net/bugs/1456398 I found that there are multiple data races in the Juju code bas

Re: Please run your tests with -race

are writing tests in packages, > races in at least that file, an possibly that package should be fixed. > > Tim > > On 21/05/15 12:12, David Cheney wrote: >> Hello, >> >> TL;DR - juju has lots of problems with data races, please test your >> code with the -ra

Re: Please run your tests with -race

messages have changed in tip. (The "->" > issue I have reported in the golang-dev mailing list and I > have a fix pending here: https://go-review.googlesource.com/#/c/10270/ ) > > > On 21 May 2015 at 07:54, David Cheney wrote: >> Here is a report of the current rac

Re: I'm concerned

This should be achievable. go test sends SIGQUIT on timeout, we can setup a SIGQUIT handler in the topmost suite (or import it as a side effect package), do whatever cleanup is needed, then os.Exit, unhandle the signal and try to send SIGQUIT to ourselves, or just panic. On Wed, Jun 17, 2015 at 3:

Re: ppc64le timeouts cursing things

On Fri, Jul 17, 2015 at 5:08 AM, Dimiter Naydenov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 17.07.2015 12:07, James Tunnicliffe wrote: >> /me opens can of worms > Thanks for starting the discussion :) > >> >> Having spent perhaps too long trying to parallelise the running of

Re: New dependency

On Tue, Aug 4, 2015 at 4:32 PM, Dimiter Naydenov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 4.08.2015 08:54, Andrew Wilkins wrote: >> Hi, >> >> I'd like to add a new third-party dependency for testing: >> github.com/benbjohnson/clock . >>

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

Yup, I agree with Rog. This is fixing the problem in the wrong place. On Mon, Aug 24, 2015 at 5:14 PM, roger peppe wrote: > I'm afraid I'm not convinced. Declaring the Error method on the > pointer receiver is idiomatic (just grep for ' Error\(' in the Go source) > and is a useful indicator that

Re: Cheryl graduating

Congratulations Cheryl! On Tue, Sep 1, 2015 at 11:46 AM, Tim Penhey wrote: > Hi folks, > > I have been very happy with the quality of Cheryl's reviews and the time > is right for her to be considered a fully graduated reviewer. > > Thanks for all the reviews Cheryl. > > Tim > > -- > Juju-dev mail

version.Current changes

Hello, This is an informational message to explain the recent changes to version.Current. version.Current used to be a version.Binary value consisting of the version number, an architecture and a series value. As of this afternoon, version.Current is now a version.Number value; series and arch h

Re: Upgrading minimum Go version?

Martin: Can you setup a unit test job that uses Go 1.5 ? I will apply the same process I did for the -race job, to get the build voting, then reenable the tests that were skipped. On Fri, Nov 27, 2015 at 12:24 AM, Martin Packman wrote: > On 26/11/2015, Andrew Wilkins wrote: >> Hi (mostly Curtis)

Re: Upgrading minimum Go version?

Thanks Martin. I'll work on making those tests pass. On Fri, Nov 27, 2015 at 8:42 AM, Martin Packman wrote: > On 26/11/2015, David Cheney wrote: >> Martin: Can you setup a unit test job that uses Go 1.5 ? I will apply >> the same process I did for the -race job, to get the b

Re: Upgrading minimum Go version?

As of this morning, the unit tests pass on xenial (thanks to Andrew for getting them over the hump) using Go 1.5 On Tue, Dec 1, 2015 at 3:21 AM, Curtis Hovey-Canonical wrote: > On Mon, Nov 30, 2015 at 10:36 AM, John Meinel wrote: >> Given how often people still use "--upload-tools" for things li

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 10:43 AM, Tim Penhey wrote: > Hi folks, > > The fslock was a mistake that I added to the codebase some time back. It > provided an overly simplistic solution to a more complex problem. > > Really the filesystem shouldn't be used as a locking mechanism. > > Most of the code t

Re: utils/fslock needs to DIAF

Doesn't look like there is windows support, and it uses fcntl (flock) under the hood, which is what we have now. On Tue, Dec 1, 2015 at 10:55 AM, Casey Marshall wrote: > How about github.com/camlistore/lock ? > > On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey > wrote: >> >> Hi folks, >> >> The fslo

Re: utils/fslock needs to DIAF

Please no. The better way is to use an abstract unix domain socket to create a mutex. On Tue, Dec 1, 2015 at 10:56 AM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 7:43 AM Tim Penhey wrote: >> >> Hi folks, >> >> The fslock was a mistake that I added to the codebase some time back. It >> provid

Re: utils/fslock needs to DIAF

On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 7:57 AM David Cheney > wrote: >> >> Doesn't look like there is windows support, and it uses fcntl (flock) >> under the hood, which is what we have now. > > > flock isn't

Re: utils/fslock needs to DIAF

s/on windows/on linux (obviously) On Tue, Dec 1, 2015 at 11:03 AM, David Cheney wrote: > On Tue, Dec 1, 2015 at 11:00 AM, Andrew Wilkins > wrote: >> On Tue, Dec 1, 2015 at 7:57 AM David Cheney >> wrote: >>> >>> Doesn't look like there is windows support

Reviews for merges _from_ master to feature branches

Hello, Why are reviewers being created for merges from master to feature branches ? What purpose does this serve ? Thanks Dave -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reviews for merges _from_ master to feature branches

> > > On Mon, Nov 30, 2015, 7:18 PM David Cheney > wrote: >> >> Hello, >> >> Why are reviewers being created for merges from master to feature >> branches ? What purpose does this serve ? >> >> Thanks >> >> Dave >> >> --

Re: utils/fslock needs to DIAF

ator. I think it's fine to develop a lock type that does the best available for each platform using conditional compilation. On Tue, Dec 1, 2015 at 11:47 AM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 8:03 AM David Cheney > wrote: >> >> On Tue, Dec 1, 2015 at 11:00 A

Re: utils/fslock needs to DIAF

http://0pointer.de/blog/projects/locking.html In short, opening the same file twice and asserting a lock on it will succeed. On Tue, Dec 1, 2015 at 12:04 PM, Andrew Wilkins wrote: > On Tue, Dec 1, 2015 at 8:57 AM David Cheney > wrote: >> >> fcntl won't work in threa

Re: utils/fslock needs to DIAF

ny reason we need to use the exact same implementation on all OSes if >> there is something that does exactly the right thing without any finagling. >> FWIW, mutexes do die with the process: >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx >>

Re: Defaulting tests internal to the package

I agree with Nate, using external tests just adds more boilerplate. On Sat, Jan 23, 2016 at 7:23 AM, William Reade wrote: > On Fri, Jan 22, 2016 at 5:17 PM, Nate Finch > wrote: >> >> I'm glad to hear Roger's opinion about testing internal code... that's >> exactly how I feel. True unit tests of

Re: Defaulting tests internal to the package

Thanks Katherine. It's displaying a bias, but doing TDD with external tests is overcomplicated and against the spirit of the thing. It's probably not impossible, so I won't say that, but I will say the extra pomp of wiring up external tests, forwarding private functions, constants and variables, i

Re: juju 2.0-alpha2 with lxd

Unless you are building Juju from source (which it doesn't look like you are) you don't need a Go compiler installed. On Mon, Feb 15, 2016 at 11:20 AM, Marco Ceppi wrote: > Right, it's not going to work: > >> It's not so much that you don't have golang installed, it's about the >> version of gola

Re: Go 1.6 is now in trusty-proposed

THIS IS FANTASTIC NEWS MICHAEL! On Thu, Mar 24, 2016 at 5:03 PM, Michael Hudson-Doyle wrote: > Hi, > > As of a few minutes ago, there is now a golang-1.6 package in > trusty-proposed: > https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the > review and copy, Steve). > > One diffe

Re: Go 1.6 is now in trusty-proposed

Hi Martin, I was told that the Go 1.6 tests were voting, so these bugs should be blocking bugs. Is this not the case ? Thanks Dave On Fri, Mar 25, 2016 at 12:51 AM, Martin Packman wrote: > On 24/03/2016, Ian Booth wrote: >> >> Not yet. The builders and test infrastructure all need to be updat

Re: Go 1.6 is now in trusty-proposed

I know if we didn't retry constantly, the Juju tests'd never pass. But by retrying, there is no impetus to fix them. How about we stop retrying flaky tests? The blocked build get's the grease. On Mon, Mar 28, 2016 at 5:23 PM, Martin Packman wrote: > On 27/03/2016, David Ch

Re: Go 1.6 is now in trusty-proposed

On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Christensen (Canonical.com) wrote: > Never a good time to stop feature work entirely and fix what amounts to a > race prone set of tests. > > > But I would advocate building in some practices to improve the situation > incrementally: > > fixing one major

Re: I think master is leaking

If the test suite panics, especially during a tear down from a failure set up, you leak mongos and data in /tmp. I have a cron job that runs a few times a day to keep this leaking below a few gig. On Sat, Apr 9, 2016 at 8:13 AM, Horacio Duran wrote: > Hey, this is more of an open question/sharing

Re: Please run go test -race before pushing code

Is the race detector build currently running and will it block landing ? On Wed, May 11, 2016 at 6:48 AM, Cheryl Jennings wrote: > Hey everyone, > > There have been some new races showing up in the CI race detector test. As > you're making your bug fixes, please make sure you run go test -race b

go test github.com/juju/juju/state takes > 10 minutes to run

Testing this package takes 16 minutes on my machine*; it sure didn't use to take this long. What happened ? * yes, you have to raise the _10 minute_ timeout to make this test run. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mai

Re: go test github.com/juju/juju/state takes > 10 minutes to run

My environment has not changed since 14.04, so I'm probably not running mongo 3.2. On Tue, May 17, 2016 at 4:13 PM, Cheryl Jennings wrote: > Are you using mongo 3.2? (see bug > https://bugs.launchpad.net/juju-core/+bug/1573294) > > On Mon, May 16, 2016 at 9:52 PM, Davi

The mean time for a CI run has risen to 33 minutes

This got significantly worse in the last 6 weeks. What happened ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

What is the story with mongo ? It's constantly causing builds to fail CI because of it's complete shitness. I've heard that some people have moved to mongo 3.2 which fixes the problem, but as CI clearly is running the old rubbish version, this clearly isn't a problem which can be called fixed. Wh

Re: The mean time for a CI run has risen to 33 minutes

of Go) On Wed, May 18, 2016 at 9:06 AM, Martin Packman wrote: > On 16/05/2016, David Cheney wrote: >> This got significantly worse in the last 6 weeks. What happened ? > > Either the juju tests are slower, or trusty on aws is slower. It's a > fresh cloud instance each run,

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

What's the plan for mongo 3.2 ? Will we be required to support 2.x versions for the foreseeable future, or is there a possibility to make it a build or run time failure if mongo < 3.2 is installed on the host ? On Wed, May 18, 2016 at 9:01 AM, Martin Packman wrote: > On 17/05/2016, Curtis Hovey-C

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

es in the new storage > engine, which we could skip if mmapv1 ( the old one) wasn't also nearing EOL > I am currently on the phone but if You want more details I can dig up the > bug with details of what I am talking about. > > > On Tuesday, 17 May 2016, David Cheney wrote: >

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

9:58 AM roger peppe > wrote: >> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to >> speed it up again? >> >> On 18 May 2016 09:51, "Christian Muirhead" >> wrote: >>> >>> >>> >>>

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

We already have godeps which can take a set of vcs repos and flick them to the right revisions. Why does CI check out every single dependency from upstream every single time we do a build ? That introduces wc -l dependencies.tsv points of failure to every single CI run -- not to mention the severa

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

g that in a variety of ways (in a container in a long running > VM, etc), but it doesn't have a local copy to work from so it has to pull it > from upstream each time. > > John > =:-> > > > On Wed, May 18, 2016 at 8:05 PM, David Cheney > wrote: >> >&g

Awful dependency problem caused by romulus

Hello, github.com/juju/juju/cmd/juju/commands: github.com/juju/romulus/cmd/commands: github.com/juju/romulus/cmd/setplan: < github.com/juju/juju/api/service: github.com/juju/juju/cmd/modelcmd: cmd/juju depends on the romulus repository, and the romulus reposi

Re: Awful dependency problem caused by romulus

On Thu, May 19, 2016 at 4:30 PM, Casey Marshall wrote: > On Wed, May 18, 2016 at 11:02 PM, David Cheney > wrote: >> >> Hello, >> >> github.com/juju/juju/cmd/juju/commands: >> github.com/juju/romulus/cmd/commands: >&g

Re: Awful dependency problem caused by romulus

On Thu, May 19, 2016 at 5:04 PM, roger peppe wrote: > On 19 May 2016 at 07:02, David Cheney wrote: >> Hello, >> >> github.com/juju/juju/cmd/juju/commands: >> github.com/juju/romulus/cmd/commands: >> github.com/juju/romulus/cmd/setplan: <<<<&l

Re: Awful dependency problem caused by romulus

Dave, I'd not realised just how much they relied on > each other. Surely there's an argument for romulus being merged into core? > > On Thu, May 19, 2016 at 8:55 AM, David Cheney > wrote: >> >> On Thu, May 19, 2016 at 5:04 PM, roger peppe >> wrote: >> >

Re: Awful dependency problem caused by romulus

;> >> On Thu, May 19, 2016 at 6:45 PM, Matthew Williams >> wrote: >> > Really sorry about this Dave, I'd not realised just how much they relied >> > on >> > each other. Surely there's an argument for romulus being merged into >> > core? >

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

TL;DR read issue https://bugs.launchpad.net/bugs/1581337 Thumper asked me to forward this to juju-dev for discussion http://reports.vapour.ws/releases/3964/job/run-unit-tests-win2012-amd64/attempt/2384 Fails because, npipe.Accept is blocking on accept goroutine 41 [syscall, locked to thread]: s

Re: Quick win - juju check

Does this need to be coded inside juju? Could it be a plugin? This sort of data feels like the kind of thing the juju deployer already consumes so the hooks (albeit exposed as blobs of JSON) may exist already. On Tue, May 24, 2016 at 2:14 PM, Tim Penhey wrote: > Hi folks, > > We talked quite a bi

Tech board agenda

Hello, Several times over this week there has been a call to do X to bring an issue to the tech board's attention. Sadly X has generally be "email", which in my mind is a shitty way of tabling issues for discussion. - Is there an agenda for the tech board? - Is there a way to add items for the t

Re: Tech board agenda

On Wed, May 25, 2016 at 4:14 PM, Andrew Wilkins wrote: > On Wed, May 25, 2016 at 1:43 PM David Cheney > wrote: >> >> Hello, >> >> Several times over this week there has been a call to do X to bring an >> issue to the tech board's attention. >> &

The CI build time continue to rise alarmingly

CI build times are now an average of 36 minutes. That means in a typical 8 hour work day, assuming doing nothing other than landing branches, less than 16 commits can be landed. While bugs can be worked on and reviewed in parallel, landing is a sequential action that blocks everyone, and given the

Re: A cautionary tale - mgo asserts

You had me at "ruins mongodb", actually just "ruins'. On Wed, Jun 8, 2016 at 9:04 PM, roger peppe wrote: > This is also relevant (but probably only for larger documents): > > https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ > > Another reason to avoid entire-subdocument ma

Re: Automatic commit squashing

Counter suggestion: the bot refuses to accept PR's that contain more than one commit, then it's up to the submitter to prepare it in any way that they feel appropriate. On Thu, Jun 16, 2016 at 6:44 PM, roger peppe wrote: > Squashed commits are nice, but there's something worth watching > out for:

Re: Automatic commit squashing

ursday, 16 June 2016, Horacio Duran > wrote: >> >> +1 on Dave's suggestion >> >> On Thursday, 16 June 2016, David Cheney >> wrote: >>> >>> Counter suggestion: the bot refuses to accept PR's that contain more >>> than

Re: Automatic commit squashing

going to go with "only 1 commit for each thing >> >> landed", then I do think that using github's squash feature is probably >> >> better than rebasing your branches. Because if we just rebase your >> >> branch, >> >> then you end up with

Re: Review Process Experiment (1 LGTM)

1) Only one LGTM needed to land code. > >a) This raises the stakes slightly on actually voting LGTM. We'd > like it to mean "I understand this patch enough that if there was > a problem, I would be responsible for it." > SGTM. This is how we do it on Go, you and the reviewer are b

The next version of juju will be 1.13.2 this friday

Hello, The next development version if Juju is scheduled to be released this friday. The aim is to continue the schedule of regular releases and pick up the bug fixes/improvements that have landed since 1.13.1. https://docs.google.com/a/canonical.com/document/d/1Vnf2_sDtxZYaFRE7B0hY_f9FHxAOgximUj

<    1   2   3   >