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: 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: 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: 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: 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

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

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:

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

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: 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: 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: 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: 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

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: 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 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

, 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'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

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

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: 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

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: 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

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

> >>>>> 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

, 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: 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

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: 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

+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

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: 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

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: 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

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

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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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: 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"

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: 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: 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

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: 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

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

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

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: 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: "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

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: 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

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: 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

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

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

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: 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

<    1   2   3