Re: Deploying a charm with t's & c's

[Matthew Williams]

Hi Tom,

This appears to be a problem with the 2.2.2 controller which has been fixed
in later versions. If you try a different aws region you should get a more
up to date controller and it should work as expected.

e.g. $ juju add-model mymodel aws/eu-west-1

Hope this helps

Matty

On Mon, Dec 4, 2017 at 2:22 PM, Tom Barber <t...@spicule.co.uk> wrote:

> mymodel  jaasaws/us-east-1  2.2.2unsupported
>
> Tom
>
>
> On 04/12/17 14:08, Matthew Williams wrote:
>
> Hi Tom,
>
> What version of the controller are you using (show in juju status). Is
> this your own controller or are you using jimm?
>
> Thanks
>
> Matty
>
> On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber <t...@spicule.co.uk> wrote:
>
>> Hi Casey
>>
>> https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll see here.
>> #45 works for me also but #47 fails. I don't think we changed anything
>> massively but clearly something in there is sad, the problem is that, the
>> error thrown gives me no indication of where we've messed up.
>>
>> On a side note I wanted to grab the zip archive of #45 and #47 and do a
>> diff to see if it was obvious but both give me a 404 from the charm store.
>>
>> juju list-agreements
>> Term Agreed on
>> isrg-lets-encrypt/2  2017-04-26 09:43:38 + UTC
>> canonical/sla-terms/32017-08-31 21:19:16 + UTC
>> spiculecharms/pdi-terms/12017-11-27 23:24:11 + UTC
>>
>> Tom
>>
>>
>> On 04/12/17 02:54, Casey Marshall wrote:
>>
>> Tom,
>> With 2.2.6, I cannot reproduce any problems with deploying your charm.
>> See https://paste.ubuntu.com/26109617/
>>
>> Please send me more information about your installation:
>>
>> - How you installed Juju (snap, deb from PPA, compiled from source, etc.)
>> - Platform information on the machine you're running the Juju client on,
>> OS, etc. Is it on a physical host, in a VM, in a container?
>> - What cloud you're trying to deploy into
>>
>> If you type `juju list-agreements`, does that show terms you've agreed to?
>>
>> -Casey
>>
>> On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber <t...@spicule.co.uk> wrote:
>>
>>> Just as a quick update, I get the same if I deploy the charm directly
>>> and from the charm store ie not in a bundle.
>>>
>>> But removing the terms in the metadata.yaml removes the error.
>>>
>>> Tom
>>>
>>>
>>> On 28/11/17 18:36, Stephen Downie wrote:
>>>
>>> Thanks for looking into this Casey. The version of Juju I'm running is
>>> 2.2.6-xenial-amd64
>>>
>>>
>>> Spicule Ltd
>>>
>>> Tel: 01603 327762
>>>
>>>
>>>
>>> www.spicule.co.uk
>>>
>>> On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall <
>>> casey.marsh...@canonical.com> wrote:
>>>
>>>> On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber <t...@spicule.co.uk> wrote:
>>>>
>>>>> hey Casey
>>>>>
>>>>> if you have no models and try and deploy a bundle with terms it shows
>>>>> you the deploy screen them hangs. if you go back you see the model with 0
>>>>> units deployed.
>>>>>
>>>>> this is a local bundle we were testing, just exported from the gui,
>>>>> Ste can provide it if you need it.
>>>>>
>>>>
>>>> Thanks for clarifying. One last question, what version of Juju was used
>>>> on the command line when trying to deploy the exported bundle?
>>>>
>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> On 28 Nov 2017 6:00 pm, "Casey Marshall" <casey.marsh...@canonical.com>
>>>>> wrote:
>>>>>
>>>>> On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie <
>>>>> step...@spicule.co.uk> wrote:
>>>>>
>>>>>> Thanks. I have tried running juju agree spiculecharms/pdi-terms/1 and
>>>>>> it states terms already agreed?
>>>>>>
>>>>>> When trying to deploy in the GUI it returns the error message cannot
>>>>>> create bundle: already exists. It appears that it creates the model but
>>>>>> does't actually deploy anything? I know I'm a bit new to this but 
>>>>>> something
>>>>>> seems a bit broken.
>>>>>>
>>>>>
&

Re: Deploying a charm with t's & c's

[Matthew Williams]

Hi Tom,

What version of the controller are you using (show in juju status). Is this
your own controller or are you using jimm?

Thanks

Matty

On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber  wrote:

> Hi Casey
>
> https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll see here. #45
> works for me also but #47 fails. I don't think we changed anything
> massively but clearly something in there is sad, the problem is that, the
> error thrown gives me no indication of where we've messed up.
>
> On a side note I wanted to grab the zip archive of #45 and #47 and do a
> diff to see if it was obvious but both give me a 404 from the charm store.
>
> juju list-agreements
> Term Agreed on
> isrg-lets-encrypt/2  2017-04-26 09:43:38 + UTC
> canonical/sla-terms/32017-08-31 21:19:16 + UTC
> spiculecharms/pdi-terms/12017-11-27 23:24:11 + UTC
>
> Tom
>
>
> On 04/12/17 02:54, Casey Marshall wrote:
>
> Tom,
> With 2.2.6, I cannot reproduce any problems with deploying your charm. See
> https://paste.ubuntu.com/26109617/
>
> Please send me more information about your installation:
>
> - How you installed Juju (snap, deb from PPA, compiled from source, etc.)
> - Platform information on the machine you're running the Juju client on,
> OS, etc. Is it on a physical host, in a VM, in a container?
> - What cloud you're trying to deploy into
>
> If you type `juju list-agreements`, does that show terms you've agreed to?
>
> -Casey
>
> On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber  wrote:
>
>> Just as a quick update, I get the same if I deploy the charm directly and
>> from the charm store ie not in a bundle.
>>
>> But removing the terms in the metadata.yaml removes the error.
>>
>> Tom
>>
>>
>> On 28/11/17 18:36, Stephen Downie wrote:
>>
>> Thanks for looking into this Casey. The version of Juju I'm running is
>> 2.2.6-xenial-amd64
>>
>>
>> Spicule Ltd
>>
>> Tel: 01603 327762
>>
>>
>>
>> www.spicule.co.uk
>>
>> On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall <
>> casey.marsh...@canonical.com> wrote:
>>
>>> On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber  wrote:
>>>
 hey Casey

 if you have no models and try and deploy a bundle with terms it shows
 you the deploy screen them hangs. if you go back you see the model with 0
 units deployed.

 this is a local bundle we were testing, just exported from the gui, Ste
 can provide it if you need it.

>>>
>>> Thanks for clarifying. One last question, what version of Juju was used
>>> on the command line when trying to deploy the exported bundle?
>>>
>>>

 Tom


 On 28 Nov 2017 6:00 pm, "Casey Marshall" 
 wrote:

 On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie  wrote:

> Thanks. I have tried running juju agree spiculecharms/pdi-terms/1 and
> it states terms already agreed?
>
> When trying to deploy in the GUI it returns the error message cannot
> create bundle: already exists. It appears that it creates the model but
> does't actually deploy anything? I know I'm a bit new to this but 
> something
> seems a bit broken.
>

 Is it possible that the model name in the GUI (the drop down in the
 upper-left of the canvas) matched an already-created model name? You might
 need to type in a new model name there.

 Or does this happen for new models with this bundle no matter what?

 Was this in the GUI in JAAS (jujucharms.com)? Did you try deploying a
 bundle from the charmstore, or did you try importing a bundle.yaml file?


>
> Thanks all for your help.
>
> Spicule Ltd
>
> Tel: 01603 327762
>
>
>
> www.spicule.co.uk
>
> On Tue, Nov 28, 2017 at 12:33 PM, Tom Barber 
> wrote:
>
>> stupid question, but I assume the bundles should handle t's better?
>>
>> On 28 Nov 2017 12:29, "Ales Stimec" 
>> wrote:
>>
>>> Hi,
>>>
>>> Could you please try
>>>juju agree spiculecharms/pdi-terms/1
>>>
>>> This is these are the terms that require agreement in order to
>>> deploy cs:~spiculecharms/pentaho-data-integration-45.
>>> To get a list of terms i used:
>>>curl "https://api.jujucharms.com/charmstore/v5/~spiculecharms/pen
>>> taho-data-integration-45/meta/any?include=id=terms"
>>>
>>> Best regards,
>>> Ales Stimec
>>>
>>> PS: fyi: the terms service issues short-lived macaroons (auth
>>> tokens) that are valid for 5 minutes…
>>>
>>>
>>>
>>> On 28 Nov 2017, at 12:59, John Meinel 
>>> wrote:
>>>
>>> Do you know what terms you need to accept? You should be able to
>>> 'juju accept termname'.
>>> The other thing to check is if 

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

[Matthew Williams]

Just replying publicly to confirm that this was done earlier this morning

Thanks

Matty

On Thu, Aug 11, 2016 at 10:30 AM, Shruthima Almavar 
wrote:

> Hi,
> We have sent a request for terms creation through the terms link (
> https://docs.google.com/forms/d/1sOfp0a6KLY9kqnpPeGwHv_
> YQJv7LEbXH1CAV-xBaMjU/viewform?edit_requested=true
> 
> )
> for the following charms:
>
> ibm-http-server
> ibm-http-plg
> ibm-http-wct
> ibm-mobilefirstserver
> ibm-spectrum-scale
>
>
> Could you please create terms as soon as possible.
>
> Thank you..!!!
>
> Regards,
> Shruthima
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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: Query on juju 2.0 installation

[Matthew Williams]

Hi Krishna,

You can use the lxd provider. There are instructions at the following places

https://jujucharms.com/docs/devel/config-LXD
https://jujucharms.com/docs/devel/controllers-creating

Thanks

Matty

On Fri, Apr 1, 2016 at 8:25 AM, Krishna Bandi  wrote:

> Hi Team,
>
>  Hope you all doing great. I was trying to use ibm-base-layer and as
> confirm by Matt it uses juju 2.0 so I was trying to install juju 2.0 on
> ubuntu x86 machine by following the link
> https://jujucharms.com/docs/devel/introducing-2and found it has steps for
> aws setup only and I am not able to install local lxc containers.
>
> Can you please advise on how to set up local lxc containers using juju
> 2.0.
>
> Also we are not able to install juju 2.0 on power machine, please suggest
> on this.
>
> Thanks & Regards,
>
> Bandi K Chaitanya
> --
> *Mobile:*+91-973145
> *E-mail:* *kriba...@in.ibm.com* 
> [image: IBM]
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Matthew Williams]

Would it not be better for the charm to have a path the client can `wget`
the libraries from - this path can be sent via the relation as a string

Matty

On Wed, Jan 20, 2016 at 2:30 PM, José Antonio Rey  wrote:

> Hey,
>
> One of the options would be to cat the file as a string and pass that
> string over the connection, finally echoing that string to foo.binary.
>
> What do others think?
>
> --
> José Antonio Rey
>
> On Wed, Jan 20, 2016, 08:25 Merlijn Sebrechts 
> wrote:
>
>> Hi
>>
>>
>> I have a question I'd like to discuss, if you guys aren't to busy
>> prepping for Ubucon.. :)
>>
>> I've found a number of Java projects where, in order to communicate for
>> example with Kafka, they require the Kafka Java libraries for that specific
>> version. For the moment, I solve this by downloading the libraries from a
>> deployed Kafka installation and include them in the Charm. However, this
>> has the disadvantage that everytime the Kafka charm version changes, I have
>> to update the libraries in all the charms that connect to Kafka. It would
>> be better if there was a way to send these libraries over the connection.
>> This way, a Charm that can connect to one version of Kafka has a very high
>> chance of being able to connect to the next version.
>>
>> So my question is: Is there a way to send large binary files between
>> Charms? Or is this problem better solved by using a subordinate
>> kafka-plugin Charm like the Hadoop Charms do?
>>
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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: JNS: Juju Name Server

[Matthew Williams]

That's an awesome idea and tool Andrew thanks for sharing. Any plans for
turning it into a charm? Would only take moments with the go binary charm
layer

Matty
On 5 Jan 2016 08:13, "Andrew Wilkins"  wrote:

> Hi,
>
> A little while ago, I found myself wanting to address a service by its
> Juju name, but outside of Juju. I didn't want to be tied to an IP/host
> name, because they might change; I didn't want to be tied to any one cloud
> provider; and I wanted it to work across environments.
>
> So I wrote a little DNS server that resolves Juju entity names to IP
> addresses. It's called "jns", Juju Name Server. You can find it here:
> https://github.com/axw/jns
> (go get github.com/axw/jns)
>
> Names take one of the following forms:
> 0.juju# machine 0
> machine-0-lxc-0.juju # machine 0/lxc/0
> mysql.juju # IP address of a random unit of the mysql
> service
> unit-mysql-0.juju   # IP address of mysql/0
>
> In the above forms, the entity is within the current environment. If you
> want to resolve the address of an entity in another environment, you can
> precede ".juju" with the name of the environment. e.g.
> mysql.prod.juju
> mysql.dev.juju
> etc.
>
> Enjoy.
>
> Cheers,
> Andrew
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju, LXD, Snappy, Raspberry pi

[Matthew Williams]

Me again folks,

Just for fun:

Now that lxd provider support is in juju, and there is a snap for lxd. I
wondered if it would be possible to use juju to deploy lxd units on a
raspberry pi 2.

Here's the result:
http://blog.mattyw.net/blog/2015/12/02/juju-lxd-snappy-pi/

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

Re: Juju, LXD, Snappy, Raspberry pi

[Matthew Williams]

Hi Sam,

That's a very good point, in theory that is possible yes, It's actually one
of the other experiments I'm trying, I've not as yet been able to setup
port forwarding on snappy to be able to access the containers from outside
the pi, or been able to get the containers to get a dhcp address from my
home router, but these are things I'm also playing with

Matty

On Thu, Dec 3, 2015 at 1:50 PM, Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> Hi Matthew,
>
> Great stuff, thanks for sharing :)
>
> Quick question, if you set the LXD provider to work remotely, do you
> really need to compile Juju to run on the rpi? Can't it run from the
> laptop, with a rpi2 being just the target?
>
> Thx,
> Sam
>
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> /
> Juju <https://jujucharms.com>
> samuel.cozan...@canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> <https://es.linkedin.com/in/scozannet>
>
> On Thu, Dec 3, 2015 at 2:19 PM, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> Me again folks,
>>
>> Just for fun:
>>
>> Now that lxd provider support is in juju, and there is a snap for lxd. I
>> wondered if it would be possible to use juju to deploy lxd units on a
>> raspberry pi 2.
>>
>> Here's the result:
>> http://blog.mattyw.net/blog/2015/12/02/juju-lxd-snappy-pi/
>>
>> Matty
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Sunitha,

I believe you can do the following:

unit_manager_0 = self.d.sentry["ibm-mobilefirst-server"][0]

Does that resolve the problem?

Many thanks

Matty

On Fri, Nov 13, 2015 at 9:50 AM, Sunitha Radharapu 
wrote:

> Hi,
>
> We have found in juju *1.25.0.1* version that each time service gets
> deployed unit number is increased like below.
> "service-name/1, service-name/2, service-name/n.."
> Earlier juju versions everytime we would deploy unit number would be same
> as "service-name/0".
>
> Due to this change our amulet tests are failing since we have hardcoded
> unit name as shown below;
>
> def test_case(self):
> self.assertTrue(self.d.deployed)
> unit_manager_0 = self.d.sentry.unit['*ibm-mobilefirst-server/0*']
> address = unit_manager_0.info['public-address']
>
> Can you please suggest a way to get dynamic unit name while running tests.
>
> Thanks,
> Sunitha.
>
>
>
>
>
>
>
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Sunitha,

The bug is closed, it was fixed and released in juju 1.25.

There are some docs at the below link that summarise the behaviour:

https://jujucharms.com/docs/1.25/reference-numbering

If you'd like to have a talk about this I'd be very happy to. I'm mattyw on
irc in #juju and #juju-dev (otherwise email is fine)

Thanks

Matty



On Fri, Nov 13, 2015 at 3:49 PM, Sunitha Radharapu <sradh...@in.ibm.com>
wrote:

> Hi Matt,
>
> I am a little bit confused here, bug description says it should be as
> unique id. If it is a bug and you are going to fix in future juju releases
> then we no need to change our amulet tests.
>
> If it is a new feature then we will change our upcoming charms
> accordingly,
>
> Thanks,
> Sunitha.
>
>
>
>
> [image: Inactive hide details for Matthew Williams ---13-11-2015
> 20:32:45---Hi Mark, Sunitha, My apologies, I should have included the]Matthew
> Williams ---13-11-2015 20:32:45---Hi Mark, Sunitha, My apologies, I should
> have included the explanation in the original email.
>
> From: Matthew Williams <matthew.willi...@canonical.com>
> To: Mark Shuttleworth <m...@ubuntu.com>
> Cc: Sunitha Radharapu/India/IBM@IBMIN, Juju email list <
> juju@lists.ubuntu.com>
> Date: 13-11-2015 20:32
> Subject: Re: Unit number is increasing in latest juju version.
> --
>
>
>
> Hi Mark, Sunitha,
>
> My apologies, I should have included the explanation in the original email.
>
> This was a change to address a long standing bug:
> *https://bugs.launchpad.net/juju-core/+bug/1174610*
> <https://bugs.launchpad.net/juju-core/+bug/1174610>
>
> There's a discussion in the bug report, but the summary is that in most
> cases it's desirable to have the unit id be unique across the life of an
> environment. Otherwise you loose the identity of a unit across relations.
>
> We were already numbering the machines in the same way, so this change
> also gives us consistency between machine and unit numbering systems.
>
> Thanks
>
> Matty
>
> On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth <*m...@ubuntu.com*
> <m...@ubuntu.com>> wrote:
>
>
>Thanks Sunitha. Matty, deeper question is - was this an intended change
>in behaviour, and what's the rationale?
>
>Mark
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Mark, Sunitha,

My apologies, I should have included the explanation in the original email.

This was a change to address a long standing bug:
https://bugs.launchpad.net/juju-core/+bug/1174610

There's a discussion in the bug report, but the summary is that in most
cases it's desirable to have the unit id be unique across the life of an
environment. Otherwise you loose the identity of a unit across relations.

We were already numbering the machines in the same way, so this change also
gives us consistency between machine and unit numbering systems.

Thanks

Matty

On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth  wrote:

>
> Thanks Sunitha. Matty, deeper question is - was this an intended change
> in behaviour, and what's the rationale?
>
> Mark
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Lots of free video training sessions tomorrow

[Matthew Williams]

In addition, if you're not bored of hearing about my side projects I'm
running a show and tell at 7PM UTC today that talks about using juju to
model network partitions:

http://summit.ubuntu.com/uos-1511/meeting/22571/modelling-network-partitions-with-juju/

Matty

On Tue, Nov 3, 2015 at 2:54 PM, Jorge O. Castro  wrote:

> Hi everyone,
>
> We're running a track as part of the Ubuntu Online Summit and tomorrow
> is Juju day:
>
> Wednesday, 4 Nov, starting at 1800UTC:
> http://summit.ubuntu.com/uos-1511/track/cloud/
>
> Click on any of those sessions and that will take you to a page where
> you can watch a video and chat in the chat box. If you're writing
> charms and are NOT yet using layers and charm build then you're really
> missing out, that session is at 1500UTC, here are the docs for that if
> you want to start reading now:
> https://jujucharms.com/docs/stable/authors-charm-building
>
> As always, the sessions will be recorded and if you want to hop into a
> session and participate then we'd love that.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - Automate your Cloud Infrastructure
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

[Matthew Williams]

Hey Folks,

Is there some action we should take to deal with this - in which case can
we raise an lp bug for it. Or do we think there's no action needed?

Matty

On Tue, Oct 6, 2015 at 3:55 PM, Matt Bruzek 
wrote:

> Merlijn,
>
> Now that I see more of what you are doing I have an alternate suggestion.
>
> When you are running 'juju init' use the su command to run as the "ubuntu"
> user.
>
> su - ubuntu -c 'juju init'
>
> Using the su command in this way gives a "login" environment for the user
> "ubuntu".  I wrote a charm (named merlijn) to test this and I saw the error
> you are reporting:
> unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
> unit.merlijn2/0.config-changed logger.go:40 + echo /root
> unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
> unit.merlijn2/0.config-changed logger.go:40 /root
> unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
> unit.merlijn2/0.config-changed logger.go:40 + juju init
> unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
> unit.merlijn2/0.config-changed logger.go:40 error: cannot determine juju
> home, required environment variables are not set
>
> What you were trying to do is create a juju environment for the root user
> (which is not advised) rather you want to create a juju environment for the
> normal (ubuntu) user.
>
> Using the su command I was able to create a juju configuration file:
> 2015-10-06 14:47:10 INFO config-changed + echo /root
> 2015-10-06 14:47:10 INFO config-changed /root
> 2015-10-06 14:47:10 INFO config-changed + su - ubuntu -c 'juju init'
> 2015-10-06 14:47:11 INFO config-changed A boilerplate environment
> configuration file has been written to /home/ubuntu/.juju/environments.yaml.
>
> Likewise if you want to create artifacts for the ubuntu user, use the "su
> - ubuntu" command.
>
> Hope that helps.
>
>
>- Matt Bruzek 
>
> On Tue, Oct 6, 2015 at 9:30 AM, Cory Johns 
> wrote:
>
>> Merlijn,
>>
>> That is an annoying inconsistency.  It's probably related to debug-hooks
>> bootstrapping itself via `juju ssh` which logs in as the ubuntu user since
>> root ssh is disabled, as well as it being unlikely that the actual hook
>> context is a login shell.
>>
>> I imagine the generate-config error is due to the lack of either $HOME or
>> $JUJU_HOME being set.  I would recommend trying explicitly setting
>> JUJU_HOME=/home/ubuntu before calling generate-config and see if that works
>> around it.
>>
>> I've also created a bug against juju-core for this:
>> https://github.com/juju/juju/issues/3449
>>
>> On Tue, Oct 6, 2015 at 10:06 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>>
>>> Hi Matt
>>>
>>>
>>> Thank you for your response. It was nice seeing you too!
>>>
>>> Let me explain my two, maybe related problems a bit more:
>>>
>>>
>>> 1. Home directory is different between debug and non-debug hook context.
>>>
>>>- Using the manual provider.
>>>- When deploying a Charm, the install hook is run as the "root" user.* 
>>> "echo
>>>~" prints "/root".*
>>>- When the install hook crashes, I connect to the unit using
>>>`debug-hooks` and restart the install hook as you described using  'juju
>>>resolved --retry unit/#'. After a while, tmux shows "[unit/0] 0:bash-
>>>1:install* " at the bottom and cwd is 
>>> '/var/lib/juju/agents/unit-0/charm'.
>>>As I understand, I am now in the hook context, right? *However,
>>>"echo ~" prints "/home/ubuntu".* Even though the current user is
>>>root.
>>>
>>>
>>>
>>> 2. Something causes "juju init" to fail in non-debug hook context and
>>> succeeds in debug hook context.
>>>
>>>
>>>- Using manual provider
>>>- Executing `juju init` or `juju generate-config` in a hook results
>>>in the error message `error: cannot determine juju home, required
>>>environment variables are not set`
>>>- Executing `juju init` or `juju generate-config` in the hook
>>>context using  `debug-hooks` and  'juju resolved --retry unit/#`
>>>succeeds.
>>>
>>>
>>> My current workaround is to generate the initial juju config myself and
>>> not use "juju generate-config". However, I'm not sure if this behavior is
>>> intentional or a bug.
>>>
>>>
>>> Thanks in advance!
>>>
>>>
>>> 2015-10-06 15:37 GMT+02:00 Matt Bruzek :
>>>
 Hell again Merlijn,

 It was nice to see you at the Charmer summit!  This is a very
 interesting use of Juju.

 What you are seeing is what we call a "hook context".  Hooks execute
 with root authority and have certain environment variables are set. This is
 so Juju commands and tools work correctly.  The debug-hooks command puts
 you into a "hook context" when you run  'juju resolved --retry unit/#'

 As I wrote all hooks are executed with these environment variables
 set.  If you are running the install script manually outside of a hook
 context these environment variables would not be 

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: Where is the Juju-gui heading ?

[Matthew Williams]

Hi Stein,

The friday session that Jose mentioned is this one:

http://summit.ubuntu.com/uos-1411/meeting/22387/whats-new-and-upcoming-in-the-work-of-juju-ui-engineering/

Thanks

Matty

On Wed, Nov 12, 2014 at 4:58 PM, Richard Harding rick.hard...@canonical.com
 wrote:

 On Wed, 12 Nov 2014, Stein Myrseth wrote:

  In earlier versions of the Juju-gui it was easy and simple to deploy a
  charm, by just dragging and dropping it into the canvas and hit commit.
 
  With the latest versions the same process it is no more intuitive how to
  deploy anymore. I hit “confirm” and “commit” and nothing happens. I have
  create a machine first, or auto place, or add the constraints or as part
  of the unit configuration, or as part of the machine configuration to
  create a machine and assign the unit etc. And the approach is different
  if I do it from the CLI and UI.
 
   To me this set the focus on two things. There will be two very distinct
   different user groups using Juju with different requirements.
 
 
  1) A charm designer/developers want to expose options for configuration
 
  2) A charm consumer, want to add a “service” to his or her deployment and
  is interested in a “serious relationships” :-)
 
   The first category has all the data, info and knows all requirements
   needed for the charm regarding constraints etc.
 
 
  The constraints are a part of my frustrations here. Today constraints are
  detached from the charm, which to me does not make sense regarding the
  two different target user groups. It’s detached in the UI on creation,
  but can be assigned from the CLI, and also copied as a constraint on
  export.
 
   As a charm developer I would very much like to see the support of adding
   the constraints like RAM, cores etc. as part of the charm config itself.
   This could be added to either the config.yaml or in a separate
   constraints.yaml file as an option.
 
 
   In this way as a charm developer I have an option to enforce the
   constraints on deployment, either using the CLI or the UI. It could be
   easy to check on deployment (as done when deploying bundles) if there is
   available machine resource matching the constraints or if the user would
   like a new machine matching the constraints to be created automatically.
   The deployment part has become to complex, and involved to many steps
   for the charm consumer. For the consumer the machines, assigned units,
   where etc. are completely secondary. The consumer is looking for
   storage, db proxy service relation without the need to learn how Mongodb
   works. Thats’s my focus.
 
 
   So as
 
 
  1) As a charm developer I need a way to make the constraints of my charms
  consistent across the different way of deploying.
 
  2) As a charm consumer I don’t care about machines, only services and the
  relationships provided and deploying should be simple.
 
 
  What is the future plans and directions for the the UI, define
  constraints and the easy of deployments ?


 Thanks for the feedback Stein. As was mentioned your concern with charm
 constraints is valid and something we've got on the list. We hit it all the
 time as things like Jenkins (go go java) don't like to run on the default
 small machines Juju uses out of the box. Having the charm author, who knows
 more than anyone what you need to operate, defined that in the
 charm level makes a lot of sense.

 As to the ease of getting something deployed, I think there's a different
 here. The GUI with machine view and the deployment bar is an attempt to
 help realize that people are not just going out and deploying a single
 thing. They're building a set of services that provide a complete solution
 for some infrastructure need. To help with that, and make it easier to do
 that work in total, we hold off on just 'hit deploy' so that the user can
 freely build out everything they want, build relations, set config, and
 really basically construct a custom bundle, before the tell Juju to go do
 anything.

 You don't mention the particular use case for the immediate deploy option.
 We have the ability to do that and perhaps what we want is a bit of both
 worlds.

 https://demo.jujucharms.com/?deploy-target=precise/mysql

 Is your use case primarily around using the GUi to manage your environment?
 Is it usually a speedy demo situation? If we gave you the option in the
 GUI config (you can get access to that via the ? key to set some config
 options) so that immediate deployment was a default behaviour for the demo
 would that help?

 I'd love to hear some more details on how you're using the GUI and when the
 extra deployment summary steps cause you pain and see if there's a good way
 to address them.

 Thanks again for the great feedback.


 --

 Rick Harding

 Juju UI Engineering
 https://launchpad.net/~rharding
 @mitechie

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

-- 
Juju mailing list

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

Re: Collection of Bundles?

[Matthew Williams]

Thanks Jorge, this is exactly what I was after

matty


On Thu, Jun 5, 2014 at 5:17 PM, Jorge O. Castro jo...@ubuntu.com wrote:

 On Thu, Jun 5, 2014 at 6:00 AM, Matthew Williams
 matthew.willi...@canonical.com wrote:
  I'm sure this has been discussed before - but I can't remember what the
  outcome was.

 James is correct, bundles are published in the same store as charms,
 the procedure is a bit different:
 https://juju.ubuntu.com/docs/charms-bundles.html

 Protip: You can use bundle:foo in jujucharms.com to search only for
 bundles.

 This is probably what you want though:
 https://code.launchpad.net/charms/bundles

 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

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

Collection of Bundles?

[Matthew Williams]

Hi Folks,

I'm sure this has been discussed before - but I can't remember what the
outcome was.

It would be nice to have some single place (or a list of places) to publish
bundles to - so if I wanted a bundle to deploy hadoop or openstack or
my-awesome-blog-engine I could find an existing bundle without having to
rely on a google search and hoping what it gives me works. Does anything
like this exist - and if not, should it?

Thanks

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

Re: Juju on Reddit

[Matthew Williams]

Thanks for the help folks,

This subreddit did belong to someone else but had only two posts from ages
ago - so was counted as being abandoned, I had to make a request to take it
over. I think we have 60 days to demonstrate that we're using it or it will
get reverted back to the original owner, so if we can try to post relevant
things to it at least every once in a while we'll be ok


On Wed, May 21, 2014 at 4:31 PM, Wayne Witzel wayne.wit...@canonical.comwrote:

 I'm wwitzel3 on reddit, we probably have plenty of moderators, but feel
 free to add me, I'll help out when I can.

 Thanks.


 On Tue, May 20, 2014 at 11:25 AM, Matthew Williams 
 matthew.willi...@canonical.com wrote:

  Hi Folks,

 We now have a subreddit for posting topics about juju:

 http://www.reddit.com/r/juju

 I'm looking for volunteers who would like to help with being moderators.

 Feel free to start posting links

 Thanks

 Matty

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




 --
 Wayne Witzel III
 wayne.wit...@canonical.com

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

Juju on Reddit

[Matthew Williams]

Hi Folks,

We now have a subreddit for posting topics about juju:

http://www.reddit.com/r/juju

I'm looking for volunteers who would like to help with being moderators.

Feel free to start posting links

Thanks

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

Re: Juju on Reddit

[Matthew Williams]

Thanks Joey,

I've added you - if you can work out how to add the flair be my guest

Cheers

Matty


On Tue, May 20, 2014 at 6:01 PM, Joey STANFORD j...@canonical.com wrote:

 On Tue, May 20, 2014 at 04:25:47PM +0100, Matthew Williams wrote:

 We now have a subreddit for posting topics about juju:

 http://www.reddit.com/r/juju

 I'm looking for volunteers who would like to help with being moderators.


 If you get no helpers, I'll signup.

 http://www.reddit.com/user/Rinchen/

 You should do what they did in /r/Ubuntu and add Canonical and Ubuntu
 flairs.

 Joey

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

Re: Manual provisioning - feedback wanted

[Matthew Williams]

Sounds like a cool feature. I tried bootstrapping in aws then adding a
machine supplied by digital ocean. I got an invalid domain error. Any idea
what I was doing wrong?

juju add-machine -v ssh:root@162.243.10.110
2013-09-15 20:06:07 INFO juju.provider.ec2 ec2.go:187 opening environment
amazon
2013-09-15 20:06:12 INFO juju.state open.go:68 opening state; mongo
addresses: [ec2-54-221-71-210.co
mpute-1.amazonaws.com:37017]; entity 
2013-09-15 20:06:15 INFO juju.state open.go:106 connection established
2013-09-15 20:06:18 INFO juju.provider.ec2 ec2.go:187 opening environment
amazon
2013-09-15 20:06:18 ERROR juju supercommand.go:282 command failed: lookup
162.243.10.110: invalid dom
ain name
error: lookup 162.243.10.110: invalid domain name

Matt



On Tue, Sep 10, 2013 at 10:56 AM, Andreas Hasenack andr...@canonical.comwrote:

 On Tue, Sep 10, 2013 at 10:17 AM, Andrew Wilkins 
 andrew.wilk...@canonical.com wrote:

 On Tue, Sep 10, 2013 at 4:18 PM, Andreas Hasenack 
 andr...@canonical.comwrote:

 The 10.0.3.53 machine is a new container I brought up manually with
 lxc-create and lxc-start. lxc-list above shows all containers, and it was
 the only one running.

 Right now I have this output for that ls command:
 # ls /etc/init/juju*
 /etc/init/juju-agent-andreas-local.conf
  /etc/init/juju-db-andreas-local.conf


 As discussed on IRC: the command will be run in the target (the
 container), not the local host.


  juju lxc is bootstrapped, but no units are running, and lxc-list shows
 my both containers stopped.


 I'm creating a new container on my laptop now, using your configuration.
 I'll let you know what I find.


 It's because of this ssh warning:
 $ ssh 10.0.3.230 ls /etc/init/ | grep juju.*\\.conf || exit 0
 Warning: Permanently added '10.0.3.230' (ECDSA) to the list of known hosts.
 $

 The code grabs both stderr and stdout and checks for len  0:
 out, err := cmd.CombinedOutput()
 (...)
 return len(strings.TrimSpace(string(out)))  0, nil




 Cheers,
 Andrew



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


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