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

juju run-action --application?

[Matthew Williams]

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

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

Problem with lxd on master - How do I debug this?

[Matthew Williams]

Hey folks,

the lxd provider has been working fine for me - until this morning. I'm
running on master (1cb8f0)

I've attached output from juju debug-log juju status and lxd list, can
someone help me work out what I should do to resolve this.

The history leading up the attached logs is:

1) Everything was working
2) A deployed a charm that had a hook install error (I was debugging said
charm, so that was expected). I couldn't ssh to the unit. I got the
following error:
$ juju ssh foobar/0
ERROR error fetching address for unit "foobar/0": private no address.

juju debug log showed:

 machine-4: 2016-02-01 11:53:39 ERROR juju.worker runner.go:229 exited
"machiner": setting machine addresses: cannot set machine addresses of
machine 4: state changing too quickly; try again soon

After doing what debug I can I destroyed the controller. Now whenever I
bootstrap a lxd environment I get the state server and everything else
get's stuck in allocation. Attached is more detailed stuff from the logs.
What should I do to work out what's going on here?

Matty
$ juju debug-log

machine-0: 2016-02-01 13:48:44 WARNING juju.state allwatcher.go:352 getting a public address for unit "wordpress2/0" failed: "public no address"
machine-0: 2016-02-01 13:48:44 WARNING juju.state allwatcher.go:356 getting a private address for unit "wordpress2/0" failed: "private no address"
machine-0: 2016-02-01 13:48:47 ERROR juju.state.unit unit.go:739 unit mysql/0 cannot get assigned machine: unit "mysql/0" is not assigned to a machine
machine-0: 2016-02-01 13:48:49 ERROR juju.state.unit unit.go:739 unit mysql/0 cannot get assigned machine: unit "mysql/0" is not assigned to a machine
machine-0: 2016-02-01 13:48:49 ERROR juju.state.unit unit.go:739 unit mysql/0 cannot get assigned machine: unit "mysql/0" is not assigned to a machine
machine-0: 2016-02-01 13:48:49 WARNING juju.state allwatcher.go:352 getting a public address for unit "mysql/0" failed: "unit mysql/0 cannot get assigned machine: unit \"mysql/0\" is not assigned to a machine"
machine-0: 2016-02-01 13:48:49 ERROR juju.state.unit unit.go:749 unit mysql/0 cannot get assigned machine: unit "mysql/0" is not assigned to a machine
machine-0: 2016-02-01 13:48:49 WARNING juju.state allwatcher.go:356 getting a private address for unit "mysql/0" failed: "unit mysql/0 cannot get assigned machine: unit \"mysql/0\" is not assigned to a machine"
machine-0: 2016-02-01 13:48:54 WARNING juju.state allwatcher.go:352 getting a public address for unit "mysql/0" failed: "public no address"
machine-0: 2016-02-01 13:48:54 WARNING juju.state allwatcher.go:356 getting a private address for unit "mysql/0" failed: "private no address"

$ juju status
wordpress/0   unknownallocating  4Waiting for agent initialization to finish
mysql/0  unknownallocating  5Waiting for agent initialization to finish

$ lxc list
+-+-+---+--+---+---+
|NAME |  STATE  |   IPV4| IPV6 | EPHEMERAL | SNAPSHOTS |
+-+-+---+--+---+---+
| juju-91f8c399-fc79-42e3-81f1-2725536bfcbb-machine-0 | RUNNING | 10.0.3.157 (eth0) |  | NO| 0 |
+-+-+---+--+---+---+
-- 
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

Re: public no address error in juju status

[Matthew Williams]

I've done a PR for it just in case: http://reviews.vapour.ws/r/3199/

On Tue, Nov 17, 2015 at 9:29 PM, Menno Smits 
wrote:

> I noticed this too but I was working on a critical bug and didn't want to
> get distracted by it. The warning seems to get emitted by each call to the
> FullStatus API for each machine without a public address (which happens
> during provisioning). Once the machine has an address the warning stops. A
> warning seems like a poor choice for such a routine event.
>
> Git says Mr Foord is the author of that line. Michael, is there any reason
> not to drop the log level to DEBUG for this?
>
> On 17 November 2015 at 06:29, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> On a tip(ish) juju (built end of last week) I was running on the local
>> provider and looking at the debug-log while watching juju status.
>>
>> The debug log was full of the following:
>> http://paste.ubuntu.com/13300268/
>>
>> Seems a bit noisy, and also sometimes quotes and sometimes not (status.go:448
>> and status.go:660).
>>
>> Does anyone know where this is coming from, feels like it should be
>> cleanup up a bit?
>>
>> 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

public no address error in juju status

[Matthew Williams]

On a tip(ish) juju (built end of last week) I was running on the local
provider and looking at the debug-log while watching juju status.

The debug log was full of the following:
http://paste.ubuntu.com/13300268/

Seems a bit noisy, and also sometimes quotes and sometimes not (status.go:448
and status.go:660).

Does anyone know where this is coming from, feels like it should be cleanup
up a bit?

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

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

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

Godeps PSA (or don't make the same mistake I did)

[Matthew Williams]

I managed to break windows builds yesterday by removing a dependency from
dependecies.tsv. I did this by running godeps - checking the diff and
getting excited about being able to remove an unused dependency.

But we currently need to import a package for windows builds that we don't
for ubuntu.

diff <(godeps -t github.com/juju/juju/...) <(GOOS=windows godeps -t
github.com/juju/juju/...)

It's an easy and silly mistake to make. But thought I'd send an email in
the hope that I can stop others from doing it

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

gocheck in non test code

[Matthew Williams]

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

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

Re: commands

[Matthew Williams]

Looks awesome Nick - it would be nice if we could expand the subcommands as
well (like in user)

mattyw

On Tue, Feb 3, 2015 at 8:25 PM, Nate Finch  wrote:

> I'm so glad these are getting auto generated so they stay in sync.
>
> They should be consistent in style, we should choose capitalized or not
> and stick with it.  I don't really care which.
> On Feb 3, 2015 7:08 AM, "Nick Veitch"  wrote:
>
>> Hello,
>>
>> I have just finished updating the all-new exciting and more comprehensible
>> commands reference page in the docs for 1.21.1:
>>
>> https://juju.ubuntu.com/docs/commands.html
>>
>> The more observant of you will notice that the content has almost all been
>> autogenerated directly from juju help. This is exciting (for me
>> anyway) because I have long yearned for these to sync better. Some
>> commands are better explained than others, and some could do with some
>> examples, but I can contribute those.
>>
>> Before I do that, I did have a question - there are some consistent
>> inconsistencies in the style of the output; for example, there is
>> 'purpose:' and 'usage:', but 'Example:' is capitalised. Is there some
>> compelling reason for this wrongness which people have passionate
>> opinions about, or can I fix it (i.e. "Usage:", etc.)?
>>
>>
>> --
>> Nick Veitch
>> nick.vei...@canonical.com
>>
>> --
>> 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

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

> On Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina
>  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: Is ReviewBoard a good thing?

[Matthew Williams]

You can use kanban for a unified view of reviews, but reviewboard is better
- you are able to see which reviews are missing comments and which ones are
approved but not landed without having to click through multiple windows.
Also the kanban board isn't viewable by everyone AFAIK.

Everyone else has already commented on the things I like - and the things I
don't: I like being able to have parent branches* and the unified review
queue, but I do worry that the benefit of these doesn't justify the cost of
another tool.

I do think it's too early to tell though. Why not give it another week or 2
then discuss in the cross teams if we want to keep it or not

Matty

* I worry that parent  (pre req) branches might be an anti-pattern. A topic
for another thread maybe

On Fri, Sep 19, 2014 at 2:44 PM, Richard Harding  wrote:

> On Fri, 19 Sep 2014, Nate Finch wrote:
>
> > There's one thing that hasn't been mentioned - reviewboard gives us a
> > unified review queue.
>
> Can I ask how kanban doesn't do this job for you? I've heard this said a
> couple of times but I realized the way I find out what needs to be looked
> at is to go to kanban not github. I do that for the same reason. We've got
> teams working on 4 different github projects under two different orgs at
> the moment. Using the source control as a source seems pretty doomed. You
> already have a 3rd party tool to track that, kanban.
>
> Rick
>
> --
> 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 
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... > 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

Unit Tests & Integration Tests

[Matthew Williams]

Hi Folks,

There seems to be a general push in the direction of having more mocking in
unit tests. Obviously this is generally a good thing but there is still
value in having integration tests that test a number of packages together.
That's the subject of this mail - I'd like to start discussing how we want
to do this. Some ideas to get the ball rolling:

Having integration tests spread about the package and having environment
variables that switch on/ off them being run

$ JUJU_INTEGRATION go test ./...

We could make use of build tags:

$ go test -tags integration ./...

We could put all the integration tests in a single package:

$ go test github.com/juju/juju/integrationtests/...


Thoughts?

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

Re: Testing api clients

[Matthew Williams]

Thanks Andrew,

I was almost about to reimplement this myself - making use of it right now

Thanks

Matty

On Thu, Sep 11, 2014 at 5:57 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> Hi folks,
>
> I'd like to bring a small, recent addition to everyone's attention:
> https://github.com/juju/juju/blob/master/api/base/testing/patch.go
>
> PatchFacadeCaller can be used (and is used now in several places) to avoid
> calling through to a real API server in api tests. Ideally we'd just
> provide mock FacadeCallers to begin with, but this alleviates some of the
> pain between now and when we do that across all the existing tests.
>
> If you're writing tests for api clients, please consider using
> PatchFacadeCaller or a mock FacadeCaller, so we can improve test coverage
> and avoid slow tests.
>
> Cheers,
> Andrew
>
> --
> 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  wrote:

> On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey 
> 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: 

ERROR juju.state failed to stop presence watcher: 

ERROR juju.state failed to stop all manager: 

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

> On 01/09/2014, John Meinel  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

juju local bootstrap from tip

[Matthew Williams]

Hi Folks,

I thought I'd try looking into the lxc failing to creates machines bug:
https://bugs.launchpad.net/juju-core/+bug/1363143

If I wanted to do a local deploy using tip I thought it would be as simple
as doing make install then juju bootstrap is that correct? It doesn't seem
to work for me, are there any steps I'm missing

Just to be annoying - I've just shutdown my precise vm so I can't paste the
errors I get here. I'll follow up with pastes next week

Matty
-- 
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 
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: Please Write Package Docs

[Matthew Williams]

Great idea, I'll do it


On Thu, Aug 21, 2014 at 5:52 PM, Nate Finch 
wrote:

> There's this great facility in Go where you can write a comment on the
> package  declaration, and that comment will get used as top-level docs
> in godoc.  We should be using this, and (in general) we're not.
>
> This is a way to communicate why a package exists and what its code does
> in general terms.  This is useful to both help developers understand the
> code in the package, but also to help them understand whether new code
> should go into that package or somewhere else.  Good package docs can
> prevent our code from getting too spaghetti'd by having unrelated code in
> the same package.
>
> I suggest that all new packages should have package docs, and we should
> try to add package docs to existing packages when it's convenient.  If a
> package is only a single non-test file (and is very likely to stay that
> way), the package docs can just live in that single file.  If a package is
> multiple non-test files, and/or has a reasonable likelihood of being
> extended with more files, it's better to put the package docs in a
> canonical place so it's easy to find, which is traditionally a file called
> doc.go
>
> If you need help writing godoc, or just want a refresher, please read
> through my godoc tutorial: https://godoc.org/github.com/natefinch/godocgo
>
> -Nate
>
> --
> 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 
wrote:

> On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams
>  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 
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
> >  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" 
wrote:

> +1
>
> Great idea, thank you
> On 18 Jul 2014 03:28, "Tim Penhey"  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 com

Re: Reviewing - moving to review mentors, and guidelines

[Matthew Williams]

+1

Great idea, thank you
On 18 Jul 2014 03:28, "Tim Penhey"  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 
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 
> 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)
>>  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

Open Ports on Ranges

[Matthew Williams]

I've spent some time over the last couple of days looking into  lp:1216644
- being able to open a range of ports in a charm:

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

Here are some notes taken during various conversations, as well as a task
list:

https://docs.google.com/a/canonical.com/document/d/1b5y5_wBkNXLvQhzkbgVphSMR260AWdtya0R2NLDX-U0/edit#heading=h.6kfmx9sa5a4n

If anyone has any comments let me know or put them in the doc

Thanks

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

Re: Juju Academy

[Matthew Williams]

This is awesome Marco, I'll help out where I can


On Wed, May 7, 2014 at 5:16 PM, Marco Ceppi  wrote:

> Hi everyone!
>
> I was trying to keep this under wraps as I worked on it more before
> announcing to the world but I'm too excited with the progress so far so
> here's the "SUPER ALPHA BETA OMEGA" introduction to Juju Academy.
>
> I started this, http://juju.academy (http://learnjuju.com) based on my
> own experiences when trying new software. Primarily modeled after the Learn
> Go Lang webiste (http://tour.golang.org/) I set out to create an easy
> platform that emulates a terminal environment and allows a user to try Juju
> before ever having to install it. In addition I wanted to make a
> lightweight lesson framework to help guide new users in this exciting new
> Service Orchestration paradigm. Finally, the last goal of this project was
> to build an easy to embed module that could live in the docs to provide
> very lightweight terminal sessions that users could use to review what
> portions of the docs they were reading.
>
> Right now I've modeled just a hand full of lessons and only a few of the
> juju commands have actually been implemented. As this is a spare time
> project progress comes in chunks of time over the weekend and in the
> evenings. However, if you're interested in piloting the demoware and
> shaking out bugs please do so! You can view the lessons at
> http://juju.academy the source code is
> https://github.com/marcoceppi/juju-academy and the issue tracker is on
> that repo.
>
> Your juju environment(s) persist not only between lessons but also between
> page visits. If at anytime you wish to start anew you can do so by issuing
> the "reset" command in the terminal. I'm working on finishing
> http://help.juju.academy which will have this and other FAQ/Guide like
> questions to use the software. All Juju help can be found, as always, at
> https://juju.ubuntu.com/docs
>
> This is also a call for help! Anyone interested in writing lessons,
> command modules, fixing bugs, making this look nicer, etc - pull requests
> are welcome! The entire project aims to be modular (in that this framework
> could be used for non juju terminal lessons). Lessons are simply JSONP
> files that contain a set number of keys and commands are functions that
> perform some rudimentary validation.
>
> I eagerly await feedback and have had an immense amount of fun working on
> this so far! I'll likely follow up with a more official announcement when
> more of the commands have been implemented.
>
> Thanks,
> Marco Ceppi
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev