Re: LXD certificate expiry issue

[Horacio Duran]

Is there a but for this in lxd? I believe this is quite a papercut for most
users of lxd in local machines.

On Mon, Feb 13, 2017 at 4:48 AM, Menno Smits 
wrote:

> Today Juju bootstraps started failing for me with the following error:
>
> cmd supercommand.go:458 new environ: creating LXD client: Get
> https://10.0.8.1:8443/1.0: x509: certificate has expired or is not yet
> valid
>
> It took me a while to figure out what was happening but it turned out that
> the LXD's server certificate had expired over the weekend (confirmed by
> inspecting the certificate file with openssl). If you delete
> /var/lib/lxd/server.{crt,key} and restart lxd it'll generate a new
> certificate and key.
>
> I noticed that the newly generated certificate lasts for 10 years whereas
> the last one was only valid for 1 year. I guess I started using LXD on this
> machine 1 year ago.
>
> I hope this helps anyone else who runs into this.
>
> - Menno
>
> --
> 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: to symlink or not to symlink?

[Horacio Duran]

Yo me the question is, does systems allow this practice? Or at least does
it discourage it? If not this sounds a lot like a Maas bug that could
potentially bite them with different services.
I was not the one to write that code but I know it's written that way to
avoid the need to call on systemd reload (the actual name escapes me) when
we do changes on the script also it is shared between systemd and upstart.

On Mon, Nov 21, 2016 at 10:22 PM Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:

> Hi
>
> There is a nice, yummy bug [1] with respect to change in Juju behavior,
> possibly related to changes when systemd support was added, where we
> started symlinking to /var/lib/juju/init & /etc.
>
> Simple solution seems to be stop symlinking \o/ Thoughts?
>
> Sincerely Yours,
>
> Anastasia
>
> [1]
>
> https://bugs.launchpad.net/bugs/1634390
>
>
>
> --
> 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: Github Reviews vs Reviewboard

[Horacio Duran]

Shouldn't we leave it for historic purposes?

On Monday, 24 October 2016, Menno Smits  wrote:

> The votes are in: Github 8, Reviewboard 5. It looks like we stick with
> Github Reviews.
>
> I'm going to email some people now about tearing down the Reviewboard
> instance.
>
> On 15 October 2016 at 06:57, Casey Marshall  > wrote:
>
>> +1, as I work on many other Github projects besides Juju and it's
>> familiar. It's not perfect by any means but I can work with it.
>>
>> I thought the ReviewBoard we had was pretty ugly and buggy, but it was
>> reasonably easy to use. Gerrit is cleaner and clearer to me -- though I
>> feel like Gerrit is also kind of rough on the uninitiated. Maybe if a newer
>> version of RB was sufficiently improved and it was charmed up well, its
>> operation would be more manageable, and it'd be OK?
>>
>> -Casey
>>
>> On Fri, Oct 14, 2016 at 12:34 PM, Andrew McDermott <
>> andrew.mcderm...@canonical.com
>> > wrote:
>>
>>>
>>> On 14 October 2016 at 16:26, Mick Gregg >> > wrote:
>>>
 I would probably chose gerrit over either, but that's not the question
 today.

>>>
>>> Oooh, yes to gerrit. +2
>>>
>>>
>>>
>>> --
>>> Andrew McDermott >> >
>>> Juju Core Sapphire team 
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> 
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> 
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju 2.0 and vmware

[Horacio Duran]

This is how mine looks

clouds:
  vsphere:
type: vsphere
auth-types: [userpass]
endpoint: 
regions:
  dc0: {}


On Mon, Oct 24, 2016 at 2:10 PM, Peter Petrakis <peter.petra...@cacheio.com>
wrote:

> On Mon, Oct 24, 2016 at 12:19 PM, Horacio Duran
> <horacio.du...@canonical.com> wrote:
> > Chance seems to be in the right path there.
> > In the example "dc0" is the name of our data center, to figure out yours
> you
> > can access the vsphere web client and in there go to:
> > Home->Vcenter inventory lists->Resources->Datacenters  (all this in the
> left
> > tree like menu)
> > And you will be presented with a list of your datacenters in the right
> pane
> > under the "Objects" tab, the "Name" column holds what you must put in
> place
> > of "dc0" .
> > Cheers
>
> Looks like I got the datacenter name correct by accident :)
>
> From the gui:
>
> vcenter.cacheio.com [10.2.0.8] -> Datacenter -> Cluster1 ->
> [cio-esx1.cacheio.com, cio-esx2-cacheio.com ]
>
> We renamed Datacenter -> dc0 just to see what would happen, same end
> result.
>
> We're using vsphere 6.0u2.
>
> root@juju-vmware:~# cat /root/.local/share/juju/clouds.yaml
> clouds:
>   myvscloud:
> type: vsphere
> auth-types: [userpass]
> endpoint: 10.2.0.8
> regions:
>   Datacenter:
> endpoint: 10.2.0.8
>
> We're on ESXi 6 which I'm told provides HW version 11. The doc says
> the min is 8.
>
> Thanks.
>
> Peter
>
> >
> > On Mon, Oct 24, 2016 at 1:10 PM, Chance Ellis <chance_el...@yahoo.com>
> > wrote:
> >>
> >> Hi Peter,
> >>
> >> Is your vsphere data center actually named dc0?
> >>
> >> “15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
> >> datacenter 'dc0' not found”
> >>
> >>
> >> The page you referenced gave an example with a data center named dc0. I
> >> imagine yours is named something different?
> >>
> >>
> >>
> >> On 10/24/16, 12:06 PM, "Peter Petrakis" <juju-boun...@lists.ubuntu.com
> on
> >> behalf of peter.petra...@cacheio.com> wrote:
> >>
> >> Hi All,
> >>
> >> I have 16.10 running in a container and am testing this against our
> >> datacenter using the docs found here:
> >>
> >> https://jujucharms.com/docs/2.0/help-vmware
> >>
> >> Which advises the following config:
> >>
> >> root@juju-vmware:~# cat /root/.local/share/juju/clouds.yaml
> >> clouds:
> >>   myvscloud:
> >> type: vsphere
> >> auth-types: [userpass]
> >> endpoint: 10.2.0.8
> >> regions:
> >>   dc0:
> >> endpoint: 10.2.0.8
> >>
> >>
> >>
> >> This does not work.
> >>
> >> root@juju-vmware:~# juju bootstrap vsphere myvscloud --debug
> >>
> >> 15:38:47 INFO  juju.cmd supercommand.go:63 running juju [2.0-rc3 gc
> >> go1.6.3]
> >> 15:38:47 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
> >> "bootstrap", "vsphere", "myvscloud", "--debug"}
> >> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:537 provider
> attrs:
> >> map[]
> >> 15:38:47 INFO  cmd cmd.go:141 Adding contents of
> >> "/root/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
> >> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:595 preparing
> >> controller with config: map[authorized-keys:ssh-rsa
> >>
> >> B3NzaC1yc2EDAQABAAABAQCxDagqFodKywSsG7itNj/
> J3JYYGdOuXA5QDiJ0FJuiLLag/W7cir+e3ofk2ly5J6U+um5edi7fI9sR1bEzCAFWZKs0mRI+
> 6DcjkzxBPC0LsjmDx8rhk4b5l9er+c93UgyTYiBpsopYzekzQI2b+
> KSLI9t1SUSMUmS1sW7sTaw3KcSFfZYWb7jeQnXLK2EOV2NcTlcmlTEohKZZU
> YVSP5uth451mqViTB8BCbsYCtGtIeqvhkmdGVnj3qErn4rM0zcyeNHoTKv8r
> cERaNcEQUCqM5sk4z+d62NONuNUMtA/8RuzzBOMP3E89h8iy59zVP0LRPtadd
> l6K8fN4wB9wSgv
> >> juju-client-key
> >>  type:vsphere name:controller
> >> uuid:e2f16e4a-fb8d-4a25-8686-81dc190894b9]
> >> 15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
> >> datacenter 'dc0' not found
> >> 15:38:47 DEBUG cmd supercommand.go:459 (error details:
> >> [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:662: }
> >> {github.com/juju/juju/environs/bootstrap/prepare.go:99: }
&g

Re: juju 2.0 and vmware

[Horacio Duran]

Beware, current release has a bug that might affect you where many
connections are open and never closed to the vcenter, it is being worked as
we speak and will most likely be included in the next release, sorry for
that.

On Mon, Oct 24, 2016 at 1:19 PM, Horacio Duran <horacio.du...@canonical.com>
wrote:

> Chance seems to be in the right path there.
> In the example "dc0" is the name of our data center, to figure out yours
> you can access the vsphere web client and in there go to:
> Home->Vcenter inventory lists->Resources->Datacenters  (all this in the
> left tree like menu)
> And you will be presented with a list of your datacenters in the right
> pane under the "Objects" tab, the "Name" column holds what you must put in
> place of "dc0" .
> Cheers
>
>
> On Mon, Oct 24, 2016 at 1:10 PM, Chance Ellis <chance_el...@yahoo.com>
> wrote:
>
>> Hi Peter,
>>
>> Is your vsphere data center actually named dc0?
>>
>> “15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
>> datacenter 'dc0' not found”
>>
>>
>> The page you referenced gave an example with a data center named dc0. I
>> imagine yours is named something different?
>>
>>
>>
>> On 10/24/16, 12:06 PM, "Peter Petrakis" <juju-boun...@lists.ubuntu.com
>> on behalf of peter.petra...@cacheio.com> wrote:
>>
>> Hi All,
>>
>> I have 16.10 running in a container and am testing this against our
>> datacenter using the docs found here:
>>
>> https://jujucharms.com/docs/2.0/help-vmware
>>
>> Which advises the following config:
>>
>> root@juju-vmware:~# cat /root/.local/share/juju/clouds.yaml
>> clouds:
>>   myvscloud:
>> type: vsphere
>> auth-types: [userpass]
>> endpoint: 10.2.0.8
>> regions:
>>   dc0:
>> endpoint: 10.2.0.8
>>
>>
>>
>> This does not work.
>>
>> root@juju-vmware:~# juju bootstrap vsphere myvscloud --debug
>>
>> 15:38:47 INFO  juju.cmd supercommand.go:63 running juju [2.0-rc3 gc
>> go1.6.3]
>> 15:38:47 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
>> "bootstrap", "vsphere", "myvscloud", "--debug"}
>> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:537 provider
>> attrs: map[]
>> 15:38:47 INFO  cmd cmd.go:141 Adding contents of
>> "/root/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
>> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:595 preparing
>> controller with config: map[authorized-keys:ssh-rsa
>> B3NzaC1yc2EDAQABAAABAQCxDagqFodKywSsG7itNj/J3JYYGdOu
>> XA5QDiJ0FJuiLLag/W7cir+e3ofk2ly5J6U+um5edi7fI9sR1bEzC
>> AFWZKs0mRI+6DcjkzxBPC0LsjmDx8rhk4b5l9er+c93UgyTYiBpsopYzekzQ
>> I2b+KSLI9t1SUSMUmS1sW7sTaw3KcSFfZYWb7jeQnXLK2EOV2NcTlcmlTEoh
>> KZZUYVSP5uth451mqViTB8BCbsYCtGtIeqvhkmdGVnj3qErn4rM0zcyeNHoT
>> Kv8rcERaNcEQUCqM5sk4z+d62NONuNUMtA/8RuzzBOMP3E89h8iy59zVP0LR
>> Ptaddl6K8fN4wB9wSgv
>> juju-client-key
>>  type:vsphere name:controller uuid:e2f16e4a-fb8d-4a25-8686-8
>> 1dc190894b9]
>> 15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
>> datacenter 'dc0' not found
>> 15:38:47 DEBUG cmd supercommand.go:459 (error details:
>> [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:662: }
>> {github.com/juju/juju/environs/bootstrap/prepare.go:99: }
>> {github.com/juju/juju/environs/bootstrap/prepare.go:160: }
>> {github.com/juju/juju/provider/vsphere/provider.go:32: }
>> {github.com/juju/juju/provider/vsphere/environ.go:47: failed to
>> create
>> new client} {github.com/juju/juju/provider/vsphere/client.go:61: }
>> {datacenter 'dc0' not found}])
>>
>> Now I look at the source and discover that "dc0" cannot be some
>> arbitrary string, it must be named "Datacenter".
>>
>> # ~/juju-src/juju-core-2.0~rc3/src/github.com/juju/govmomi/fin
>> d/finder.go
>> func (f *Finder) DatacenterList(ctx context.Context, path ...string)
>> ([]*object.Datacenter, error) {
>> es, err := f.find(ctx, f.rootFolder, false, path...)
>> if err != nil {
>> return nil, err
>> }
>>
>> var dcs []*object.Datacenter
>> for _, e := range es {
>> ref := e.Object.Reference()
>> if ref.Type 

Re: juju 2.0 and vmware

[Horacio Duran]

Chance seems to be in the right path there.
In the example "dc0" is the name of our data center, to figure out yours
you can access the vsphere web client and in there go to:
Home->Vcenter inventory lists->Resources->Datacenters  (all this in the
left tree like menu)
And you will be presented with a list of your datacenters in the right pane
under the "Objects" tab, the "Name" column holds what you must put in place
of "dc0" .
Cheers


On Mon, Oct 24, 2016 at 1:10 PM, Chance Ellis 
wrote:

> Hi Peter,
>
> Is your vsphere data center actually named dc0?
>
> “15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
> datacenter 'dc0' not found”
>
>
> The page you referenced gave an example with a data center named dc0. I
> imagine yours is named something different?
>
>
>
> On 10/24/16, 12:06 PM, "Peter Petrakis"  behalf of peter.petra...@cacheio.com> wrote:
>
> Hi All,
>
> I have 16.10 running in a container and am testing this against our
> datacenter using the docs found here:
>
> https://jujucharms.com/docs/2.0/help-vmware
>
> Which advises the following config:
>
> root@juju-vmware:~# cat /root/.local/share/juju/clouds.yaml
> clouds:
>   myvscloud:
> type: vsphere
> auth-types: [userpass]
> endpoint: 10.2.0.8
> regions:
>   dc0:
> endpoint: 10.2.0.8
>
>
>
> This does not work.
>
> root@juju-vmware:~# juju bootstrap vsphere myvscloud --debug
>
> 15:38:47 INFO  juju.cmd supercommand.go:63 running juju [2.0-rc3 gc
> go1.6.3]
> 15:38:47 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
> "bootstrap", "vsphere", "myvscloud", "--debug"}
> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:537 provider attrs:
> map[]
> 15:38:47 INFO  cmd cmd.go:141 Adding contents of
> "/root/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
> 15:38:47 DEBUG juju.cmd.juju.commands bootstrap.go:595 preparing
> controller with config: map[authorized-keys:ssh-rsa
> B3NzaC1yc2EDAQABAAABAQCxDagqFodKywSsG7itNj/
> J3JYYGdOuXA5QDiJ0FJuiLLag/W7cir+e3ofk2ly5J6U+um5edi7fI9sR1bEzCAFWZKs0mRI+
> 6DcjkzxBPC0LsjmDx8rhk4b5l9er+c93UgyTYiBpsopYzekzQI2b+
> KSLI9t1SUSMUmS1sW7sTaw3KcSFfZYWb7jeQnXLK2EOV2NcTlcmlTEohKZZU
> YVSP5uth451mqViTB8BCbsYCtGtIeqvhkmdGVnj3qErn4rM0zcyeNHoTKv8r
> cERaNcEQUCqM5sk4z+d62NONuNUMtA/8RuzzBOMP3E89h8iy59zVP0LRPtadd
> l6K8fN4wB9wSgv
> juju-client-key
>  type:vsphere name:controller uuid:e2f16e4a-fb8d-4a25-8686-
> 81dc190894b9]
> 15:38:47 ERROR cmd supercommand.go:458 failed to create new client:
> datacenter 'dc0' not found
> 15:38:47 DEBUG cmd supercommand.go:459 (error details:
> [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:662: }
> {github.com/juju/juju/environs/bootstrap/prepare.go:99: }
> {github.com/juju/juju/environs/bootstrap/prepare.go:160: }
> {github.com/juju/juju/provider/vsphere/provider.go:32: }
> {github.com/juju/juju/provider/vsphere/environ.go:47: failed to create
> new client} {github.com/juju/juju/provider/vsphere/client.go:61: }
> {datacenter 'dc0' not found}])
>
> Now I look at the source and discover that "dc0" cannot be some
> arbitrary string, it must be named "Datacenter".
>
> # ~/juju-src/juju-core-2.0~rc3/src/github.com/juju/govmomi/
> find/finder.go
> func (f *Finder) DatacenterList(ctx context.Context, path ...string)
> ([]*object.Datacenter, error) {
> es, err := f.find(ctx, f.rootFolder, false, path...)
> if err != nil {
> return nil, err
> }
>
> var dcs []*object.Datacenter
> for _, e := range es {
> ref := e.Object.Reference()
> if ref.Type == "Datacenter" {
> dcs = append(dcs,
> object.NewDatacenter(f.client, ref))
> }
> }
>
> return dcs, nil
> }
>
> Which gets me a whole lot further but not quite to the finish line.
>
> root@juju-vmware:~# juju bootstrap  vsphere myvscloud --debug
> 16:04:15 INFO  juju.cmd supercommand.go:63 running juju [2.0-rc3 gc
> go1.6.3]
> 16:04:15 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
> "bootstrap", "vsphere", "myvscloud", "--debug"}
> 16:04:15 DEBUG juju.cmd.juju.commands bootstrap.go:537 provider attrs:
> map[]
> 16:04:15 INFO  cmd cmd.go:141 Adding contents of
> "/root/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
> 16:04:15 DEBUG juju.cmd.juju.commands bootstrap.go:595 preparing
> controller with config: map[name:controller
> uuid:cde9a49f-4a06-4d96-8197-87ddad561abf authorized-keys:ssh-rsa
> B3NzaC1yc2EDAQABAAABAQCxDagqFodKywSsG7itNj/
> J3JYYGdOuXA5QDiJ0FJuiLLag/W7cir+e3ofk2ly5J6U+um5edi7fI9sR1bEzCAFWZKs0mRI+
> 6DcjkzxBPC0LsjmDx8rhk4b5l9er+c93UgyTYiBpsopYzekzQI2b+
> 

Re: Github Reviews vs Reviewboard

[Horacio Duran]

+1 to Github, I prefer the papercuts of githubs to the swordcuts from
reviewboard.

On Fri, Oct 14, 2016 at 12:09 PM, Dimiter Naydenov <
dimiter.nayde...@canonical.com> wrote:

> +1, Nate said what I was thinking :)
>
> On 10/14/2016 05:34 PM, Nate Finch wrote:
> > +1
> >
> > Keeping the PR and reviews together really makes it easier for me to
> > keep track of what's going on with a PR.  It's also really nice not
> > having to context switch out of github for every single PR.
> >
> > Reviewboard and related infrastructure breaks like once couple weeks,
> > and I'm not convinced it'll get better, since we've been using it for
> > quite some time now.
> >
> > I have missed exactly zero of the features of reviewboard since using
> > github, and haven't really cared about the drawbacks of github.
> >
> > One point - you *can* minimize comments in the files view - there's a
> > checkbox per file that will hide the comments in that file.
> >
> > On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > > wrote:
> >
> > On 14 October 2016 at 12:45, Adam Collard
> > >
> wrote:
> > > Not sure I get a vote, but -1
> > >
> > > You're running an old version of ReviewBoard (2.0.12 released in
> > January
> > > 2015) and many of the issues I think you've been hitting are fixed
> > in later
> > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> > development and
> > > brings a chunk of new UI improvements.
> > >
> > > Release notes for 2.5
> > >
> > > 3.0 demo site
> >
> > I'm still not convinced.
> >
> > Even 3.0 still deletes draft comments without so much as a
> by-your-leave
> > when you double-click somewhere else in the text. And because it
> > doesn't use
> > real text entry boxes, the Lazarus plugin, my usual saviour in such
> > cases,
> > doesn't work. I've lost far too much time to this in the past.
> >
> > Replying to a comment still involves a page reload and associated
> > lost context.
> >
> > I can't see anything in the 2.5 release notes about fixing behaviour
> > on file
> > move/rename, though I may well have missed it.
> >
> > And not being able to deal with really large PRs is a definite issue
> > too (not
> > that github is better there).
> >
> >   cheers,
> > rog.
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com 
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
>
>
> --
> Dimiter Naydenov 
> Juju Core Sapphire team 
>
>
> --
> 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: Reviews on Github

[Horacio Duran]

I disagree, once the discussion is over and the merge is ready, an
amend/squash is in order to avoid useless tree nodes.

On Wed, Sep 21, 2016 at 8:41 PM, Reed O'Brien 
wrote:

> Two things I've noticed today while doing OCR duties are:
> 1. There's no way to tell if a PR has a review when looking at the list of
> open PRs. I may be missing something or it may be an oversight on the part
> of GH and will likely be remedied soon. When there are comments it shows
> little comment clouds and a count, but not if there's only a review nothing
> shows there for me.
> 2. When someone amends a commit and force pushes, the review remains but
> isn't attached to a commit any longer. You can see that there was an update
> because the commit appears later in the timeline than the review on the PR
> details view. Personally, I think that once you make a PR and involve
> someone else we shouldn't rewrite history anymore.
>
>
> On Wed, Sep 21, 2016 at 4:37 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Wed, Sep 21, 2016 at 5:53 AM Menno Smits 
>> wrote:
>>
>>> Some of us probably got a little excited (me included). There should be
>>> discussion and a clear announcement before we make a signigicant change to
>>> our process. The tech board meeting is today/tonight so we'll discuss it
>>> there as per Rick's email. Please contribute to this thread if you haven't
>>> already and have strong opinions either way on the topic.
>>>
>>
>> We discussed Github reviews vs. Reviewboard at the tech board meeting
>> today, and we all agreed that we should go ahead with a trial for 2 weeks.
>>
>> There are pros and cons to each; neither is perfect. You can find the
>> main points of discussion in the tech board agenda.
>>
>> Please give it a shot and provide your criticisms so we decide on the
>> best path forward at the end of the trial.
>>
>> Cheers,
>> Andrew
>>
>> Interestingly our Github/RB integration seems to have broken a little
>>> since Github made these changes. The links to Reviewboard on pull requests
>>> aren't getting inserted any more. If we decide to stay with RB
>>>
>>> On 21 September 2016 at 05:54, Rick Harding 
>>> wrote:
>>>
 I spoke with Alexis today about this and it's on her list to check with
 her folks on this. The tech board has been tasked with he decision, so
 please feel free to shoot a copy of your opinions their way. As you say, on
 the one hand it's a big impact on the team, but it's also a standard
 developer practice that not everyone will agree with so I'm sure the tech
 board is a good solution to limiting the amount of bike-shedding and to
 have some multi-mind consensus.

 On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
 katherine.cox-bu...@canonical.com> wrote:

> Seems like a good thing to do would be to ensure the tech board
> doesn't have any objections and then put it to a vote since it's more a
> property of the team and not the codebase.
>
> I just want some consistency until a decision is made. E.g. "we will
> be trying out GitHub reviews for the next two weeks; all reviews should be
> done on there".
>
> --
> Katherine
>
> Nate Finch  writes:
>
> > Can we try reviews on github for a couple weeks? Seems like we'll
> > never know if it's sufficient if we don't try it. And there's no
> setup
> > cost, which is nice.
> >
> > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
> >  wrote:
> >
> > I see quite a few PRs that are being reviewed in GitHub and not
> > ReviewBoard. I really don't care where we do them, but can we
> > please pick a direction and move forward? And until then, can we
> > stick to our previous decision and use RB? With people using both
> > it's much more difficult to tell what's been reviewed and what
> > hasn't.
> >
> > --
> > Katherine
> >
> > Nate Finch  writes:
> >
> > > In case you missed it, Github rolled out a new review process.
> > It
> > > basically works just like reviewboard does, where you start a
> > review,
> > > batch up comments, then post the review as a whole, so you
> don't
> > just
> > > write a bunch of disconnected comments (and get one email per
> > review,
> > > not per comment). The only features reviewboard has is the edge
> > case
> > > stuff that we rarely use: like using rbt to post a review from
> a
> > > random diff that is not connected directly to a github PR. I
> > think
> > > that is easy enough to give up in order to get the benefit of
> > not
> > > needing an entirely separate system to handle 

Re: Reviews on Github

[Horacio Duran]

Also +1 for that source not being review board

On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien 
wrote:

> Also +1 for a single source of truth.
>
> On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding 
> wrote:
>
>> /me is always +1 on reducing the number of things we have to maintain and
>> keeping things simpler.
>>
>> On Wed, Sep 14, 2016 at 4:04 PM Nate Finch 
>> wrote:
>>
>>> In case you missed it, Github rolled out a new review process.  It
>>> basically works just like reviewboard does, where you start a review, batch
>>> up comments, then post the review as a whole, so you don't just write a
>>> bunch of disconnected comments (and get one email per review, not per
>>> comment).  The only features reviewboard has is the edge case stuff that we
>>> rarely use:  like using rbt to post a review from a random diff that is not
>>> connected directly to a github PR. I think that is easy enough to give up
>>> in order to get the benefit of not needing an entirely separate system to
>>> handle reviews.
>>>
>>> I made a little test review on one PR here, and the UX was almost
>>> exactly like working in reviewboard: https://github.co
>>> m/juju/juju/pull/6234
>>>
>>> There may be important edge cases I'm missing, but I think it's worth
>>> looking into.
>>>
>>> -Nate
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
>
> --
> Reed O'Brien
> ✉ reed.obr...@canonical.com
> ✆ 415-562-6797
>
>
> --
> 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: about to land a breaking change

[Horacio Duran]

This just landed fyi.

On Tue, Jun 21, 2016 at 8:36 AM, Horacio Duran <horacio.du...@canonical.com>
wrote:

> I am about to land a change in the way we persist user permissions in juju
> core master, this will not change API but existing models/controllers will
> stop working so please be aware of this before pulling the latest version
> of the code and trying to upgrade to it.
> Cheers and sorry for the inconvenience.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

about to land a breaking change

[Horacio Duran]

I am about to land a change in the way we persist user permissions in juju
core master, this will not change API but existing models/controllers will
stop working so please be aware of this before pulling the latest version
of the code and trying to upgrade to it.
Cheers and sorry for the inconvenience.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

about to land a breaking change

[Horacio Duran]

I am about to land a change in the way we persist user permissions, this
will not change API but existing models/controllers will stop working so
please be aware of this before pulling the latest version of the code.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Automatic commit squashing

[Horacio Duran]

Much like communism, it's still in practice at small territory

On Thursday, 16 June 2016, David Cheney <david.che...@canonical.com> wrote:

> I thought feature branches, like communism, sounded good but had
> failed in practice.
>
> On Thu, Jun 16, 2016 at 7:06 PM, Horacio Duran
> <horacio.du...@canonical.com <javascript:;>> wrote:
> > On second thought, this might be a problem for feature branches but we
> can
> > device a way to tell the bot that something is a fb
> >
> >
> > On Thursday, 16 June 2016, Horacio Duran <horacio.du...@canonical.com
> <javascript:;>>
> > wrote:
> >>
> >> +1 on Dave's suggestion
> >>
> >> On Thursday, 16 June 2016, David Cheney <david.che...@canonical.com
> <javascript:;>>
> >> wrote:
> >>>
> >>> Counter suggestion: the bot refuses to accept PR's that contain more
> >>> than one commit, then it's up to the submitter to prepare it in any
> >>> way that they feel appropriate.
> >>>
> >>> On Thu, Jun 16, 2016 at 6:44 PM, roger peppe <
> roger.pe...@canonical.com <javascript:;>>
> >>> wrote:
> >>> > Squashed commits are nice, but there's something worth watching
> >>> > out for: currently the merge commit is committed with the text
> >>> > that's in the github PR, but when a squashed commit is made, this
> >>> > text is ignored and only the text in the actual proposed commit ends
> up
> >>> > in the history. This surprised me (I often edit the PR description
> >>> > as the review continues) so worth being aware of, I think.
> >>> >
> >>> >   cheers,
> >>> > rog.
> >>> >
> >>> > On 16 June 2016 at 02:12, Menno Smits <menno.sm...@canonical.com
> <javascript:;>>
> >>> > wrote:
> >>> >> Hi everyone,
> >>> >>
> >>> >> Following on from the recent thread about commit squashing and
> commit
> >>> >> message quality, the idea of automatically squashing commit at merge
> >>> >> time
> >>> >> has been raised. The idea is that the merge bot would automatically
> >>> >> squash
> >>> >> commits for a pull request into a single commit, using the PR
> >>> >> description as
> >>> >> the commit message.
> >>> >>
> >>> >> With this in place, developers can commit locally using any approach
> >>> >> they
> >>> >> prefer. The smaller commits they make as they work won't be part of
> >>> >> the
> >>> >> history the team interacts with in master.
> >>> >>
> >>> >> When using autosquashing the quality of pull request descriptions
> >>> >> should get
> >>> >> even more scrutiny during reviews. The quality of PR descriptions is
> >>> >> already
> >>> >> important as they are used for merge commits but with autosquashing
> in
> >>> >> place
> >>> >> they will be the *only* commit message.
> >>> >>
> >>> >> Autosquashing can be achieved technically by either having the merge
> >>> >> bot do
> >>> >> the squashing itself, or by taking advantage of Github's feature to
> do
> >>> >> this
> >>> >> (currently in preview mode):
> >>> >>
> >>> >> https://developer.github.com/changes/2016-04-01-squash-api-preview/
> >>> >>
> >>> >> We need to ensure that the squashed commits are attributed to the
> >>> >> correct
> >>> >> author (i.e. not jujubot). I'm not sure what we do with pull
> requests
> >>> >> which
> >>> >> contain work from multiple authors. There doesn't seem to be an
> >>> >> established
> >>> >> approach for this.
> >>> >>
> >>> >> Thoughts?
> >>> >>
> >>> >> - Menno
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Juju-dev mailing list
> >>> >> Juju-dev@lists.ubuntu.com <javascript:;>
> >>> >> Modify settings or unsubscribe at:
> >>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>> >>
> >>> >
> >>> > --
> >>> > Juju-dev mailing list
> >>> > Juju-dev@lists.ubuntu.com <javascript:;>
> >>> > Modify settings or unsubscribe at:
> >>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>
> >>> --
> >>> Juju-dev mailing list
> >>> Juju-dev@lists.ubuntu.com <javascript:;>
> >>> 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: Automatic commit squashing

[Horacio Duran]

On second thought, this might be a problem for feature branches but we can
device a way to tell the bot that something is a fb

On Thursday, 16 June 2016, Horacio Duran <horacio.du...@canonical.com>
wrote:

> +1 on Dave's suggestion
>
> On Thursday, 16 June 2016, David Cheney <david.che...@canonical.com
> <javascript:_e(%7B%7D,'cvml','david.che...@canonical.com');>> wrote:
>
>> Counter suggestion: the bot refuses to accept PR's that contain more
>> than one commit, then it's up to the submitter to prepare it in any
>> way that they feel appropriate.
>>
>> On Thu, Jun 16, 2016 at 6:44 PM, roger peppe <roger.pe...@canonical.com>
>> wrote:
>> > Squashed commits are nice, but there's something worth watching
>> > out for: currently the merge commit is committed with the text
>> > that's in the github PR, but when a squashed commit is made, this
>> > text is ignored and only the text in the actual proposed commit ends up
>> > in the history. This surprised me (I often edit the PR description
>> > as the review continues) so worth being aware of, I think.
>> >
>> >   cheers,
>> > rog.
>> >
>> > On 16 June 2016 at 02:12, Menno Smits <menno.sm...@canonical.com>
>> wrote:
>> >> Hi everyone,
>> >>
>> >> Following on from the recent thread about commit squashing and commit
>> >> message quality, the idea of automatically squashing commit at merge
>> time
>> >> has been raised. The idea is that the merge bot would automatically
>> squash
>> >> commits for a pull request into a single commit, using the PR
>> description as
>> >> the commit message.
>> >>
>> >> With this in place, developers can commit locally using any approach
>> they
>> >> prefer. The smaller commits they make as they work won't be part of the
>> >> history the team interacts with in master.
>> >>
>> >> When using autosquashing the quality of pull request descriptions
>> should get
>> >> even more scrutiny during reviews. The quality of PR descriptions is
>> already
>> >> important as they are used for merge commits but with autosquashing in
>> place
>> >> they will be the *only* commit message.
>> >>
>> >> Autosquashing can be achieved technically by either having the merge
>> bot do
>> >> the squashing itself, or by taking advantage of Github's feature to do
>> this
>> >> (currently in preview mode):
>> >>
>> >> https://developer.github.com/changes/2016-04-01-squash-api-preview/
>> >>
>> >> We need to ensure that the squashed commits are attributed to the
>> correct
>> >> author (i.e. not jujubot). I'm not sure what we do with pull requests
>> which
>> >> contain work from multiple authors. There doesn't seem to be an
>> established
>> >> approach for this.
>> >>
>> >> Thoughts?
>> >>
>> >> - Menno
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 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: Automatic commit squashing

[Horacio Duran]

+1 on Dave's suggestion

On Thursday, 16 June 2016, David Cheney  wrote:

> Counter suggestion: the bot refuses to accept PR's that contain more
> than one commit, then it's up to the submitter to prepare it in any
> way that they feel appropriate.
>
> On Thu, Jun 16, 2016 at 6:44 PM, roger peppe  > wrote:
> > Squashed commits are nice, but there's something worth watching
> > out for: currently the merge commit is committed with the text
> > that's in the github PR, but when a squashed commit is made, this
> > text is ignored and only the text in the actual proposed commit ends up
> > in the history. This surprised me (I often edit the PR description
> > as the review continues) so worth being aware of, I think.
> >
> >   cheers,
> > rog.
> >
> > On 16 June 2016 at 02:12, Menno Smits  > wrote:
> >> Hi everyone,
> >>
> >> Following on from the recent thread about commit squashing and commit
> >> message quality, the idea of automatically squashing commit at merge
> time
> >> has been raised. The idea is that the merge bot would automatically
> squash
> >> commits for a pull request into a single commit, using the PR
> description as
> >> the commit message.
> >>
> >> With this in place, developers can commit locally using any approach
> they
> >> prefer. The smaller commits they make as they work won't be part of the
> >> history the team interacts with in master.
> >>
> >> When using autosquashing the quality of pull request descriptions
> should get
> >> even more scrutiny during reviews. The quality of PR descriptions is
> already
> >> important as they are used for merge commits but with autosquashing in
> place
> >> they will be the *only* commit message.
> >>
> >> Autosquashing can be achieved technically by either having the merge
> bot do
> >> the squashing itself, or by taking advantage of Github's feature to do
> this
> >> (currently in preview mode):
> >>
> >> https://developer.github.com/changes/2016-04-01-squash-api-preview/
> >>
> >> We need to ensure that the squashed commits are attributed to the
> correct
> >> author (i.e. not jujubot). I'm not sure what we do with pull requests
> which
> >> contain work from multiple authors. There doesn't seem to be an
> established
> >> approach for this.
> >>
> >> Thoughts?
> >>
> >> - Menno
> >>
> >>
> >>
> >>
> >> --
> >> 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: The CI build time continue to rise alarmingly

[Horacio Duran]

So as a follow up of this, the fault is in
"7fb39bdfbd8a7a668c7db53923836ac42cd640ec" that removed --nojournal from "
github.com/juju/testing" mgo.go file, which is good for mongo 3.2 but kills
2.4, this needs to check what version of mongo is running and use flags
accordingly, its EOD for me but if no one tackled this by tomorrow ill fix
it (hint, our code has this in main in the mongo package iirc)

On Wed, Jun 8, 2016 at 1:20 PM, Christian Muirhead <
christian.muirh...@canonical.com> wrote:

> Hi Torsten -
>
> That fix shouldn't have increased build times unless we also changed the
> test run to be against Mongo 3.2. If builds are still against 2.4 then the
> change will have made them slightly faster (because we only drop and
> recreate the database at the suite level).
>
> I don't think we've switched runs to be against 3.2 because there were
> other problems that were unrelated to the slow state tests - these two that
> I know about:
> https://bugs.launchpad.net/juju-core/+bug/1588784
> https://bugs.launchpad.net/juju-core/+bug/1573286
>
> Cheers,
> Christian
>
>
> On Wed, 8 Jun 2016, 16:06 Torsten Baumann, 
> wrote:
>
>> Hi David,
>>
>> Thanks for raising the inefficiency.
>>
>> From what I understand there was a change introduced in and around June
>> 1st for https://bugs.launchpad.net/juju-core/+bug/1573294 that may have
>> increased the time again. :-( As regrettable as this is we did review this
>> with the tech board and it was accepted as part of the fix.
>>
>>
>> I discussed with a few people and there is some time we can shave off on
>> the tarball assembly (2-4 minutes) if we spent a few days work there.
>>
>> I also believe we can save time if we ran the tests in LXC containers but
>> there may be some reliability issues there. we can always switch the jobs
>> to use lxc and see what happens?
>>
>> Other than that I am open to seeing who else on this list has ideas as to
>> what we can do to reduce the time? I would rather we go after the most
>> important ones first if we can identify them.
>>
>> thanks everyone,
>>
>> Torsten
>>
>>
>>
>> -- Forwarded message --
>> From: David Cheney 
>> Date: Thu, Jun 2, 2016 at 9:49 PM
>> Subject: The CI build time continue to rise alarmingly
>> To: "juju-dev@lists.ubuntu.com" 
>>
>>
>> CI build times are now an average of 36 minutes. That means in a
>> typical 8 hour work day, assuming doing nothing other than landing
>> branches, less than 16 commits can be landed.
>>
>> While bugs can be worked on and reviewed in parallel, landing is a
>> sequential action that blocks everyone, and given the landing bot is
>> batting less than 0.500, this limits the practical number of changes
>> that can be landed in a day, a sprint, a iteration, or a development
>> cycle.
>>
>> I cannot make it any clearer than this, the speed of CI limits the
>> velocity of this team.
>>
>> 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
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[Horacio Duran]

Uh, ill take a look at that, I am the author of said test

On Fri, May 20, 2016 at 6:50 AM, roger peppe 
wrote:

> The state tests "only" take 10m26s for me.
>
> I built a thing to analyse gocheck output
> https://play.golang.org/p/veBCtrmmPR
> and used it on the state test output.
>
> total suites 94
> total test time 10m25.752s
> total suite time 10m26.033s
> total setup test 3m4.727s
> total teardown test 14.277s
> total setup suite 89ms
> total teardown suite 17.496s
> total fixture overhead 3m36.589s
> longest test 1m39.423s (
> StatusHistorySuite.TestPruneStatusHistoryBySize) setup 135ms teardown
> 4ms
> overall time 10m26.078s
>
> Surely TestPruneStatusHistoryBySize doesn't *really* need to take all that
> time?
>
> If you want to play around with the code, it expects as input the output
> from timestamp (go get github.com/rogpeppe/misc/cmd/timestamp).
>
> e.g.
>
> go test -check.vv 2>&1 | timestamp > statetest.out
> parsegocheck < statetest.out
>
>
>
> On 17 May 2016 at 03:52, David Cheney  wrote:
> > Testing this package takes 16 minutes on my machine*; it sure didn't
> > use to take this long.
> >
> > What happened ?
> >
> > * yes, you have to raise the _10 minute_ timeout to make this test run.
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/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: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[Horacio Duran]

For now we are trying to go around mongo issues that make the tests 100x
slower (yes one hundred) once this is fixed we should start using mongo 3.2
exclusively since 2.4 iirc is EOL or near. The issue lies in the new
storage engine, which we could skip if mmapv1 ( the old one) wasn't also
nearing EOL I am currently on the phone but if You want more details I can
dig up the bug with details of what I am talking about.

On Tuesday, 17 May 2016, David Cheney  wrote:

> What's the plan for mongo 3.2 ? Will we be required to support 2.x
> versions for the foreseeable future, or is there a possibility to make
> it a build or run time failure if mongo < 3.2 is installed on the host
> ?
>
> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
> > wrote:
> > On 17/05/2016, Curtis Hovey-Canonical  > wrote:
> >>
> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in xenial
> >> and without other changes, 2.4 will be used by all other 1.25 series.
> >
> > This isn't yet true, there's a bug open for it:
> >
> > "Use juju-mongodb2.6 for 1.25 on xenial"
> > 
> >
> > I had made the packaging change, but without juju code changes as well
> > it just went and installed the old (2.4) juju-mongodb anyway when
> > setting up a state server.
> >
> > 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

Re: Connecting to the controller database w/mongodb 3.2

[Horacio Duran]

so, for case 1) this link explains how to add the repo
http://askubuntu.com/questions/724749/install-mongo-3-2-on-ubuntu-15-10
for 2) following
https://docs.mongodb.com/manual/reference/connection-string/ should work



On Fri, May 13, 2016 at 12:57 PM, Casey Marshall <
casey.marsh...@canonical.com> wrote:

> On Fri, May 13, 2016 at 10:52 AM, Horacio Duran <
> horacio.du...@canonical.com> wrote:
>
>> By connect I assume you mean to use the shell, for this you need the
>> mongodb-org papa and install mongodb-org-shell, I am currently on the phone
>> but as soon as I get to a computer I'll send you links
>>
>>
> Well, for use case #1, yes, use the shell.
>
> For use case #2, I'd be using github.com/dcu/mongodb_exporter, which uses
> mgo.v2 and just needs a mongodb URI
> <https://github.com/dcu/mongodb_exporter/blob/master/mongodb_exporter.go#L26>
> .
>
>
>> On Friday, 13 May 2016, Casey Marshall <casey.marsh...@canonical.com>
>> wrote:
>>
>>> I seem to be unable to connect to the Juju 2.0 controller database
>>> lately. I'm thinking this might be related to the move to mongodb 3.2.
>>>
>>> Can someone in the know please share how to do this? While most users
>>> should never, ever connect directly to the controller's database, I have
>>> two good use cases for it:
>>>
>>> 1. It's sometimes necessary for debugging the state of a live controller.
>>> 2. I'd like to instrument a controller's mongodb with prometheus.io,
>>> but in order to do this, I need to derive the new connection info.
>>>
>>> Much thanks,
>>> Casey
>>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Connecting to the controller database w/mongodb 3.2

[Horacio Duran]

By connect I assume you mean to use the shell, for this you need the
mongodb-org papa and install mongodb-org-shell, I am currently on the phone
but as soon as I get to a computer I'll send you links

On Friday, 13 May 2016, Casey Marshall  wrote:

> I seem to be unable to connect to the Juju 2.0 controller database lately.
> I'm thinking this might be related to the move to mongodb 3.2.
>
> Can someone in the know please share how to do this? While most users
> should never, ever connect directly to the controller's database, I have
> two good use cases for it:
>
> 1. It's sometimes necessary for debugging the state of a live controller.
> 2. I'd like to instrument a controller's mongodb with prometheus.io, but
> in order to do this, I need to derive the new connection info.
>
> Much thanks,
> Casey
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

a few notes on common windows breaking mistakes.

[Horacio Duran]

Hello all, this past week I have spent some time fixing Wintows tests for
go 1.6, many errors where caused by http being more strict on what it will
take on a Get and therefore many innocent mistakes often made in tests
where suddenly not so innocent, so just as a friendly reminder.

* Always join paths with filepath.Join,
* if you want to represent a fake absolute path, don't just append "/"
either try to obtain current root/drive letter or make them into a
conditional variable that uses ":" for windows and "/" for
the rest
* don't craft File URLs (file://) by hand, for this there is
utils.MakeFileURL that has a different implementation for windows and linux
paths. many errors where caused by stuff like: "file://" + aRandomPath +
"/tools" which is a combination of this point and the previous one.

Hope this reminder helps.
Cheers
--
Horacio
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

[Horacio Duran]

yes, that workaround works, also you can change /etc/default/lxd-bridge and
restart the lxd-bridge service.

On Wed, Apr 6, 2016 at 6:12 PM, Casey Marshall  wrote:

> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer <
> alexis.bruem...@canonical.com> wrote:
>
>>
>> Hi All,
>>
>> As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the
>> latest LXD will not work with Juju 2.0-beta3.  This is a result of LXD
>> moving to use a default bridge of lxdbr0 and Juju expecting lxcbr0.  Thanks
>> to the heads up and help from the LXD team there is a fix for this in Juju
>> master that will be available in the release next week.  However, until
>> then Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this work
> for beta3? I've been able to bootstrap with latest LXD and current Juju
> master (beta4) by configuring LXD this way.
>
>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

[Horacio Duran]

yes, that workaround works, also you can change /etc/default/lxd-bridge and
restart the lxd-bridge service.

On Wed, Apr 6, 2016 at 6:12 PM, Casey Marshall  wrote:

> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer <
> alexis.bruem...@canonical.com> wrote:
>
>>
>> Hi All,
>>
>> As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the
>> latest LXD will not work with Juju 2.0-beta3.  This is a result of LXD
>> moving to use a default bridge of lxdbr0 and Juju expecting lxcbr0.  Thanks
>> to the heads up and help from the LXD team there is a fix for this in Juju
>> master that will be available in the release next week.  However, until
>> then Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this work
> for beta3? I've been able to bootstrap with latest LXD and current Juju
> master (beta4) by configuring LXD this way.
>
>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Horacio Duran]

As a non English native myself I find destroy to be much more final than
kill, to me destroy sounds like kill and then burn just in case, but I
don't know if this extends to other non English speakers too.

On Wednesday, 6 April 2016, Nate Finch <nate.fi...@canonical.com> wrote:

> Also +1 to Andrew's proposal.  In particular, the difference between kill
> and destroy is pretty arbitrary from a vocabulary standpoint, so it's not
> clear which one is the default and which one is the extreme measure.  A
> flag on destroy is a lot more clear in that regard (and reduces the number
> of commands needed).
>
> On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran <horacio.du...@canonical.com
> <javascript:_e(%7B%7D,'cvml','horacio.du...@canonical.com');>> wrote:
>
>> Strong +1 to what Andrew just proposed
>>
>> On Wednesday, 6 April 2016, Andrew Wilkins <andrew.wilk...@canonical.com
>> <javascript:_e(%7B%7D,'cvml','andrew.wilk...@canonical.com');>> wrote:
>>
>>> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding <rick.hard...@canonical.com>
>>> wrote:
>>>
>>>> +1 to the -1 of a new command for this. I'd like to raise the
>>>> discussion with the technical board as I'd like understand why the change
>>>> the change that the team had to make made it impossible for kill-controller
>>>> to function and what we could do to allow the team to remove legacy code,
>>>> but still be able to kill off things.
>>>>
>>>
>>> Sorry, I probably should have started a new thread; this is orthogonal.
>>> Still worth talking about with the board, but orthogonal to removing
>>> details of a controller. You might "juju register" someone else's
>>> controller, and then want to remove it from your client without destroying
>>> it.
>>>
>>> I think the UX could do with rethinking. There's a few issues:
>>>  (1) It's too easy to lose resources via kill-controller. See:
>>> https://bugs.launchpad.net/juju-core/+bug/1559701 and
>>> https://bugs.launchpad.net/juju-core/+bug/1566011
>>>  (2) It's not clear from the name what kill-controller vs.
>>> destroy-controller is, and so it's easy to assume they either do the same
>>> thing, or just randomly choose one and run it. That leads to (1) happening
>>> more than we'd like or expect.
>>>  (3) destroy-controller is harder to use than kill-controller for the
>>> standard case of destroying the controller and all of its hosted models.
>>> You have to pass "--destroy-all-models" to destroy-controller, which you
>>> don't have to pass to kill-controller. I don't understand the point of
>>> that, given that you're already asked whether you want to destroy the
>>> controller or not.
>>>
>>> What I would like to see is:
>>>  * kill-controller to be dropped
>>>  * destroy-controller's --destroy-all-models flag to be dropped, and
>>> implied by the accepted prompt (or -y)
>>>  * destroy-controller to take on a --force flag, causing it to do what
>>> kill-controller does now, and what destroy-environment --force used to do
>>>  * a new command to remove a controller from the client
>>>
>>> Why a new command? Because removing/forgetting is orthogonal to
>>> destroying. It's plain weird to say "kill-controller --forget" (or
>>> --cleanup, or whatever) if you're removing details of a live controller
>>> that you just don't want to use any more.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
>>>> andrew.wilk...@canonical.com> wrote:
>>>>
>>>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>>>> cheryl.jenni...@canonical.com> wrote:
>>>>>
>>>>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>>>>
>>>>>> We should provide a way to clean up controllers without making the
>>>>>> user manually edit juju's files.
>>>>>>
>>>>>
>>>>> Unless anyone objects, or has a better spelling, I will be adding a
>>>>> command to do this:
>>>>>
>>>>> juju purge-controller 
>>>>>
>>>>> The command will require a "-y" or prompt for confirmation, like
>>>>> kill-controller. It will not attempt to destroy the controller, it will
>>>>> just remove the details of it from the client.
>>>>>
>>>

Re: Unable to kill-controller

[Horacio Duran]

Strong +1 to what Andrew just proposed

On Wednesday, 6 April 2016, Andrew Wilkins 
wrote:

> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding  > wrote:
>
>> +1 to the -1 of a new command for this. I'd like to raise the discussion
>> with the technical board as I'd like understand why the change the change
>> that the team had to make made it impossible for kill-controller to
>> function and what we could do to allow the team to remove legacy code, but
>> still be able to kill off things.
>>
>
> Sorry, I probably should have started a new thread; this is orthogonal.
> Still worth talking about with the board, but orthogonal to removing
> details of a controller. You might "juju register" someone else's
> controller, and then want to remove it from your client without destroying
> it.
>
> I think the UX could do with rethinking. There's a few issues:
>  (1) It's too easy to lose resources via kill-controller. See:
> https://bugs.launchpad.net/juju-core/+bug/1559701 and
> https://bugs.launchpad.net/juju-core/+bug/1566011
>  (2) It's not clear from the name what kill-controller vs.
> destroy-controller is, and so it's easy to assume they either do the same
> thing, or just randomly choose one and run it. That leads to (1) happening
> more than we'd like or expect.
>  (3) destroy-controller is harder to use than kill-controller for the
> standard case of destroying the controller and all of its hosted models.
> You have to pass "--destroy-all-models" to destroy-controller, which you
> don't have to pass to kill-controller. I don't understand the point of
> that, given that you're already asked whether you want to destroy the
> controller or not.
>
> What I would like to see is:
>  * kill-controller to be dropped
>  * destroy-controller's --destroy-all-models flag to be dropped, and
> implied by the accepted prompt (or -y)
>  * destroy-controller to take on a --force flag, causing it to do what
> kill-controller does now, and what destroy-environment --force used to do
>  * a new command to remove a controller from the client
>
> Why a new command? Because removing/forgetting is orthogonal to
> destroying. It's plain weird to say "kill-controller --forget" (or
> --cleanup, or whatever) if you're removing details of a live controller
> that you just don't want to use any more.
>
> Cheers,
> Andrew
>
> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com
>> > wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>> cheryl.jenni...@canonical.com
>>> > wrote:
>>>
 Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059

 We should provide a way to clean up controllers without making the user
 manually edit juju's files.

>>>
>>> Unless anyone objects, or has a better spelling, I will be adding a
>>> command to do this:
>>>
>>> juju purge-controller 
>>>
>>> The command will require a "-y" or prompt for confirmation, like
>>> kill-controller. It will not attempt to destroy the controller, it will
>>> just remove the details of it from the client.
>>>
>>> (Alternative suggestion for spelling: "juju forget-controller".
>>> Purge-controller may suggest that we're purging a controller of its
>>> contents, rather than purging the controller from the client?)
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch > wrote:

> This just happened to me, too.  Kill-controller needs to work if at
> all possible.  That's the whole point.  And yes, users may not hit 
> specific
> problems, but devs do, and that wastes our time trying to figure out how 
> to
> manually clean up the garbage.
>
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
> rick.hard...@canonical.com
> > wrote:
>
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com
>> >
>> wrote:
>>
>>> In a non-beta release we would make sure that the config changes
>>> aren't backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user 
>> the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an 
>> exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>> --
>> Juju-dev mailing list
>> 

Re: Unable to kill-controller

[Horacio Duran]

The issue I see with that approach is that in that case kill-controller
might be doing less than you expect instead of more, suppose the controller
is having transient issues and kill controller cannot reach the cloud for
deletion, this would forget the controller and leave it in the cloud,
forget-controller instead tells us very clearly what is going to happen,
the change is going to be local and not affect the controller.
My 2c

On Wednesday, 6 April 2016, Nick Veitch <nick.vei...@canonical.com> wrote:

> just my tuppence
>
> instead of having another command, can't we just add this as an option to
> kill-controller?
>
> juju kill-controller --cleanup 
>
>
>
> On 6 April 2016 at 11:05, Horacio Duran <horacio.du...@canonical.com
> <javascript:_e(%7B%7D,'cvml','horacio.du...@canonical.com');>> wrote:
>
>>
>> I might be biased by years of apt-get but purge makes me think that you
>> are going to do what kill is supposed to do, forget sound more aligned whit
>> what you are really aiming to.
>>
>> On Wednesday, 6 April 2016, Andrew Wilkins <andrew.wilk...@canonical.com
>> <javascript:_e(%7B%7D,'cvml','andrew.wilk...@canonical.com');>> wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>> cheryl.jenni...@canonical.com> wrote:
>>>
>>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>>
>>>> We should provide a way to clean up controllers without making the user
>>>> manually edit juju's files.
>>>>
>>>
>>> Unless anyone objects, or has a better spelling, I will be adding a
>>> command to do this:
>>>
>>> juju purge-controller 
>>>
>>> The command will require a "-y" or prompt for confirmation, like
>>> kill-controller. It will not attempt to destroy the controller, it will
>>> just remove the details of it from the client.
>>>
>>> (Alternative suggestion for spelling: "juju forget-controller".
>>> Purge-controller may suggest that we're purging a controller of its
>>> contents, rather than purging the controller from the client?)
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch <nate.fi...@canonical.com>
>>>> wrote:
>>>>
>>>>> This just happened to me, too.  Kill-controller needs to work if at
>>>>> all possible.  That's the whole point.  And yes, users may not hit 
>>>>> specific
>>>>> problems, but devs do, and that wastes our time trying to figure out how 
>>>>> to
>>>>> manually clean up the garbage.
>>>>>
>>>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>>>>> rick.hard...@canonical.com> wrote:
>>>>>
>>>>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>>>>> andrew.wilk...@canonical.com> wrote:
>>>>>>
>>>>>>> In a non-beta release we would make sure that the config changes
>>>>>>> aren't backwards incompatible.
>>>>>>>
>>>>>>
>>>>>> I think this is the key thing. I think that kill-controller is an
>>>>>> exception to this rule. I think we should always at least give the user 
>>>>>> the
>>>>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>>>>> release. I'd like to ask us to explore making kill-controller an 
>>>>>> exception
>>>>>> to this policy and that if tests prove we can't bootstrap on one beta and
>>>>>> kill with trunk that it's a blocking bug for us.
>>>>>> --
>>>>>> 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
>> <javascript:_e(%7B%7D,'cvml','Juju-dev@lists.ubuntu.com');>
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
>
> --
> Nick Veitch,
> CDO Documentation
> Canonical
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Horacio Duran]

I might be biased by years of apt-get but purge makes me think that you are
going to do what kill is supposed to do, forget sound more aligned whit
what you are really aiming to.

On Wednesday, 6 April 2016, Andrew Wilkins 
wrote:

> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com
> > wrote:
>
>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>
>> We should provide a way to clean up controllers without making the user
>> manually edit juju's files.
>>
>
> Unless anyone objects, or has a better spelling, I will be adding a
> command to do this:
>
> juju purge-controller 
>
> The command will require a "-y" or prompt for confirmation, like
> kill-controller. It will not attempt to destroy the controller, it will
> just remove the details of it from the client.
>
> (Alternative suggestion for spelling: "juju forget-controller".
> Purge-controller may suggest that we're purging a controller of its
> contents, rather than purging the controller from the client?)
>
> Cheers,
> Andrew
>
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch > > wrote:
>>
>>> This just happened to me, too.  Kill-controller needs to work if at all
>>> possible.  That's the whole point.  And yes, users may not hit specific
>>> problems, but devs do, and that wastes our time trying to figure out how to
>>> manually clean up the garbage.
>>>
>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding >> > wrote:
>>>
 On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
 andrew.wilk...@canonical.com
 > wrote:

> In a non-beta release we would make sure that the config changes
> aren't backwards incompatible.
>

 I think this is the key thing. I think that kill-controller is an
 exception to this rule. I think we should always at least give the user the
 ability to remove their stuff and start over with the new alpha/beta/rc
 release. I'd like to ask us to explore making kill-controller an exception
 to this policy and that if tests prove we can't bootstrap on one beta and
 kill with trunk that it's a blocking bug for us.
 --
 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: Usability issues with status-history

[Horacio Duran]

I think you are attributing too much importance to some data that can
hardly be considered information let me try to mention some points that I
think are valid here.
1) Not every message is valuable, you state that every message we throw
away makes it harder to debug, but certainly a message like "downloading
N%" is useless, you can record the start of the download and failure/end
but the steps intermediate are quite useless. We can argue later which
messages satisfy this criteria, but I am completely sure that some do.
2) Not filling the history buffer with superfluos messages will help here,
although I do agree we should find a more elegant deletion criteria (time
sounds right) while not loosing sight of size (at this point no one has a
record of the actual cost of storing these things in terms of space
therefore we cannot make decisions based on the scale we want to support.

Regarding "making the charm decide" I agree its something we might not want
to do, I would actually not export this to the charm, I would just use it
internally, since we are opinionated we can very well decide what goes
there.

Adding more status information will help adding observability, not having a
flag for internal ephemeral statuses strikes me a bit as deleting with the
left hand what you just wrote with the right one (saying might not
translate well from Spanish)

Finally, can this be a potential shoot in our own foot tool? yes, but so
can almost any other part of our code base, this is something juju will use
to report information to the user therefore we control it and, if we are
not careful we will shot ourselves but, then again, if we are not careful
with almost any part of the code we will do so too.

Cheers

On Thu, Mar 17, 2016 at 6:51 AM, William Reade 
 wrote:

I see this as a combination of two problems:
>
> 1) We're spamming the end user with "whatever's in the status-history
> collection" rather than presenting a digest tuned for their needs.
>
2) Important messages get thrown away way too early, because we don't know
> which messages are important.
>
> I think the pocket/transient/expiry solutions boil down to "let's make the
> charmer decide what's important", and I don't think that will help. The
> charmer is only sending those messages *because she believes they're
> important*; even if we had "perfect" trimming heuristics for the end user,
> we do the *charmer* a disservice by leaving them no record of what their
> charm actually did.
>
> And, more generally: *every* message we throw away makes it hard to
> correctly analyse any older message. This applies within a given entity's
> domain, but also across entities: if you're trying to understand the
> interactions between 2 units, but one of those units is generating many
> more messages, you'll have 200 messages to inspect; but the 100 for the
> faster unit will only cover (say) the last 30 for the slower one, leaving
> 70 slow-unit messages that can't be correlated with the other unit's
> actions. At best, those messages are redundant; at worst, they're actively
> misleading.
>
> So: I do not believe that any approach that can be summed up as "let's
> throw away *more* messages" is going to help either. We need to fix (2) so
> that we have raw status data that extends reasonably far back in time; and
> then we need to fix (1) so that we usefully precis that data for the user
> (...and! leave a path that makes the raw data observable, for the cases
> where our heuristics are unhelpful).
>
> Cheers
> William
>
> PS re: UX of asking for N entries... I can see end-user stories for
> timespans, and for "the last N *significant* changes". What's the scenario
> where a user wants to see exactly 50 message atoms?
>
> On Thu, Mar 17, 2016 at 6:30 AM, John Meinel 
>  wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 8:41 AM, Ian Booth 
>>  wrote:
>>
>>>
>>> Machines, services and units all now support recording status history.
>>> Two
>>> issues have come up:
>>>
>>> 1. https://bugs.launchpad.net/juju-core/+bug/1530840
>>>
>>> For units, especially in steady state, status history is spammed with
>>> update-status hook invocations which can obscure the hooks we really
>>> care about
>>>
>>> 2. https://bugs.launchpad.net/juju-core/+bug/1557918
>>>
>>> We now have the concept of recording a machine provisioning status. This
>>> is
>>> great because it gives observability to what is happening as a node is
>>> being
>>> allocated in the cloud. With LXD, this feature has been used to give
>>> visibility
>>> to progress of the image downloads (finally, yay). But what happens is
>>> that the
>>> machine status history gets filled with lots of "Downloading x%" type
>>> messages.
>>>
>>> We have a pruner which caps the history to 100 entries per entity. But
>>> we need a
>>> way to deal with the spam, and what is displayed when the user asks for
>>> juju
>>> status-history.
>>>
>>> Options to solve bug 1

Re: Diffing string checker

[Horacio Duran]

You are my new personal hero

On Thursday, 25 February 2016, Andrew Wilkins 
wrote:

> Howdy,
>
> Occasionally I'll change a test, and some string equality test will fail
> with a wall of text. Sometimes we shouldn't be checking the whole string,
> but sometimes it's legitimate to do so, and it can be difficult/tedious to
> spot the differences.
>
> I've just written a checker which diffs the two string args, and
> colourises the output. You may find it useful. I'm using red/green
> background, but I also added bold for insertions, strike-through for
> deletions, in case you're red/green colour blind. My terminal doesn't do
> strike-through, and your's probably doesn't either. Anyway, the important
> thing is you can see the difference between bits that are the same vs.
> insertions/deletions.
>
> Code is at github.com/axw/fancycheck. Just replace
> c.Assert("x", gc.Equals, "y")
> with
> c.Assert("x", fancycheck.StringEquals, "y")
>
> Cheers,
> Andrew
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Defaulting tests internal to the package

[Horacio Duran]

I have two points, which might be biased by my personal opinion here:
1) API end points tests are good, they exercise that what you are
advertising to the public is what you meant, for the cases you are
interested. If they are properly coded you should need to export the least
amount of things in export tests and be able to plug your own stubs through
interfaces.
I don't think that we should call things that exercise a public interface
end to end a unit test though, for me a unit test is a test for the
smallest testable code unit you can manage.
2) all the internal functions adhere to a contract and subject to a set of
assumptions that the developer makes, it is a statement to what are the
boundaries of such a piece of code and a test is a great way to communicate
and maintain that contract. If that contract is broken by third party
dependencies or by a different developer, the best way to find out is to
see a very local test failing instead of knowing that "something" in the
package is broken. I completely disagree on the statement that is false
security, unit tests are not supposed to be mathematical proof just
statistical sampling, I feel that if a test passes for a set of cases I
deem representative of the universe of input my function takes I have a
very justified security on the functionality for the intended purpose and a
solid set of samples for the next person touching that code to respect.
Additionally it is a nice practice that allows people finding corner cases
to add them as test to ensure we won't have regressions while documenting
where in the code the corner case hits.

Sorry for the poor redaction, I wrote this on my phone

On Saturday, 23 January 2016, William Reade 
wrote:

> On Sat, Jan 23, 2016 at 12:27 AM, David Cheney  > wrote:
>
>> I agree with Nate, using external tests just adds more boilerplate.
>>
>
> I agree that it's often *harder* to write external tests; but it's always
> harder to write code that's reliable (and, specifically, here, resilient in
> the face of distracted/hurried maintenance programming, which is a
> perennial problem).
>
> But I'd love to be shown where I'm wrong. Do you have any counterpoints to
> my statements about the practical impact of internal tests?
>
> Cheers
> William
>
>
>> On Sat, Jan 23, 2016 at 7:23 AM, William Reade
>> > > wrote:
>> > On Fri, Jan 22, 2016 at 5:17 PM, Nate Finch > >
>> > wrote:
>> >>
>> >> I'm glad to hear Roger's opinion about testing internal code... that's
>> >> exactly how I feel.  True unit tests of small bits of code are easy to
>> >> write, easy to read and understand, and give you confidence that your
>> code
>> >> is doing what you think it'll do in a wide variety of cases.  If the
>> unit
>> >> test fails, it's generally incredibly clear where the fault in the code
>> >> lies, and it's easy to fix either the code or the test.  In 6 months,
>> you or
>> >> someone else can go back to the tests, easily understand what they are
>> >> testing, and modify them trivially when making a bug fix or
>> improvement.
>> >
>> >
>> > Tests for unexported utility functions can give you great confidence in
>> the
>> > operation of those unexported utility functions... but those tests will
>> > continue to pass even if you change the package so that they're never
>> > actually used, and that renders those tests' diagnostic power pretty
>> much
>> > worthless. And, to make things worse, that sort of test is very
>> frequently
>> > used as a justification for skipping tests of the same functionality
>> against
>> > the exported interface.
>> >
>> >>
>> >> While you certainly *can* write code that tests all the corner cases of
>> >> some small utility function through the external API... those tests
>> will
>> >> almost always be incredibly opaque and hard to understand, and
>> generally
>> >> much more complicated than they would be if you could just test the
>> utility
>> >> function by itself.  This is often a problem I have with our current
>> >> tests... it's hard to see what is actually being tested, and even
>> harder to
>> >> verify that the test itself is correct and complete.  When a test
>> fails, you
>> >> often have no clue where the actual problem lies, because the test
>> traverses
>> >> so much code.
>> >
>> >
>> > I think you're misdiagnosing the problems with our current tests. Most
>> of
>> > our rubbish "unit" tests are rubbish because they're not unit tests at
>> all:
>> > they're full-stack tests that are utterly and inextricably bound up
>> with the
>> > implementation details of *all* the layers underneath, and depend
>> critically
>> > upon assumptions about how those other layers work. And, yes, one of the
>> > worst 

Re: workers using *state.State

[Horacio Duran]

There is lazy and there is also "I just based in that other worker" which
happens, I am the proud parent of statushistorypruner and a rewrite is
underway too, sorry.

On Tuesday, September 8, 2015, Tim Penhey  wrote:

> On 09/09/15 11:22, Andrew Wilkins wrote:
> > On Wed, Sep 9, 2015 at 6:14 AM Ian Booth  
> > >> wrote:
> >
> > Those workers below aren't the only ones. There's also minunits and
> > peergrouper
> > workers.
> >
> > No-one does these things on purpose. Just last week I caught and
> > rejected a pull
> > request to introduce a new worker depending on state directly.
> > People make
> > mistakes. Perhaps we should introduce a test which fails if state is
> > imported
> > into any worker code. We have similar tests already for other
> > forbidden imports.
> >
> >
> > +1. I was thinking the same thing, and eventually that test should be
> > increased to other packages too.
>
> Let's be honest, developers are lazy. When under pressure to land
> things, they go and look for the simplest way to get something done.
>
> The problem has been that we didn't shout loud enough early enough that
> there were to be "NO MORE STATE WORKERS", and what's more, making it a
> priority to change the existing ones to api workers.
>
> In case any one missed it, "NO MORE STATE WORKERS". Onyx will take the
> dblogpruner and txnpruner as we added those, and Menno already mentioned
> this.
>
> Bugs have been filed for the five workers using *state.State directly,
> and have been added to the tech-debt kanban board.
>
> https://canonical.leankit.com/Boards/View/116651667#workflow-view
>
> 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: Uniter tests for update-status hook - BLOCKER

[Horacio Duran]

On 20/07/15 07:57, William Reade wrote:
 On Mon, Jul 20, 2015 at 6:42 AM, Tim Penhey tim.pen...@canonical.com
 mailto:tim.pen...@canonical.com wrote:

 Hi folks,

 Earlier today I was investigating this CRITICAL BLOCKER bug:
 https://bugs.launchpad.net/juju-core/+bug/1475724


 I'll talk about the specific bug to begin with, but there's a much
 more important bit further down. If you're pressed for time, skip down
 to the point marked THE IMPORTANT BIT.

 But as you can see above, there was not a second update-status before
 the config-changed (but there is one after on both).

 Really the test doesn't care one hoot about the update-status
 hook, all
 it really cared about checking was the config-changed. [2]

The immediate bit:
So, I agree we have a big elephant on the room and we might have all
been looking the other way (most likely distracted by the pack of
velocirraptors on the other side).
We ought to sit and talk about this tech-debt negotiation, as any debt
negotiation this takes a couple of rounds of discussion around a table,
some shouting and a conclusion that might let none of us completely
happy but will produce the best outcome in terms of reliability and
functionality for the experience/service we are trying to provide here.
In the immediate however, this is blocking master so Ill be working on a
solution that solves the symptom at hand as we know this works in
practice it is a matter of better defining the tests for now while we
work ASAP in a better foundation for at least idle and whatever is built
on top of it.
As a side note, we need to spread some education about the uniter, its
innards and the design philosophy around it since much of the added code
on it seems a result of just throwing a case into the select, see what
it did and then accommodate to it (my very first approach included).
Cheers.
--
Horacio
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: coloring juju logs a bit

[Horacio Duran]

Looks really nice, if I have to maintain something less I am happy. Is
there any conf required that you can share with us?

On Sunday, May 3, 2015, Marco Ceppi marco.ce...@canonical.com wrote:

 ccze also works really well for colouring log output and is one less tool
 we have to build/maintain. Getting some fixes to it so it better colors
 juju logs would be a win I think. FWIW, I and others in eco have been using
 it for a while on a variety of application outputs including juju

 Marco

 On Tue, Apr 28, 2015 at 4:30 PM, Horacio Duran 
 horacio.du...@canonical.com
 javascript:_e(%7B%7D,'cvml','horacio.du...@canonical.com'); wrote:

 After an interesting discussion with one of my peers where things like
 bash is the devil where said, I decided to go the go way, I upgraded a
 bit a tool from our own Nate Finch to help filter and color the logs. The
 coloring is a bit crude but I have found it to be a quite useful little
 tool.
 here is the url https://github.com/natefinch/nolog
 and here is a sample of output: http://imgur.com/qRuaROh

 On Fri, Mar 6, 2015 at 2:31 PM, Horacio Duran 
 horacio.du...@canonical.com
 javascript:_e(%7B%7D,'cvml','horacio.du...@canonical.com'); wrote:

 So, for those like me, that usually end up hunting for what broke your
 tests and find themselves swimming in a sea of log output, I have added a
 bit of setup to my supercat to get some useful coloring.
 I most likely will be doing this in a more serious and less hacky (and
 more juju dev oriented) way bu in the mean time:
 create .spcrc/spcrc-juju-tests
 with the contents of: http://pastebin.ubuntu.com/10551462/
 and to get some coloring (bear in mind that if everything went well you
 will get absolutely nothing colored)
 go test github.com/juju/juju/... 21 | spc -w -t juju-tests

 the output is something like this
 http://imgur.com/TErS04p



 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 javascript:_e(%7B%7D,'cvml','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: restoring juju state

[Horacio Duran]

This is a bit rough, I have not had time to make it better or add the other
less common use cases or HA but should give a more decent explanation
https://docs.google.com/a/canonical.com/document/d/1AtAo-uxED5TvXahJNytF-PIswRv9T0lewcyu699Rpyk/edit?usp=sharing

On Wed, Mar 25, 2015 at 3:44 PM, Eric Snow eric.s...@canonical.com wrote:

 On Tue, Mar 24, 2015 at 9:25 PM, Tim Penhey tim.pen...@canonical.com
 wrote:
  I'm seriously not in favour of calling it recover, and not just
  because it has a particular meaning in Go.

 I'm glad you said so then. :)

 
  Perhaps rebuild or recreate, but recover feels wrong.

 Got it.  I'm not married to recover.  It was just the first
 reasonable (to me) alternative that popped into my head.

 rebuild and recreate could work, though they don't seem quite
 right either.  Perhaps something more like replace or reset?  So
 far it's all re* names, so maybe wipe? :)  The catch is that it will
 be a subcommand of juju backups so it also needs to be something
 that implies applying a backup rather than affecting a backup.  Hmm.
 apply?

 -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: restoring juju state

[Horacio Duran]

Nope this is not very accurate I believe that you got some parts wrong out
of our conversation. I am currently on vacation but upon return I'll submit
a writeup with some graphic flows explaining how this all works (the
recover part I agree with, in any case what is being recovered/restored is
the state server so that is what we should be trying to convey with the
name)

On Monday, March 23, 2015, Eric Snow eric.s...@canonical.com wrote:

 juju 1.23 adds the new restore, all written in Go and integrated into
 core.  This is a great thing and the result of a lot of effort by
 Horacio.  In discussions with him about it, there are two things that
 came up that I wanted to bring up here.

 First, the name restore is misleading.  It gives the impression of
 capability that it does not actually provide.  I propose that we
 rename it to recover in 1.23 and forward.

 Second, I am now under the impression that after restore is complete,
 the environment is left with instances on the provider that juju
 should be cleaning up but isn't.  In the case of a single state
 server, the old state server instance is left dead but still active.
 In the case of HA, in addition to the state server that handles the
 restore API request, the other state servers are also left in that
 same situation.

 So for a 3 server replicaset you are left with 3 instances that juju
 is not using but that are still active on the provider side.  Users
 may not realize they need to manually remove those instances to avoid
 further costs (depending on the provider, I suppose).  Please explain
 if I've misunderstood this or if juju has some other mechanism by
 which such instances are cleaned up.  If I haven't missed something
 then I think we need to fix restore to clean up those state machines.

 -eric

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com javascript:;
 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

dependency branches for 1.21

[Horacio Duran]

Hey, I have been backporting licencing fixes into utils, syslog and testing
for 1.21 release. While doing this I noticed that the revs testing and
utils used in 1.21 are quite far from what we use in master so, in order to
prevent bringing unwanted changes to 1.21 by bumping the deps to HEAD I
branched utils and testing at the version they where in 1.21.
Both repos now have a 1.21 branch where all backported changes should go,
if any.
I presume I will be doing the same for 1.22 If I find the case to be the
same.
Cheers.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: git clients vulnerability found

[Horacio Duran]

I dont know, some might run osx (also we have a client for windows and osx
so I dont discard that anyone might be using those tools now and then)

On Thu, Dec 18, 2014 at 6:39 PM, David Cheney david.che...@canonical.com
wrote:

 Fortunately all of us run an operating system with a case sensitive
 file system, right ?

 On Fri, Dec 19, 2014 at 8:32 AM, Horacio Duran
 horacio.du...@canonical.com wrote:
  Heads up people
 
 https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
  apparently there is a vulnerability in git client that might be exploited
  via pushing certain snippets to the repos.
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 

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

Re: juju min version feature

[Horacio Duran]

Ideally we will provide tools for the user to determine this, unless I
understood wrongly the requirement.


On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding rick.hard...@canonical.com
wrote:

 Then we should take up the burden to help others realize that their code
 will work with older versions of juju. Perhaps I am assuming, but if I am a
 charm author and I am wondering what my minimum version of juju is I will
 select the one I am currently using. Running tests and older versions are
 not something I'm going to do want to take up the burden on. This means
 that users of juju will have a smaller set of charms available to them
 because of this declaration even though it may actually work.

 Rick
 On Dec 15, 2014 11:51 AM, Nate Finch nate.fi...@canonical.com wrote:

 OK, so, many people in juju-core have talked about this with Eco, and we
 came to the conclusion that per-feature flags would be way too confusing
 for the charm consumer.  When I want to deploy a charm, I don't wnat to
 have to figure out what version of juju supports leader election so I can
 know if the charm I want is supported by my version of juju.  I just want
 to see a min version and compare it to my version of juju.

 This does put a little more burden on charm authors, to do that
 translation themselves, but they would need to be able to do that anyway to
 understand what versions of juju support their charm.  This way we at least
 take that burden off the person deploying the charm.

 Also, we very specifically only support min version.  This just means
 we'll need to be backwards compatible. There won't be leader election 2.0
 that makes 1.0 not work.

 On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch nate.fi...@canonical.com
 wrote:

 last copy of context to juju-dev

 On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard 
 adam.coll...@canonical.com wrote:

 On 15 December 2014 at 15:06, Marco Ceppi marco.ce...@canonical.com
 wrote:

 I'm against this idea, what if something changes in the implementation
 of leader_election? Now there's a requirement to track version of features
 released and complexity grows.


 Well if that were to happen, the charm author would have to know which
 version of Juju they need anyway? In fact the version based tracking of
 this makes it even worse, let's for the sake of argument assume that leader
 election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju
 1.24.0. If the charm is using the 1.0 model they have to say I require
 Juju = 1.22.0  and  Juju 1.24.0. In the capability model they simply
 state I require a Juju capable of leader_election_2 (or some other better
 token that describes the change in a semantic way).

 I think the capabilities based model can easily extend into a provider
 based constraint as well. So the charm can say I require container
 addressing and MAAS Provider will be fine but everything else will fail as
 per the current spec. Using a capabilities model is more expressive and can
 be extended. Using version numbers is clunky.


 It seems much easier (testing and comprehension-wise) to have the
 author say Won't work unless you have this version of Juju or higher.
 This makes testing, linting, and other typical charm author actions 
 simpler
 while yielding virtually the same result.


 I don't think manually mapping features to Juju versions is simple for
 anyone now, let alone the expanded base of charm authors that we're
 targetting.


 As for your use case of bugs in juju break user experience is an
 already existent risk and can be improved in other ways that I think are
 outside the scope of this.


 Agreed.


 --
 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: Can we removed all devel agents from released streams.

[Horacio Duran]

I can add a bunch of detail, actually:

The install was: 1.18.4-trusty-amd64

The persons machine:

$ juju --version
1.20.11-trusty-amd64

upgrade was: juju upgrade-juju --upload-tools --version=1.20.11

The resulting files:
drwxr-xr-x 2 root root 4096 Jul 29 17:52 1.18.4-trusty-amd64
drwxr-xr-x 2 root root 4096 Nov 13 18:14 1.19.4-trusty-amd64
lrwxrwxrwx 1 root root   19 Nov 13 18:10 machine-0 - 1.19.4-trusty-amd64
lrwxrwxrwx 1 root root   19 Nov 13 18:14 unit-ksplice-9 -
1.19.4-trusty-amd64
then at log:
2014-11-13 18:32:11 ERROR juju.worker.instanceupdater updater.go:267 cannot
set addresses on 0: cannot set addresses of machine 0: cannot set
 addresses for machine 0: state changing too quickly; try again
soon


2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:776 upgrade to
1.19.4-trusty-amd64 already completed.
2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:757 upgrade to
1.19.4-trusty-amd64 completed.


On Thu, Nov 13, 2014 at 7:41 PM, Ian Booth ian.bo...@canonical.com wrote:



 On 14/11/14 06:28, Curtis Hovey-Canonical wrote:
  We have another cases where an env using --upload-tools tried to
  upgrade from 1.18.4 to 1.20.x and got 1.19.x. I want to remove all the
  devel agents from the released streams.
 
  We have already created separate streams for devel and proposed agents
  to ensure environments cannot upgrade to them without explicitly set
  the environment to use them.
 
  I want to ensure we don't have old devel agents in our released
  streams. This will prevent anyone from getting these version from our
  official locations. This may also prevent environments that are idling
  on obsolete version from deploying more units.
 
  Are there other issues that will happen if I remove the devel agents?
  Is this a bad and dangerous idea?
 

 I think this is a good idea and can only see benefits.
 So +1 from me.

 Having said that, if they used upload-tools then the public metadata is
 not used
 anyway. Juju will generate metadata for the jujud it finds in the user's
 path
 (or compiles from source if no jujud is found). The metadata is written to
 their
 environ storage (for Juju  1.21). Do we have any more information about
 their
 setup? It would be interesting to understand what happened.

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

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

Re: Is ReviewBoard a good thing?

[Horacio Duran]

We will all be seeing each other in 2 weeks we can discuss it then

On Friday, September 19, 2014, Eric Snow eric.s...@canonical.com wrote:

 On Fri, Sep 19, 2014 at 7:55 AM, Matthew Williams
 matthew.willi...@canonical.com javascript:; wrote:
  I do think it's too early to tell though. Why not give it another week
 or 2
  then discuss in the cross teams if we want to keep it or not

 +1

 -eric

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com javascript:;
 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: getting rid of all-machines.log

[Horacio Duran]

Hey, In an effort to move forward with juju's windows integration I have
summarized what seems to be the core points of this discussion to the best
of my ability (please excuse me if I missed or misunderstood something).
The two core points of discussion on this thread are:
* should we remove all-machines.log: which has been voted against, at least
for the moment, since it is used for debug-log.
* how do we support logging in windows: The strongest suggestions here are
a syslog package by gabriel and logging into MongoDB by Gustavo.

We do require some decision on the front of windows logging to have a
complete windows support. Ideally we need senior citizens of juju dev
community to weight into this in order to get a clear path to follow.

Here is a summary I made to help myself while following this discussion:

​Nate original suggestion:
* Remove all-machines.log: Claiming it takes a lot of space and it is not a
multi platform solution

Tim, John, Aaaron, etc:
* all-machines.log is required for debug-log
* makes it big and it would be nice to rotate it.

Nate, gabriel:
* keep all-machines.log
* use a go-only solution (syslog package with ports from gabriel for
windows)
John
* agrees.

Nate, gabriel:
* remove rsyslog from al OSes in favor of one solution that fits all OSes
* Replace with go only solution.

Dave:
* Dont mind about the logs, make it just output and let external tools
handle logging and rotation.
* all-machines.log might be a bit bloated and it could contain less data
that is more useful.
(Here is the reference to 12factor that will later be attibuted to nate)
Ian:
* Agrees with dave, yet we should provide a rolling mechanism.

Gabriel:
* Windows does not support capturing stdout as a logging mechanism, it
requires to explicitly log into the event log.
* Thinks that using rsyslog to stream logs from agents to state server is
too much overhead on external tools.
* Proposes replacing external rsyslog with in app solution for the case of
streaming logs.
* Alternative solution, he does not recommend it, to create (and bundle
with jujud.exe) a wrapper for windows only.

Gustavo:
* Present a possible alternative by using a MongoDB capped collection
which will suit our use cases but does not recommend it because of the idea
needs maturing on some details.

Matt:
* We should provide the option to log to stdout or syslog.

Kapil:
* Supports Gustavo's idea of logging in a structured form into Mongo as it
makes sense to dump structured data with structure instead of serializing
it to be de-serialized later.
* We can send also messages to syslog and let OPS people collec them
themselves.

Gabriel (summarizing)
* I will be looking into event log for local windows logging. This will
probably require writing a package.
* the syslog change will solve in the sort term, the aggregation issue from
Windows nodes (when something better comes along, I will personally send a
case of beer or ice-cream...or both, to whomever removes syslog as a
dependency)
* lumberjack works *now* for local logging on both Windows and Ubuntu. It
simply removes 2 dependencies (for logging) with just a few lines of code...

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

issuing a jujud restart

[Horacio Duran]

Hey, I am currently working on restore command for juju state servers. I
find myself in the need, after putting all the back-up parts in place, of
restarting jujud, from within jujud. Can anyone shed some light on how to
do that?
Thank you all.
Cheers
--
Horacio Durán
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

determine if juju is upgrading

[Horacio Duran]

Hey, I have been running several CI tests lately and find very often the
following error:
2014-08-04 22:27:42 ERROR juju.cmd supercommand.go:323 upgrade in progress
-
At least when my machine is not under heavy load and I am at decent network
reach of amazon.
I wonder, is there a way to poll juju to know if its upgrading?

I think it is a bit drastic having CI tests fail for this (unless the test
checks is related to upgrade in some form) I believe that being able to do
the check and have the CI test check with a timeout before proceeding with
the rest of the tests would yield much cleaner results when we need to
review CI runs that failed.

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

Re: Making peergrouper accept a manual replicaset entry?

[Horacio Duran]

take a look at restore, it does that by hand look for rs.config on the code.


On Tue, Aug 5, 2014 at 5:33 PM, Wayne Witzel wayne.wit...@canonical.com
wrote:

 A user had some issues after an upgrade put them on the unstable Juju
 path. We've been working to get them back on stable and finally have them
 upgraded to 1.20.1.

 The issue we've run in to is that we have manually run an rs.initiate() to
 get the replica set setup. When they jumped versions it was across the
 non-HA / HA feature implementation. We have the proper IP and port in the
 replica set.

 The peergrouper is not aware of that replicaset and continues to report
 this error. http://pastebin.ubuntu.com/7963471/

 What collection do we need to update to so that the peergrouper is in sync
 with the replicaset config?


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

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


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

Re: avoiding unnecessarily entering upgrade mode

[Horacio Duran]

You had my verbal SGTM but have it written also

On Tuesday, August 5, 2014, David Cheney david.che...@canonical.com wrote:

 SGTM.

 On Wed, Aug 6, 2014 at 11:10 AM, Menno Smits menno.sm...@canonical.com
 javascript:; wrote:
  Right now, a Juju machine agent is in upgrade mode from the moment it
  starts until the upgrade-steps worker is finished. During this period API
  logins are heavily restricted and most of the agent's workers don't start
  until upgrade mode stops.
 
  This happens even when there is no upgrade to perform. The upgrade-steps
  worker always runs at machine agent startup and upgrade mode is in force
  until it finishes.
 
  Upgrade mode is typically short-lived (say 10 seconds) but if something
 is
  wrong (e.g. mongo issues) the upgrade-steps worker may take longer or not
  finish resulting in the user seeing lots of upgrade in progress
 messages
  from the client and in the logs.
  This is particularly confusing when a user hasn't even requested an
 upgrade
  themselves.
 
  I would like to change the machine agent so that upgrade mode is only
  entered if the version in agent.conf is different from the running
 software
  version. This would mean that upgrade mode is only entered if there is an
  actual upgrade to perform.
 
  The version in agent.conf is only updated after a successful upgrade so
 it
  is the right thing to use to determine if upgrade mode should be entered.
 
  The current behaviour means that the (idempotent) upgrade steps for the
  current version are always run each time the machine agent starts. If the
  change I'm proposing is implemented this will no longer happen. Does this
  seem like a problem to anyone? For instance, do we rely on the upgrade
 steps
  for the current version being run after bootstrap?
 
  The ticket for this work is at: https://bugs.launchpad.net/bugs/1350111
 
  Cheers,
  Menno
 
 
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com javascript:;
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com javascript:;
 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: CI regressions will block merges

[Horacio Duran]

Since $$fixes-1342937$$ is already committed I changed the state by hand in
the bug report sorry I did not do that before, I forgot it was no longer
automatic.



On Tue, Jul 29, 2014 at 3:05 PM, Curtis Hovey-Canonical 
cur...@canonical.com wrote:

 Magicians.

 I have updated the rules that test merges to abort when there are ci
 regressions and the PR doesn't claim to fix one of them

 Three bugs currently block merges into master. CI is looking for one
 of these three token:
 $$fixes-1347715$$
 $$fixes-1342725$$
 $$fixes-1342937$$

 Adding $$fixes-lp-bug-number$$ as a comment to the PR will signal it
 is allowed to test. The token can be in any comment and in any part of
 the comment.

 A bug blocks merges when it is of critical importance, in the triaged
 or in-progress state, and it is tagged with ci regression. Updating
 the status of a bug to fix committed will remove it from the list of
 blockers.

 It's me, not you, but maybe it should be you.

 I am spending 4 out of 5 days reviewing all the broken test runs
 looking for new evidence to help close the regressions. The
 regressions are mutating. As I am the only person on operations duties
 this week because of vacations, I cannot keep up. Juju developers must
 stop landing branches that compound the regressions.

 As devel has been broken since 2014-06-25, and devel was broken for
 many weeks in June. it is fair to say juju devel has not worked for a
 month and only 2 weeks in the last 2 months. There is little point in
 adding features to devel because I cannot release an alpha with
 regressions.

 I hope with a working devel, or at least a slower moving broken devel,
 the Juju QA Team can write new tests that ensure new juju is
 compatible with old juju so that Ubuntu will it in trusty.



 --
 Curtis Hovey
 Canonical Cloud Development and Operations
 http://launchpad.net/~sinzui

 --
 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: Master has been broken for 4 weeks

[Horacio Duran]

Im on the restore bug

On Wed, Jul 23, 2014 at 12:38 PM, Nate Finch nate.fi...@canonical.com wrote:
 I'm on the nonce.txt bug.


 On Wed, Jul 23, 2014 at 11:34 AM, Curtis Hovey-Canonical
 cur...@canonical.com wrote:

 This is the current list of regressions that block a release

 C:/Juju/lib/juju/nonce.txt does not exist, bootstrap failed in win
 https://bugs.launchpad.net/juju-core/+bug/1342725
 reported 2014-07-16, but is a manifestation of an evolving
 issue from June

 Juju restore fails Could not get lock /var/lib/dpkg/lock
 https://bugs.launchpad.net/juju-core/+bug/1342937
 reported  2014-07-16, but is a manifestation of the brittlity
 of the backup-restore feature whic breaks ever few weeks.

 ec2 changes? rising failure rate in ec2 health checks
 https://bugs.launchpad.net/juju-core/+bug/1345638
 report 2014-07-20. This is very ambiguous. ec2 is
 behaving differently and Juju doesn't handle it well.
 I have been tuning ci and the ec2 config to resolve this,
 but the fact is juju faults.

 Manual provider does not respond after bootstrap
 https://bugs.launchpad.net/juju-core/+bug/1347715
 reported 2014-07-23. Broken by commit d57b76cd

 The QA team is finishing up some work this week. Next week we will
 change the git-merge-juju to demand fixes for ci regressions. I think
 this will need to understand that difference between the master and
 1.20 branches.




 --
 Curtis Hovey
 Canonical Cloud Development and Operations
 http://launchpad.net/~sinzui

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

End Of Review marker

[Horacio Duran]

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

Re: Getting commit emails now - possible?

[Horacio Duran]

This seems to be close to what you want
http://stackoverflow.com/questions/8371173/how-to-get-notified-when-someone-pushes-into-a-github-branch


On Thu, Jun 5, 2014 at 8:43 PM, Tim Penhey tim.pen...@canonical.com wrote:

 Hi All,

 When Juju was on launchpad, I had subscribed to the trunk branch so I
 got an email for each mainline commit.

 This helped me track what was landing without having to read all the
 code reviews.

 Does anyone know if this is possible through github?

 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: Juju is now on Github

[Horacio Duran]

Thanks for the info Ian, you guys have done a wonderful job and have been
very helpful during the day.


On Tue, Jun 3, 2014 at 8:49 PM, Ian Booth ian.bo...@canonical.com wrote:

 Hi folks

 The migration of Juju source from Launchpad to Github is now complete for
 phase
 one. The final location is at https://github.com/juju/juju

 I say phase one because there are sill some follow up tasks to complete.
 You
 will notice that the landing process (essentially the time taken to run the
 tests) is longer. This is because we currently need to spin up an
 ephemeral EC2
 instance rather than using a nailed up instance on Canonistack. We also
 need to
 reduce the parallelism of the tests to get them reliably passing in that
 environment. Addressing these issues is high on the priority list.

 Note: only trunk is moved across to Github. Any work on 1.18.x will still
 need
 to be done via Launchpad.

 One thing you may want to do is redirect Juju project related
 notifications to a
 work email address. Folks may have previously signed up to Github accounts
 with
 personal email addresses. You can go into your profile and add a new email
 address and redirect notifications for the Juju project to prevent spam to
 your
 personal address.

 As a reminder, the new landing workflow is documented in the Contributing
 document https://github.com/juju/juju/blob/master/CONTRIBUTING

 Don't forget, if you have in progress bzr branches, these can be migrated
 across
 using the steps Martin previously sent out.

 snip
 $ cd $GOPATH/src
 $ bzr branches launchpad.net/juju-core
 * trunk
   wip_feature
 $ bzr switch -d launchpad.net/juju-core wip_feature
 $ (cd github.com/juju/jujugit branch)
 * master
 $ (cd github.com/juju/jujugit checkout -b wip_feature)
 $ (cd launchpad.net/juju-corebzr diff -rancestor:co:trunk)|(cd
 github.com/juju/jujupatch  -p0 --merge)

 Then resolve any conflicts, stage and commit.
 snip

 One improvement over the old system is that we now have visibility to how
 our
 landings are progressing. There's a link to the Jenkins landing job in the
 pull
 request email and from there you can see the console output of the test
 run.

 Finally, there are bound to be some rough edges and process improvements
 we can
 make as we all adjust to using this new environment. Please do speak up if
 there
 are issues that need to be addressed.


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