Default Controller Type on GCE

[Matthew Williams]

Hello Juju Fans,

I've recently been playing around with Juju on GCE. Google is suggesting
that I could downgrade the instance type to save some money (attached
screenshot)

I was wondering if anyone else had something similar, and therefore, does
this suggest our default controller instance type on GCE is bigger than we
need?

(The attached screenshot would be a saving of $47 per month)

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Leadership Election Tools

[Matthew Williams]

Hey Folks,

Let's say I'm a charm author that wants to test leadership election in my
charm. Are there any tools available that will let me force leadership
election in juju so that I can test how my charm handles it? I was looking
at the docs here: https://jujucharms.com/docs/stable/developer-leadership
but couldn't see anything

Cheers

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

One instance manual provider

[Matthew Williams]

Hey Folks,

I notice the docs state that at least two instances are needed for the
manual provider: https://jujucharms.com/docs/stable/clouds-manual. Some
quick playing around suggests that this is indeed the case.

Is there a technical reason why? I'd love to spin up a charm on [insert vps
provider here] and only spend money for one instance

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju run-action --application?

[Matthew Williams]

Those are all good points - but they also seem like implementation details.
For example if an action relied on coordination around the leader then the
action should be written to protect against that - since it may still break
if the user was to run juju run-action myapp/0 && juju run-action myapp/1.

My question is - if I have a model with an application scaled to 10 units,
and I know the action is safe to run all the units why do I have to call
run-action 10 times, shouldn't I just be able to call it once on the
application? Is there a genuine reason we're not supporting this?

Cheers

Matty

On Wed, Aug 3, 2016 at 6:02 PM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> Because of the ambiguous nature of actions and application. Some would
> expect, as you do, to run on all units. Others would expect the leader to
> coordinate that action. Furthermore, it becomes more complex as to how
> results are curated. Do you get back X UUIDs one for each unit or a single
> action UUID but results returned in a different fashion?
>
> Marco
>
> On Wed, Aug 3, 2016, 12:35 PM Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> Hey Folks,
>>
>> Is there any reason why I can't do juju run-action --application myapp
>> (in the same way I can do juju run --application myapp).
>>
>> Thanks
>>
>> Matty
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Cleansing Mongo data

[Matthew Williams]

I seem to be missing something. Why do we need this?

Matty
On 24 Jun 2016 17:14, "Nate Finch"  wrote:

> 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 can't
>> say for sure, but it looks like we may have been cleansing things in the
>> parts of Juju that need it. William may know more.
>>
>> If not, I imagine a small upgrade step would make short work of any
>> problems.
>>
>> roger peppe  writes:
>>
>> > This is useful, thanks.
>> >
>> > Note that's it's not necessary to cleanse *all* keys that go into Mongo,
>> > just the ones that might be used in queries.
>> >
>> > But one thought... what about keys that already contain full-width
>> > dollar and dot?
>> >
>> >   cheers,
>> > rog.
>> >
>> > On 23 June 2016 at 21:09, Katherine Cox-Buday
>> >  wrote:
>> >> Hey all,
>> >>
>> >> William gave me a good review and it came up that I wasn't cleansing
>> >> some of
>> >> the data being placed in Mongo. I wasn't aware this had to be done,
>> >> and
>> >> after talking to a few other folks it became apparent that maybe not
>> >> many
>> >> people know we should be doing this.
>> >>
>> >> At any rate, William also pointed me to some existing code which did
>> >> this.
>> >> I've pulled it out into the mongo/utils package for general
>> >> consumption. The
>> >> comments do a pretty good job of elucidating why this is necessary.
>> >>
>> >> https://github.com/juju/juju/blob/master/mongo/utils/data_cleansing.go
>> >>
>> >> -
>> >> Katherine
>> >>
>> >> --
>> >> Juju-dev mailing list
>> >> Juju-dev@lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>> >>
>>
>> --
>> Katherine
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Awful dependency problem caused by romulus

[Matthew Williams]

Yeah - the mistake we made was starting with pure intentions but over time
starting to think of it as just another part of core. I'll have to discuss
it with Casey when he's up

On Thu, May 19, 2016 at 9:47 AM, David Cheney <david.che...@canonical.com>
wrote:

> I think that would be the best solution, I don't see how we can undo
> the dependencies between cmd/juju and romulus -- they're so tightly
> coupled they should probably live in the same repository.
>
> On Thu, May 19, 2016 at 6:45 PM, Matthew Williams
> <matthew.willi...@canonical.com> 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?
> >
> > On Thu, May 19, 2016 at 8:55 AM, David Cheney <
> david.che...@canonical.com>
> > wrote:
> >>
> >> On Thu, May 19, 2016 at 5:04 PM, roger peppe <roger.pe...@canonical.com
> >
> >> wrote:
> >> > On 19 May 2016 at 07:02, David Cheney <david.che...@canonical.com>
> >> > wrote:
> >> >> 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
> repository
> >> >> depends on juju.
> >> >>
> >> >> This is terrible. It means we _cannot_ change the public api of the
> >> >> juju that romulus depends on because then juju won't compile, and we
> >> >> cannot land the fix to romulus without breaking juju.
> >> >
> >> > I agree that this is unfortunate, but "cannot" is a strong word. I
> >> > believe
> >> > that there is a (somewhat painful) workaround for this - we've been in
> >> > similar situations
> >> > before.
> >> >
> >> > Say you want to change the public API of juju in a backwardly
> >> > incompatible
> >> > way. Here's how you can do it.
> >> >
> >> > First change the API and fix romulus to work with the new API, without
> >> > merging either change into their repos.
> >> >
> >> > Then push the romulus change to the romulus repo in a *feature branch*
> >> > rather onto master. Tests will not pass in this branch because it
> >> > depends
> >> > on as-yet-to-be-landed changes in juju, but the code is now available
> in
> >> > the romulus repo.
> >> >
> >> > Then propose the Juju changes with the feature-branch revision
> >> > of romulus as a dependency. Tests should pass OK because godeps
> >> > doesn't care which branch its dependencies are pulled from.
> >> >
> >> > Once that's landed, land the romulus changes in romulus master
> >> > depending on the just-landed changes in juju.
> >> >
> >> > Then update juju to use the latest romulus dependency.
> >>
> >> Or I could just land the commits directly. I guess it depends if we
> >> want to play the CI game or not. My point is creating loops like this
> >> means we have to reach for even more creative measures to mitigate
> >> them.
> >>
> >> To be clear, this is a big mistake, it's fine for juju to depend on a
> >> project, we currently depend on 72 projects. What is not ok is for
> >> that project to then depend back on juju, that is poor software
> >> engineering.
> >>
> >> > As for the cyclic dependency itself, perhaps there's an argument for
> >> > moving the main juju command into a separate repo (or everything *but*
> >> > the juju main command into a separate repo) so that it's possible
> >> > to include externally implemented commands without creating a cycle.
> >>
> >> I'd very much like to see this. It's clear that the juju command is
> >> going to have to serve multiple masters, and by breaking it off into a
> >> separate project this would force us (juju) to create a supported
> >> public API which we currently do not have.
> >>
> >> >
> >> >   cheers,
> >> > rog.
> >> >
> >> >> Casey, please fix this immediately. Either juju depends on romulus,
> or
> >> >> romulus depends on juju, but at the moment they both depend on each
> >> >> other and that is a showstopper,
> >> >>
> >> >> Thanks
> >> >>
> >> >> Dave
> >> >>
> >> >> --
> >> >> Juju-dev mailing list
> >> >> Juju-dev@lists.ubuntu.com
> >> >> Modify settings or unsubscribe at:
> >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Awful dependency problem caused by romulus

[Matthew Williams]

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?

On Thu, May 19, 2016 at 8:55 AM, David Cheney 
wrote:

> 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: <
> >>   github.com/juju/juju/api/service:
> >>   github.com/juju/juju/cmd/modelcmd:
> >>
> >> cmd/juju depends on the romulus repository, and the romulus repository
> >> depends on juju.
> >>
> >> This is terrible. It means we _cannot_ change the public api of the
> >> juju that romulus depends on because then juju won't compile, and we
> >> cannot land the fix to romulus without breaking juju.
> >
> > I agree that this is unfortunate, but "cannot" is a strong word. I
> believe
> > that there is a (somewhat painful) workaround for this - we've been in
> > similar situations
> > before.
> >
> > Say you want to change the public API of juju in a backwardly
> incompatible
> > way. Here's how you can do it.
> >
> > First change the API and fix romulus to work with the new API, without
> > merging either change into their repos.
> >
> > Then push the romulus change to the romulus repo in a *feature branch*
> > rather onto master. Tests will not pass in this branch because it depends
> > on as-yet-to-be-landed changes in juju, but the code is now available in
> > the romulus repo.
> >
> > Then propose the Juju changes with the feature-branch revision
> > of romulus as a dependency. Tests should pass OK because godeps
> > doesn't care which branch its dependencies are pulled from.
> >
> > Once that's landed, land the romulus changes in romulus master
> > depending on the just-landed changes in juju.
> >
> > Then update juju to use the latest romulus dependency.
>
> Or I could just land the commits directly. I guess it depends if we
> want to play the CI game or not. My point is creating loops like this
> means we have to reach for even more creative measures to mitigate
> them.
>
> To be clear, this is a big mistake, it's fine for juju to depend on a
> project, we currently depend on 72 projects. What is not ok is for
> that project to then depend back on juju, that is poor software
> engineering.
>
> > As for the cyclic dependency itself, perhaps there's an argument for
> > moving the main juju command into a separate repo (or everything *but*
> > the juju main command into a separate repo) so that it's possible
> > to include externally implemented commands without creating a cycle.
>
> I'd very much like to see this. It's clear that the juju command is
> going to have to serve multiple masters, and by breaking it off into a
> separate project this would force us (juju) to create a supported
> public API which we currently do not have.
>
> >
> >   cheers,
> > rog.
> >
> >> Casey, please fix this immediately. Either juju depends on romulus, or
> >> romulus depends on juju, but at the moment they both depend on each
> >> other and that is a showstopper,
> >>
> >> Thanks
> >>
> >> Dave
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: mongo and ssh

[Matthew Williams]

Hi Neale,

When you bootstrap, juju should be setting up mongo on the bootstrap server
with all the correct settings and keys, you normally don't need to access
the running mongodb, but if it's needed for debugging purposes it's
possible. If you want to run mongo as part of your environment then you
should make use of the mongodb charm (juju deploy mongodb).

If however there's a mongo related problem with bootstrapping then that's
something we should be fixing for you, in this case a copy of the log would
be useful.

I hope this answers your question to some extent, let me know what I can do
to help further

Thanks

Matt (mattyw)

On Thu, Jan 7, 2016 at 5:42 PM, Neale Ferguson  wrote:

> Hi,
>  I have Juju bootstrapping and as part of the process it’s attempting to
> contact a mongo server. It is doing so securely and thus mongodb needs to
> be set up correctly. Is there a guide for “Using Juju with mongodb”
> anywhere? I am trying to determine key and certificate requirements on
> both sides etc.
>
> TIA, Neale
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Problem Bootstrapping Azure

[Matthew Williams]

Hey Folks,

Can someone with knowledge of azure respond to this issue?

https://github.com/juju/juju/issues/3313

Many thanks

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

On Call Reviewer Duties

[Matthew Williams]

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 there. We moved to github to improve collaboration,
but the issues list is often left ignored. If every OCR took a look at it
we'd get it under control very quickly

Thoughts

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju status & ubuntu snappy

[Matthew Williams]

Hey folks,

I've been hacking around a bit more with juju and snappy. Thought you folks
might be interested in seeing what I've come up with so far.

Video: https://www.youtube.com/watch?v=JnbrWRDFqVo

Blog post: http://blog.mattyw.net/blog/2015/10/18/snappy-juju-flasher-video/

Cheers

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Graduated Juju core reviewer: Aleš Stimec

[Matthew Williams]

Congratulations Ales. Good work

On Wed, Oct 7, 2015 at 1:05 PM, Casey Marshall  wrote:

> All,
> I'm pleased to announce Aleš Stimec is now a graduated Juju core reviewer.
> His recent contributions and improvements to the Juju unit agent,
> command-line infrastructure and API login clearly demonstrate a depth and
> breadth of Juju core knowledge befitting this role.
>
> Welcome Aleš, and well done!
>
> -Casey
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fix for LP: #1174610 landing (unit ids should be unique)

[Matthew Williams]

This has now landed - and at the moment only in master so it will be out in
1.25

On Mon, Apr 27, 2015 at 5:44 PM, Casey Marshall 
casey.marsh...@canonical.com wrote:

 Just a friendly heads-up.. a fix for this longstanding bug will be
 landing into master shortly:

 LP: #1174610, unit ids should be unique

 What this fix essentially does is assign each deployed workload a
 distinct unit ID (incrementing sequentially) within the scope of an
 environment. Example:

 1. juju deploy mysql
Deployed workload gets an ID, mysql/0

 2. juju destroy-service mysql

 3. juju deploy mysql
Deployed workload gets a distinct ID, mysql/1

 I do not anticipate any negative impact to normal Juju usage from this
 bugfix, but I'd like to raise awareness here proactively, in the event
 that there is potential breakage in scripts that invoke juju with
 hard-coded assumptions on how Juju assigns unit IDs -- instead of
 retrieving actual assigned unit IDs from status.

 -Casey


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Public Service Annoucement

[Matthew Williams]

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
Contributing.md:

https://github.com/juju/juju/blob/master/CONTRIBUTING.md#local-clone

Thanks for listening

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Test suite on windows now voting on trunk

[Matthew Williams]

I wasn't able to work out why my test failed on windows, but I was able to
realise that it wasn't really testing what I wanted. I'm landing a further
change now that makes the tests a little better, and adds a new one, and
I've confirmed that they pass in the right way on windows and ubuntu.

Matty

On Fri, Apr 24, 2015 at 11:43 AM, John Meinel j...@arbash-meinel.com
wrote:

 That's really great!

 John
 =:-


 On Fri, Apr 24, 2015 at 1:59 PM, Gabriel Samfira 
 gsamf...@cloudbasesolutions.com wrote:

 That is great news! Congrats guys! :)


 Cheers,
 Gabriel
 
 From: juju-dev-boun...@lists.ubuntu.com [
 juju-dev-boun...@lists.ubuntu.com] on behalf of Martin Packman [
 martin.pack...@canonical.com]
 Sent: Friday, April 24, 2015 12:56 PM
 To: juju-dev@lists.ubuntu.com
 Subject: Re: Test suite on windows now voting on trunk

 On 23/04/2015, Martin Packman martin.pack...@canonical.com wrote:
  Well, mostly good news after Matty and I landed workarounds. There's a
  single remaining failure that has manifested since:
 
  TestLeadership fails on windows test slave
  https://bugs.launchpad.net/juju-core/+bug/1447595

 With Bogdan's fix landed, we've had our first clean run on CI:

 
 http://reports.vapour.ws/releases/2558/job/run-unit-tests-win2012-amd64/attempt/287
 

 Description set: Revision build: 2558
 gitbranch:master:github.com/juju/juju 73cde95d
 Finished: SUCCESS

 Thanks for helping out everyone!

 Martin

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Graduated reviewer: Domas Monkus

[Matthew Williams]

Congratulations Domas!
On 23 Apr 2015 15:47, Casey Marshall casey.marsh...@canonical.com wrote:

 Juju developers,
 I would like to announce Domas Monkus is a fully graduated Juju core
 reviewer. This announcement is really long overdue.. Domas is careful
 and thoughtful in his reviews, his feedback is useful, actionable and
 relevant, and he's landed several significant improvements that
 demonstrate a deep understanding of Juju core design and internals.

 So let's give praise, thanks (and reviews) to Domas, for a job well done!

 -Casey


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: gocheck in non test code

[Matthew Williams]

I was just looking at exactly that - it's much more manageable number as
well! We'd probably want one for jujud as well

On Tue, Apr 21, 2015 at 3:49 PM, John Meinel j...@arbash-meinel.com wrote:

 I think the difference is that if you do:
   go list -f '{{join .Deps \n}}' github.com/juju/juju/cmd/juju

 Then it only lists things that get imported by the juju binary.

 However, if you do github.com/juju/juju/... then it recurses the
 directory structure and finds everything imported by every directory.

 John
 =:-


 On Tue, Apr 21, 2015 at 5:46 PM, John Meinel j...@arbash-meinel.com
 wrote:

 I don't know if it is because of bad imports but I certainly see
  github.com/juju/juju/environs/testing
  github.com/juju/juju/juju/testing
 etc
 in the output of the go list output.

 John
 =:-

 On Tue, Apr 21, 2015 at 5:34 PM, Matthew Williams 
 matthew.willi...@canonical.com wrote:

 Unless I misunderstand my usage of go list (which is an absolute
 possibility) then those instances aren't included.

 On Tue, Apr 21, 2015 at 3:31 PM, John Meinel j...@arbash-meinel.com
 wrote:

 Looking at the patch, that doesn't seem to filter testing packages,
 does it? Those intentionally have those dependencies, but should only be
 imported in *_test.go code.

 John
 =:-


 On Tue, Apr 21, 2015 at 5:17 PM, Matthew Williams 
 matthew.willi...@canonical.com wrote:

 Hi Folks,

 There seem to be a number of places in core where we end up importing
 gocheck in non test code. We should have a plan for reducing this down to
 zero, and at some stage not merge code in that does this. That's not a
 reasonable thing to do at the moment so I've just proposed a new rule in
 the Makefile that we can use to track it:
 http://reviews.vapour.ws/r/1460/

 Any implementation specific comments should go on the review. But I
 wanted to email the list incase anyone wanted to discuss the idea in
 general - and possible resolutions.

 Thanks all

 Matty

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev






-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: gocheck in non test code

[Matthew Williams]

Unless I misunderstand my usage of go list (which is an absolute
possibility) then those instances aren't included.

On Tue, Apr 21, 2015 at 3:31 PM, John Meinel j...@arbash-meinel.com wrote:

 Looking at the patch, that doesn't seem to filter testing packages, does
 it? Those intentionally have those dependencies, but should only be
 imported in *_test.go code.

 John
 =:-


 On Tue, Apr 21, 2015 at 5:17 PM, Matthew Williams 
 matthew.willi...@canonical.com wrote:

 Hi Folks,

 There seem to be a number of places in core where we end up importing
 gocheck in non test code. We should have a plan for reducing this down to
 zero, and at some stage not merge code in that does this. That's not a
 reasonable thing to do at the moment so I've just proposed a new rule in
 the Makefile that we can use to track it:
 http://reviews.vapour.ws/r/1460/

 Any implementation specific comments should go on the review. But I
 wanted to email the list incase anyone wanted to discuss the idea in
 general - and possible resolutions.

 Thanks all

 Matty

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Unit test failure in juju/errors

[Matthew Williams]

Hi Folks,

It appears that juju/errors has a failing unit test:
http://paste.ubuntu.com/10085832/

It also appears that it only fails in go1.4

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Where to Review

[Matthew Williams]

Hi Folks,

I'm forgetful and disorganised at the best of times

I can never remember where I should go to review a particular juju project.

I *think* only juju/juju and juju/utils are in reviewboard and everything
else is in github - but I can't remember - is that right?

Do we have a definitive list somewhere - that we update as we move to
github so people like me can remember easily?

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Too space, or not two space

[Matthew Williams]

Believe it or not I also learned to type on a mechanical typewriter and I
did double spaces on that. But you also needed to un jam it if you typed
too fast.

I'm voting for single space.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Distributed systems theory

[Matthew Williams]

There's also the papers we love project

https://github.com/papers-we-love/papers-we-love

They have loads of papers about various topics. Here's the distributed
systems section:

https://github.com/papers-we-love/papers-we-love/tree/master/distributed_systems

Matty

On Tue, Sep 23, 2014 at 9:05 AM, John Meinel j...@arbash-meinel.com wrote:

 This is a collection of papers/discussions on Distributed Systems Theory
 that seems to be a pretty good starting point for understanding.

 http://the-paper-trail.org/blog/distributed-systems-theory-for-the-distributed-systems-engineer/

 It focuses on bridge material to help people get a general understanding
 of the problem space.

 I haven't dug deeply into this, but reading through the overview it looks
 pretty good.

 John
 =:-


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: The Pros and Cons of ReviewBoard.

[Matthew Williams]

Just in case we're counting, another pro:

You are able to seperate pushing branches to github and creating a new
version of code for review

Matty

On Fri, Sep 19, 2014 at 4:37 PM, Eric Snow eric.s...@canonical.com wrote:

 Given that I've in some part driven the switch to ReviewBoard, I want
 to make sure we are all on the same page and any decision on its
 future can be made objectively.  This is an outgrowth of the current
 discussion on whether or not we should ditch reviewboard.

 Let's look at the pros and cons of using it (at least relative to
 github).  Feel free to expand on any point here or add to them.

 -eric

 ReviewBoard Pros:

 * self-hosted (flexibility, ownership)
 * unified review queue with detailed info
 * reviews are composed of multiple comments, not just one
 * reviews have worklow-supporting metadata (ship-it, issues)
 * reviews can be edited as a whole before publishing
 * review comments are threaded (provides context)
 * customizable (3rd party and custom extensions)
 * extensive remote API
 * some github integration
 * supports chained branches (anti-pattern?)
 * allows you to look at new changes in context of old comments
 * allows you to look at changes between review request updates
 * does not require a PR to exist

 ReviewBoard Cons:

 * self-hosted (hosting, maintenance, etc.)
 * adds manual steps to our workflow
 * extra steps increase the barrier to contributing
 * not a part of the mainstream github workflow
 * requires adjusting to a new tool for most people
 * web UI has some usability issues (list?)
 * emails formatting is complicated (subjective)

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: The Pros and Cons of ReviewBoard.

[Matthew Williams]

At the risk of opening a can of worms:

Reviewboard doesn't have to be a barrier to contributing. We could allow
new contributors/ drive by fixes to use github.

Matty
On 19 Sep 2014 17:05, Eric Snow eric.s...@canonical.com wrote:

 On Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina
 jaquil...@eagleeyet.net wrote:
  I am more than willing to help out wity those modifications

 Cool.  I'll get in touch.

 -eric

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Doing chained diffs w/ Reviewboard

[Matthew Williams]

I've got it working. Using rbt it was pretty trivial. I'm not 100% sure of
my steps - but from memory and some prompting from `history` the process
was more or less:

1) rebase my branch against the latest version of the parent. Then:

2) rbt post -parent remotes/mattyw/my-parent-branch

It appeared that when I ran rbt -u against this branch I still needed to
specify the parent (ISTR that lbox used to remember there was a parent
branch when pushing changes)

Matty



On Thu, Sep 18, 2014 at 10:53 AM, Adam Collard adam.coll...@canonical.com
wrote:

 On 18 September 2014 10:49, John Meinel j...@arbash-meinel.com 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...  base.diff
  git co dependent-branch
  git diff master...  dependent.diff
  git merge-base master HEAD  remember-this-rev

 And then put the dependent.diff into the Diff: *, and then the
 base.diff into Parent Diff: and then 'remember-this-rev' into the Base
 Commit ID.

 I also tried putting git merge-base master base-branch as the Base
 Commit ID.


 This makes me think you're using the UI to do this.

 Let me repeat my Public Safety Announcement: Do NOT use ReviewBoard's UI
 for uploading diffs. Please for $deity's sake use rbt post.


 https://www.reviewboard.org/docs/rbtools/0.6/rbt/commands/post/#distributed-version-control-systems

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: reviewboard

[Matthew Williams]

Thanks Eric,

Taking it for a spin now, looks pretty cool

Matty

On Tue, Sep 9, 2014 at 3:47 PM, Eric Snow eric.s...@canonical.com wrote:

 On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com
 wrote:
  On 09/09/14 04:32, Eric Snow wrote:
  To install rbt:
 
  sudo pip install --allow-unverified rbtools --allow-external rbtools
 rbtools
 
  Ah... no.
 
  Perhaps in a virtual env.

 Is it the sudo or the flags to which you object? :)  Using a
 virtualenv would indeed be a good idea!  So, as a correction to my
 previous instructions:

   virtualenv ~/.venvs/reviewboard
   ~/.venvs/reviewboard/bin/pip install --allow-unverified rbtools
 --allow-external rbtools rbtools
   alias rbt='~/.venvs/reviewboard/bin/rbt'

 -eric

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

auth fails bug reports

[Matthew Williams]

Hi Folks,

Casey and I spent some time today looking at the auth fails during
TearDownTest symptom/ bug:

https://bugs.launchpad.net/juju-core/+bug/1348477.

The failure seems to happen across various tests. The same problem was
reported across a number of the errors listed in our juju test failures doc.

Additional logging was added to this part of the code this morning (thanks
Dimiter!) so now we have a better chance of working out exactly where the
error comes from. If anyone running near HEAD encounters this problem Casey
and I would be interesting in seeing logs from the error. In particular any
lines that look like this:

ERROR juju.state failed to stop state watcher: err

ERROR juju.state failed to stop presence watcher: err

ERROR juju.state failed to stop all manager: err

Thanks

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Lag for unblocking CI

[Matthew Williams]

Thanks Martin, yeah things have come up since it tried to land, I'll try
again later today and let you know if there are any problems


On Mon, Sep 1, 2014 at 2:49 PM, Martin Packman martin.pack...@canonical.com
 wrote:

 On 01/09/2014, John Meinel j...@arbash-meinel.com wrote:
 
  Is there some amount of caching going on somewhere? (I also noticed it
 took
 7minutes for the bot to notice a $$merge$$ request, so maybe it does the
  check somehow asynchronously to processing the requests?)

 Maybe it was something timing related. At any rate, manually running
 the script shows it's happy now.

 $ python check_blockers.py master 562
 No blocking bugs

 Can do this by getting the script from lp:juju-ci-tools with the
 params as what you want to merge into, and the pull request number.

 I see the proposal has still not landed, despite some subsequent
 comments with the merge directive. However, William has also left some
 additional comments, so I guess we leave it till that's all addressed?

 Martin

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: gccgo internal compiler errors

[Matthew Williams]

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?

Thanks

Matty


On Thu, Aug 28, 2014 at 11:48 PM, Tim Penhey tim.pen...@canonical.com
wrote:

 Hi folks,

 I spent some time this morning looking at
 https://bugs.launchpad.net/juju-core/+bug/1362636

 A critical regression that was breaking CI on power.

 There is a bug in gccgo where we hit an internal compiler error when
 comparing an interface to a concrete type that implements the interface
 (as opposed to a pointer to the concrete type implementing the interface).

 This impacts some of the names.Tag rework that is going on.

 If you try to compare:
var tag names.Tag = names.NewMachineTag(1)

if names.NewUnitTag(1) == tag {
   // BOOM!!!
}

 This is entirely valid Go, and works fine with gc, but gccgo barfs
 horribly.

 My fix is here: https://github.com/juju/juju/pull/633

 This is just a warning.

 Remember folks that we need to support gccgo still (for at least another
 year until we have power and arm64 using gc).

 You can test locally by doing this:
   go test -compiler gccgo

 If you install the gccgo packages, which I don't remember, but hopefully
 someone will follow up with.

 Cheers,
 Tim

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[Matthew Williams]

I'm not attempting to cause trouble here - I just want to make sure I
understand the feature - and what effects it might have.

It sounds like any implementation of the default-hook would need to start
with something like: (pseudo-bash)

if JUJU_HOOK_NAME == start
 //run start
else if JUJU_HOOK_NAME == config-changed
 //run config-changed
else if JUJU_HOOK_NAME == stop
 //run stop
else
  //unknown hook
  exit 1
fi

Any default-hook that deviated from this pattern could find itself being
run multiple times in succession - I wonder if that might be confusing/
unexpected to a charm author?
Gustavo's observation about hooks that the charm might no know about yet
means that the else clause is absolutely required, I wonder if that's
obvious to someone who's new to charming?

Just some thoughts - in principle I love the feature

Matt





On Tue, Aug 19, 2014 at 11:10 PM, Gustavo Niemeyer gust...@niemeyer.net
wrote:

 On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams
 matthew.willi...@canonical.com wrote:
  Something to be mindful of is that we will shortly be implementing a new
  hook for metering (likely called collect-metrics). This hook differs
  slightly to the others in that it will be called periodically (e.g. once
  every hour) with the intention of sending metrics for that unit to the
 state
  server.
 
  I'm not sure it changes any of the details in this feature or the pr -
 but I
  thought you should be aware of it

 Yeah, that's a good point. I'm wonder how reliable the use of
 default-hook will be, as it's supposed to run whenever any given hook
 doesn't exist, so charms using that feature should expect _any_ hook
 to be called there, even those they don't know about, or that don't
 even exist yet. The charms that symlink into a single hook seem to be
 symlinking a few things, not everything. It may well turn out that
 default-hook will lead to brittle charms.


 gustavo @ http://niemeyer.net

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

[Matthew Williams]

Something to be mindful of is that we will shortly be implementing a new
hook for metering (likely called collect-metrics). This hook differs
slightly to the others in that it will be called periodically (e.g. once
every hour) with the intention of sending metrics for that unit to the
state server.

I'm not sure it changes any of the details in this feature or the pr - but
I thought you should be aware of it

Matty


On Tue, Aug 19, 2014 at 6:07 PM, Aaron Bentley aaron.bent...@canonical.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 14-08-19 12:46 PM, Gustavo Niemeyer wrote:
  On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley
  aaron.bent...@canonical.com wrote:
  True.  At that point, the pattern is not a win, but it's not much
  of a loss.  Changing the web site relation is extremely uncommon,
  but operations which do require server restarts are quite common.
  So making an exception for the web site relation can be seen as
  a micro-optimization.
 
  Restarting a process and killing all on-going activity is a big
  deal more often than not, for realistic services.

 Sure, if we *were* to optimize this, we'd want to restart only on
 certain kinds of changes.  But I'd argue that it's better to optimize
 that in the application domain than based on hook names.

 For example, changing the cron interval does not require restarting
 the web server, but changing the http port does.  Both use the same
 hook, config-changed.

 Instead of restarting the web server unconditionally, we could restart
 it when the contents of its config file change.  That would avoid a
 restart when cron interval changes, and also when
 webserver-relation-changed fires.

 So I think it's a bigger win to focus on the application domain and
 ignore the hook names.

  The point I was trying to convey is not that you can merge or
  ignore certain events. The system was designed so that this was
  possible in the first place. The point is rather that the existing
  event system is convenient and people rely on it, so I don't buy
  that a something-changed hook is what most people want at this
  point.

 Fair enough.  More evidence would be needed to determine whether I'm
 an outlier.

 Aaron
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r
 0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu
 kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR
 fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc
 mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi
 X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE=
 =bqp0
 -END PGP SIGNATURE-

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reviewing - moving to review mentors, and guidelines

[Matthew Williams]

Is this still happening?

M
On 19 Jul 2014 09:43, Matthew Williams matthew.willi...@canonical.com
wrote:

 +1

 Great idea, thank you
 On 18 Jul 2014 03:28, Tim Penhey tim.pen...@canonical.com wrote:

 Hi all,

 Last night in the team meeting we discussed the review process.
 Initially because there have been a number of things sneaking through
 reviews where ideally we'd like to catch them earlier.

 In order to help the newer folks on the team learn how we review, it has
 been suggested that we formalise the mentored reviewers process.

 Mentored Reviewers
 ==

 All juju core members are expected to review code.  It is not reasonable
 to expect the newer members of the team to feel comfortable being the
 sole reviewer on work.

 I have created a new sheet for people to register themselves on if they
 feel they would like to have a review mentor [1].  You should discuss
 this with your team lead if you are unsure.  A mentor will be allocated
 to you, or if you have discussed this with someone in particular, you
 can have a say in your own mentor.

 Reviews done by the mentored developer are not considered enough to land
 code until they have been approved by their mentor.

 It is up the mentor and mentee how they choose to do the reviews.  They
 could do this over a hang out together, or the mentor could review the
 review after the mentee has done the first pass.

 Once the mentor feels that the mentee is consistently doing good
 reviews, they will announce the graduation, and that developer no longer
 needs a second review pass of their reviews.


 Guidelines
 ==

 Prior to starting any significant piece of work or refactoring, the
 general approach should first be checked with the team lead and
 technical architect.  Smaller more obvious pieces of work don't
 necessarily need this, but it is often good to talk to someone about the
 problem and the proposed fix as an initial sanity check.

 The aim here is to avoid getting into design discussions at review time
 as this is clearly the wrong time to do it.

 As the developer, it is strongly suggested that you work to the boy
 scout rule - leave the code cleaner than you found it.  We don't
 expect perfection (or we shouldn't), but don't leave a mess.  It is ok
 to push back on a reviewer if you feel that the reviewer is being
 unreasonable in their request for perfection.  If you feel that this is
 the case, talk to your team lead.

 As a reviewer, if you don't understand the code or what is being done
 there are a number of options:
  * it could be that the code is confusing, getting a second opinion can
 help here
  * it could be that you don't understand the area of code being changed,
 and it isn't always feasible to grok everything completely. If the
 change isn't obviously correct (to you), get a second opinion

 A review that says

 The code looks good, test coverage seems to be complete, but I can't
 tell if this will actually fix problem X

 is still a useful review, and worth doing.  The developer should seek
 someone to understands that area, or work with the reviewer to help them
 understand.

 In any situation where you need to stop and explain it can seem like the
 process is too slow, but sharing and explaining is short term delay for
 long term gain as the knowledge is shared through the team.


 Checklist
 =

 I think it makes sense to have a check list to cover the basics of what
 we look for in reviews.  Probably even get this into the docs directory
 in trunk.

 There is a document already which covers some basics of writing good
 tests: doc/how-to-write-tests.txt


 Initial things that I look for (off the top of my head):
  * firstly work out what the code is trying to fix (feature or bug)
  * is it obvious that the code does this?
  * for new functions, do the names make sense? do they say what the
 function does?
  * are all the public constants, variables, functions and methods
 documented?
  * how are the new functions tested?
  * can they be tested in isolation?
  * are all the new code paths tested?
  * do the names of the tests make sense?
  * could similar tests be combined into a table based test?
  * should a table based test be broken out in more obvious tests?
   (this sometimes happens when there is too much logic or too many
 conditionals in the actual test block of the table based test)
  * is this code valid for all operating systems?
  * are there any race conditions?
  * are the tests isolated from the environment?



 Cheers,
 Tim


 [1]

 https://docs.google.com/a/canonical.com/spreadsheets/d/1v9KB6Y4r1bMLOyB1JEs-wj_jBAvsq6EglWssa4cOx9c/edit#gid=0

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Port ranges - restricting opening and closing ranges

[Matthew Williams]

+1 on an opened-ports hook tool, I've added it to the task list


On Fri, Jun 27, 2014 at 9:41 AM, William Reade william.re...@canonical.com
wrote:

 Agreed. Note, though, that we'll want to give charms a way to know what
 ports they have already opened: I think this is a case where
 look-before-you-leap maybe beats easier-ask-forgiveness-than-permission
 (and the consequent requirement that error messages be parsed...). An
 opened-ports hook tool should do the trick.


 On Thu, Jun 26, 2014 at 9:18 PM, Gustavo Niemeyer gust...@niemeyer.net
 wrote:

 +1 to Mark's point. Handling exact matches is much easier, and does
 not prevent a fancier feature later, if there's ever the need.

 On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen (Canonical.com)
 mark.ramm-christen...@canonical.com wrote:
  My belief is that as long as the error messages are clear, and it is
 easy to
  close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine.
  Of
  course it is nicer if we can do that automatically for you, but I
 don't
  see why we can't add that later, and I think there is a value in
 keeping a
  port-range as an atomic data-object either way.
 
  --Mark Ramm
 
 
  On Thu, Jun 26, 2014 at 2:11 PM, Domas Monkus 
 domas.mon...@canonical.com
  wrote:
 
  Hi,
  me and Matthew Williams are working on support for port ranges in juju.
  There is one question that the networking model document does not
 answer
  explicitly and the simplicity (or complexity) of the implementation
 depends
  greatly on that.
 
  Should we only allow units to close exactly the same port ranges that
 they
  have opened? That is, if a unit opens the port range [8000-9000], can
 it
  later close ports [8500-8600], effectively splitting the previously
 opened
  port range in half?
 
  Domas
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 



 --

 gustavo @ http://niemeyer.net

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Thoughts to keep in mind for Code Review

[Matthew Williams]

I agree that the code needs to be self-explanatory enough to not require
annotations, but annotations can be useful - especially for larger changes.
Suggesting the order for code to be reviewed is certainly useful if you're
reviewing code in a part of the system you aren't familiar with


On Wed, Jun 25, 2014 at 10:25 AM, Jeroen Vermeulen 
jeroen.vermeu...@canonical.com wrote:

 On 2014-06-25 09:43, roger peppe wrote:

  About pre-review annotations, I agree with Ian that the code should be
 documented
 well enough that someone coming to it from scratch can understand it, but
 I also wonder if there is a room for review-specific comments, talking
 about
 reasons for the changes themselves in the specific context of that review.


 There is, I think.  But should it be quite so close to the code, where it
 competes against commenting for the coder's time?

 Don't know if there's a definite answer, because either way we assume a
 human process to complement the technical solution.  But if a coder starts
 by reviewing their own code, perhaps they should also turn these notes into
 a single coherent cover letter and, in explaining, perhaps spot
 structural flaws or anticipate questions.


 Jeroen


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at: https://lists.ubuntu.com/
 mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Static Analysis on Juju

[Matthew Williams]

Hi Folks,

As some of you will be aware the latest version of go includes some static
analysis tools in godoc:
http://golang.org/lib/godoc/analysis/help.html

As is noted in the above, the analysis is quite slow (and resource
intensive), but I wanted to find out if there was any useful output. To
this end I setup a machine in canonistack running against tip (Commit:
4d4379e)

http://162.213.34.143:8080/pkg/

All of the packages in the gopath are analysed, - so all of core, its
dependencies and the stdlib are here, after ~6 hours not all of it has been
done.

I'll try to keep this machine running all week if anyone wants to take a
look

Cheers

Matty
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: End Of Review marker

[Matthew Williams]

+1 Rick.

My opinion is it's just an issue of manners. After filling in comments
inline let them know that you're done so they can start working on it.
Likewise if you start doing a review and have some interruption and are
unable to finish it let them know that there might be more to come.

It's polite

Matty


On Thu, Jun 12, 2014 at 12:48 PM, Richard Harding 
rick.hard...@canonical.com wrote:

 We try to put a main comment on the review. Having inline comments does not
 complete the review. So after going through the diff, we go back to the
 main pull request and leave a comment there.

 This looks good but I had a few concerns about how it's tested. Please
 don't forget to update the docs as well. Looking forward to this change.

 It kind of wraps it up.

 The other thing we often do is ping in irc that the review is :+1: or
 'comments sent'.

 https://github.com/juju/juju-gui/pull/328 is kind of an example
 conversation.

 Rick

 On Thu, 12 Jun 2014, Ian Booth wrote:

  It's also the same when you are responding to review comments. You want
 to mark
  them all as Done (or whatever) and have those go out in a batch to let
 the
  reviewer know they can come back and +1.
 
  Surely we're not the only people annoyed by this? I wonder what more
 experienced
  github users do. Or maybe people know that github sucks for code reviews
 and use
  gerrit or something else?
 
  On 12/06/14 20:38, Horacio Duran wrote:
   Hey, I don't know if this bugs everyone or just me but it happens very
   often that I am working while people are reviewing my code on gh. While
   people is reviewing and commenting on the code I keep getting mails
 and the
   diff page from the pr keeps changing. To know when its all done and I
 can
   finally try to answer/fix all the comments I usually wait until my
 phone
   stops ringing madly with mails but I think that we could do better. At
 the
   end of the diff page there is a comment box where you can add comments
   (where you usually add your $$merge$$ or LGTM) We could add something
   there, like Done just to let the author know we are done with the
 review
   and not just reading a big confusing chunk of code.
   What do you people think?

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev