Re: Squelching Leadership messages

[Katherine Cox-Buday]

John A Meinel  writes:

> Note that we should still report leadership changes at INFO level, which 
> should allow you to
> debug easy things without changing the log level, as those changes should 
> happen very
> rarely.

+1, thanks for this!

-- 
Katherine

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

Re: A (Very) Minimal Charm

[Katherine Cox-Buday]

Mark Shuttleworth  writes:

> We are already aligning things like terms and authentication so that
> charms and snaps can be delivered together, though, so perhaps all
> thats required is the ability to give the charm some say in update
> control of snaps.

Interesting, thanks, Mark.

-- 
Katherine

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

Re: A (Very) Minimal Charm

[Katherine Cox-Buday]

Tim Penhey  writes:

> Make sure you also run on LXD with a decent delay to the APT archive.

Open question: is there any reason we shouldn't expect charm authors to take a 
hard-right towards charms with snaps embedded as resources? I know one of our 
long-standing conceptual problems is consistency across units which snaps 
solves nicely.

-- 
Katherine

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

Re: A (Very) Minimal Charm

[Katherine Cox-Buday]

Tim Penhey  writes:

> Make sure you also run on LXD with a decent delay to the APT archive.

Open question: is there any reason we shouldn't expect charm authors to take a 
hard-right towards charms with snaps embedded as resources? I know one of our 
long-standing conceptual problems is consistency across units which snaps 
solves nicely.

-- 
Katherine

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

Re: Dependencies added for new jsonschema support

[Katherine Cox-Buday]

Nate Finch  writes:

> In support of my PR that adds an interactive mode for add-cloud, we needed to 
> add
> jsonschema for the cloud configurations that can be inspected at runtime to 
> generate the
> interactive queries.

Thanks for the great write-up, Nate. I've added it to the tech board agenda[1] 
and we should review tonight.

-- 
Katherine

[1] - 
https://docs.google.com/document/d/13nmOm6ojX5UUNtwfrkqr1cR6eC5XDPtnhN5H6pFLfxo/edit

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

Re: Long tests

[Katherine Cox-Buday]

Nate Finch  writes:

Thanks for highlighting these, Nate!

> Here's some especially bad low hanging fruit (note these are the times
> for single tests, not full suites):

If anyone is so inclined, I have modified the deploy command so that it is unit 
testable, and written some unit tests[1] for it to help guide future 
development; they are 100% in-memory (aside from some suite set up which likely 
doesn't need to be there). If you have some free time (ha!), take one of the 
tests from `DeploySuite` and convert it over to a true in-memory unit test.

[1] - 
https://github.com/juju/juju/blob/staging/cmd/juju/application/deploy_test.go#L1243

-- 
Katherine

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

Re: juju/retry take 2 - looping

[Katherine Cox-Buday]

Tim Penhey  writes:

> Forcing continue/break does not make it like all boring imperative
> loops.

I would like to understand this better.

Here's why I think they're boring:
- They're Go keywords.
- They're present in many other languages and are well understood.
- I see breaks/continues all the time in loops.

In my opinion, it's much easier to understand and support a loop that makes use 
of these keywords than it is to invent a new way to break out of a loop.

Can you elaborate on why do you think these keywords are worse than checking 
for a special error instance?

-- 
Katherine

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

Re: juju/retry take 2 - looping

[Katherine Cox-Buday]

Tim Penhey  writes:

> The rationale behind that is to make the the library handle the 80%
> case easily. The main reason of passing the error into Next is so you
> don't have to do the check and explicit break within the loop.

I will argue here that this goes against a core principle of Go which is to be 
informed and care about your error path.

> Sure, but this could be trivially handled by assigning something to
> err (consider if we made a public error in the retry package for
> this):
>
> var result Foo
> var err error
> for loop := retry.Loop(spec); loop.Next(err); {
>result, err = SomeFunc(blah)
>if err == nil && resultNotGoodEnough(result) {
>  err = retry.ErrTryAgain
>}
> }
> if err != nil {
>// what ever
> }
> // continue using result

I think this is a hint that this is the wrong approach. The edge-cases begin 
showing the cracks in the abstraction and end up making the code more complex. 
Consider your example instead of:

var finalResult Foo
for loop := retry.Loop(spec); loop.Next(); {
result, err := SomeFunc(blah)
if err != nil || resultNotGoodEnough(result) {
continue
}

finalResult = result
break
}

There are no special errors, no mixing of concerns, just a boring imperative 
loop. It works like any other loop written in Go.

-- 
Katherine

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

[Katherine Cox-Buday]

roger peppe  writes:

> I think that review history is crucial for context on historic
> code decisions

I wonder if we could hack a script to save the reviews as git notes, e.g. 
https://github.com/google/git-appraise

With git's ability to rewrite history, I bet this is doable...

-- 
Katherine

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

Re: juju/retry take 2 - looping

[Katherine Cox-Buday]

John Meinel  writes:

> As commented on the pull request, passing 'err' into Next() initially feels 
> weird, but
> it allows a big improvement to whether the loop exited because we ran out of
> retries, or it exited because the request succeeded. (loop.Error()
> tells us either way.)

I don't understand why the retry logic has the concern of why the loop exits 
(i.e. Next(error)).

The motivation of moving towards loops was so that the concern of what's being 
retried is brought back to be inline with the surrounding code. Having the 
retry mechanism inspecting errors doesn't fall in line with that goal.

In my mind, any retry solutions only needs to cover two things:
1. Provide a primitive that will delay a for iteration in a controlled way.
2. Be preemptable.

Everything else is the logic of the thing you're retrying, including why it 
eventually succeeded/failed.

-- 
Katherine

-- 
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 is here!

[Katherine Cox-Buday]

Nicholas Skaggs  writes:

> Juju 2.0 is here!

YES! Time to upgrade my production 1.25 installation :D

Congratulations, everyone.

-- 
Katherine

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

Re: Big memory usage improvements

[Katherine Cox-Buday]

Menno Smits  writes:

> Christian (babbageclunk) has been busy fixing various memory leaks in the Juju
> controllers and has made some significant improvements.

Awesome, good work, Christian!

Not to detract from this fantastic news, but it's still worrisome that an idle 
Juju seems to have a memory which is growing linearly (before picture looked 
like the beginning of an exponential curve?). Do we feel this is memory which 
will at some point be GCed?

-- 
Katherine

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

Re: ANN: Metrics in Juju 2.0

[Katherine Cox-Buday]

Casey Marshall  writes:

> I’m pleased to announce Juju Metrics, new in Juju 2.0!

Casey, this is awesome! Congratulations and well-done to the team!

-- 
Katherine

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

Re: Reviews on Github

[Katherine Cox-Buday]

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 <nate.fi...@canonical.com> 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
> <katherine.cox-bu...@canonical.com> 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 <nate.fi...@canonical.com> writes:
> 
> > In case you missed it, Github rolled out a new review process.
> It
> > basically works just like reviewboard does, where you start a
> review,
> > batch up 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.com/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/mailman/listinfo/juju-dev

Re: Reviews on Github

[Katherine Cox-Buday]

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 reviews. 
>
> I made a little test review on one PR here, and the UX was almost
> exactly like working in reviewboard:
> https://github.com/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/mailman/listinfo/juju-dev

Re: Error while doing bootstrap

[Katherine Cox-Buday]

Hey Rajith,

This sounds like lp:1605714, do you agree? Mick (CCed) is currently 
investigating this as his top priority, so hopefully we'll have a fix soon.

"Rajith P Venkata"  writes:

> Hi
>
> I am installing juju 2.16 on Ubuntu 16.04 power machine: ppc64le.
> While doing bootstrap getting below error: 
>
> 2016-08-30 04:40:24 ERROR cmd supercommand.go:458 creating LXD client:
> Get https://10.12.56.1:8443/1.0:Unable to connect to: 10.12.56.1:8443
> ERROR failed to bootstrap model: subprocess encountered error code 1
>
> Please fix this issue.
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Cell- 9901966577
> Email: rajith...@in.ibm.com

-- 
Katherine

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

Changes coming to CLI deployment messages

[Katherine Cox-Buday]

Hey all,

I want to raise awareness that we're in the process of tightning up
the messages Juju will output when deploying local and charmstore
charms and bundles. I have just landed the first of these changes to
fix lp:1596853[1].

In particular, I want to make sure our QA staff is aware of this
change in case we rely on this output as sentinels to stages in QA
processes.

-- 
Katherine

[1] - https://bugs.launchpad.net/juju/+bug/1596853

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

Re: Let's talk retries

[Katherine Cox-Buday]

roger peppe  writes:
> There's a fourth way that you haven't mentioned, which fits somewhere
> in between 1 and 2 I think (it was the first explicit general retry
> code in Juju AFAIK), which is utils.Attempt.
>
> I'd suggest that the way it's used matches the pattern you'd like to
> write quite well:
>
>  for attempt := strategy.State(); attempt.Next(); { Do something }

Thanks, Roger, I had missed that one. utils.Attempt would be my next 
preference, but it would have to be taught how to be interruptable via channel. 
I also feel that because so much of Go is oriented towards channels, exposing 
the wait via a channel rather than a function makes sense, but I don't 
immediately have a use-case in mind.

>
> AFAIR this pattern was arrived at after some discussion between myself
> and Gustavo. At the time I was thinking of some kind of callback-based
> scheme like the others schemes you mention, but I think that leaving
> the caller in control and the loop explicit is actually nicer - the
> logic is clear to the reader and more composable with other primitives
> (it is also a good match for the pattern you propose).

I strongly agree with this. In my estimation, favoring composability and inline 
code is much clearer and maintainable than piling one abstractions on another.

> How about making AttemptStrategy a little more flexible?

It looks like we've standardized on juju/retry. I don't have the historical 
context in my cache to know why we've rewritten retries 3 times now o.0

-- 
Katherine

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

Change in provisioning functionality

[Katherine Cox-Buday]

Hey All,

I have just landed a fix for lp:1597170 (juju2 beta10 fails to deploy all 
services in aws if storage is not ready), and it may come with some unexpected 
(desirable?) consequences.

In my fix, I found that -- though there is code in place to do so -- we never 
actually retried to provision machines if an error is encountered. This has 
been corrected.

Please keep an eye out for any unintended consequences to either the UX, or 
base functionality, and raise bugs if necessary.

Thanks very much!

-- 
Katherine

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

Re: Let's talk retries

[Katherine Cox-Buday]

Andrew's queue is certainly nice, but I agree with the points Roger is raising:

1. Go's idiom for coordinating concurrent operations are goroutines and 
channels.
2. Sticking to these idioms makes it much easier to compose parts into a whole 
(if only because the language strongly bends code that way).

As a matter of opinion, I also dislike having to instantiate structs to 
encapsulate logic; I would rather write the logic inline, or in a closure -- 
possibly in a goroutine.

William Reade  writes:

> On Tue, Aug 9, 2016 at 10:17 AM, roger peppe
>  wrote:
>
> BTW I'm not saying that a timer queue is never the correct answer.
> In some
> circumstances, it can be the exactly the right thing to use.
> 
>
> Yeah -- the context here is that katco has been looking at the
> provisioner, and I think a timer queue is sensible there. Firing off
> goroutines for every machine is not necessarily bad by any means, but
> it *is* somewhat harder to get right in every circumstance (e.g. what
> happens when a machine is removed while that other goroutine is
> working on provisioning it?).
>
> There are certainly many places where a single retryable op *is* the
> only important thing and there's no call for a control loop. I'm not
> suggesting we should always use a queue; but I'd tend to encourage it
> whenever we have a component dealing with many similar retryable
> tasks. (I definitely should be using it in dependency.Engine, for
> example.)
>
> Cheers
> William
>

-- 
Katherine

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

Let's talk retries

[Katherine Cox-Buday]

Hey All,

We currently have 3 ways we're performing retries in Juju:

1. Archaic, custom, intra-package retry code.
2. github.com/juju/utils::{Countdown,BackoffTimer}
3. github.com/juju/retry (current best practice)

I have just touched some code which fits #1, and when I was attempting to 
retrofit it to #3, I found it a little obtuse. Here's why:

In my case (and I assume most), I wanted something like this:

for range retries { // Loop should break if our parent is cancelled
// Do something
// Success, retry, or fatal error
}

To implement this, I do something like this:

args := retry.CallArgs{
Func: func() error {
// Body of my loop
},
BackoffFunc: func(delay time.Duration, attempt int) time.Duration {
if attempt == 1 {
return delay
}
return delay * factor
},
Stop: dying,
// etc...
}

Call(args)

We attempt to encapsulate every scenario for retries in 
github.com/juju/retry/::CallArgs. We have variables to determine if errors are 
fatal, to notify things, how to back off, etc. This feels very heavy-weight to 
me, and a bit like the monolith model rather than the unix model. I would 
prefer the logic be left to the caller (i.e. do I break out of this loop? do I 
notify something?), and the interface into a retry strategy be much simpler, 
say a channel like in time.Tick(time.Duration) <-chan time.Time.

How would folks feel about something like this?

func BackoffTick(done <-chan struct{}, clock clock.Cock, delay time.Duration, 
factor int64) <-chan time.Time {
signalStream := make(chan time.Time)
go func() {
defer close(signalStream)
for {
select {
case <-done:
return
case signalStream <- time.After(delay):
delay = time.Duration(delay.Nanoseconds() * 
factor)
}
}
}()
return signalStream
}

With this, the above becomes:

for range BackoffTick(dying, myClock, 1*time.Second, 2) {
// Determination of fatality and notifications happen here
}

If you want a max retry concept, you do this:

for range Take(done, 3, BackoffTick(dying, myClock, 1*time.Second, 2)) {
// Determination of fatality and notifications happen here
}

If you want a max duration you do this:

done = Timeout(done, 5*time.Minute)
for range Take(done, 3, BackoffTick(dying, myClock, 1*time.Second, 2)) {
// Determination of fatality and notifications happen here
}

Functionally, what's in juju/retry is fine; and I can stuff anything I want 
into the function. It just feels a little odd to use in that I must put the 
body of my loop in a function, and I dislike that the CallArgs struct attempts 
to encapsulate a bunch of different scenarios.

Thoughts?

Also, is it on the roadmap to address the inconsitant retries throughout Juju? 
I almost used utils.BackoffTimer until I started looking deeper. I'm going to 
submit a PR to flag it as deprecated.

-- 
Katherine

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

Re: Any mentor for adding a new provider available?

[Katherine Cox-Buday]

Hey Patrik,

Have a look at this[1] wiki page and see if it doesn't provide what you need.

We'll make every effort to support you during development it, and we'll want to 
make sure that Wiki page is updated to fill in any gaps you might find.

You might also find the document on contributing[2] helpful as well.

Good luck, and welcome!

[1] - https://github.com/juju/juju/wiki/Implementing-environment-providers
[2] - https://github.com/juju/juju/blob/master/CONTRIBUTING.md

Marco Ceppi  writes:

> Hi Patrik,
>
> This would be a great and welcomed addition. I'm adding the juju-dev
> mailing list to this thread as that is where most the Juju Core
> development happens.
>
> Marco
>
> On Mon, Aug 1, 2016, 6:23 AM Patrik Karisch 
> wrote:
>
> Hi there,
> 
> 
> I want to add DigitalOcean as a new provider to Juju, but as I'm
> not Go experienced and new to the architecture of Juju, I'm
> searching for a mentor who gives me directions on what to do
> first/next and sometimes do code review. Anyone here? :)
> 
> 
> Cheers
> Patrik
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

-- 
Katherine

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

Re: Any mentor for adding a new provider available?

[Katherine Cox-Buday]

Hey Patrik,

Have a look at this[1] wiki page and see if it doesn't provide what you need.

We'll make every effort to support you during development it, and we'll want to 
make sure that Wiki page is updated to fill in any gaps you might find.

You might also find the document on contributing[2] helpful as well.

Good luck, and welcome!

[1] - https://github.com/juju/juju/wiki/Implementing-environment-providers
[2] - https://github.com/juju/juju/blob/master/CONTRIBUTING.md

Marco Ceppi  writes:

> Hi Patrik,
>
> This would be a great and welcomed addition. I'm adding the juju-dev
> mailing list to this thread as that is where most the Juju Core
> development happens.
>
> Marco
>
> On Mon, Aug 1, 2016, 6:23 AM Patrik Karisch 
> wrote:
>
> Hi there,
> 
> 
> I want to add DigitalOcean as a new provider to Juju, but as I'm
> not Go experienced and new to the architecture of Juju, I'm
> searching for a mentor who gives me directions on what to do
> first/next and sometimes do code review. Anyone here? :)
> 
> 
> Cheers
> Patrik
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

-- 
Katherine

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

Re: Schema for Juju RPC messages

[Katherine Cox-Buday]

Mark Shuttleworth <m...@ubuntu.com> writes:

> On 27/07/16 19:43, Reed O'Brien wrote:
>
> +1
> 
> 
> On Wed, Jul 27, 2016 at 9:52 AM, Katherine Cox-Buday
> <katherine.cox-bu...@canonical.com> wrote:
> 
> 
> I am a huge fan of publishing schema's and then generating
> SDKs and documentation websites off of them. It brings your
> API closer to language agnostic, removes the burden on us
> having to hand-craft both our API client and our documentation
> site, and makes validation implicit. I'm not up on what the
> best tools for doing this are, but Swagger[1] seems to be
> popular.
>
> Schemas are excellent for test suites and tool validation, but
> auto-generated bindings are *always* ugly. Please don't make that
> plan A for any language you care about. From a house perspective, Go,
> JS and Python need designed and human-curated bindings that are
> idiomatic for coders who love those languages.
>
> Mark
>

Good point, Mark. I agree that it's difficult to make an auto-generated client 
idiomatic/nice to use. What I like to do is use the schema to auto-generate the 
boilerplate, and then wrap that with a small shim that is more crisp.

Do you have an opinion on this approach?

-- 
Katherine

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

Re: Schema for Juju RPC messages

[Katherine Cox-Buday]

I am a huge fan of publishing schema's and then generating SDKs and 
documentation websites off of them. It brings your API closer to language 
agnostic, removes the burden on us having to hand-craft both our API client and 
our documentation site, and makes validation implicit. I'm not up on what the 
best tools for doing this are, but Swagger[1] seems to be popular.

[1] - http://swagger.io/

John A Meinel  writes:

> We've had some requests from people trying to drive Juju that it would
> actually be really nice if we were stricter with the messages that we
> accept on our API. Specifically, as we've changed the API methods,
> they had several hard-to-debug problems because they were passing a
> parameter that was named incorrectly, and Juju was not giving them any
> indication that something was wrong.
>
> I put together a (very hackish) test branch, to see if I could use
> JSONSchema to define our request and response messages, and give nicer
> error messages (rather than silent acceptance). As I was working with
> JSON, I realized the extra " and { characters really got in the way of
> making a document that was readable, so I leveraged our existing YAML
> to JSON conversion mechanisms to write the description in YAML and
> then load the object tree into JSONSchema to validate our requests.
>
> I did end up getting basic validation of the outer structure (just the
> Request/Response message, not the contents of Parameters) functioning
> here:
> https://github.com/jameinel/juju/blob/yaml-schema-rpc/rpc/jsoncodec/codec.go
> You can see what some of the error messages look like here:
> https://github.com/jameinel/juju/blob/yaml-schema-rpc/rpc/jsoncodec/codec_test.go
>
> The actual code itself isn't useful as is, because it needs to have
> the schema validation stuff pulled out into its own file, etc. But it
> does give a proof-of-concept of basic message validation. I'm not
> super excited by some of the error messages
> (gojsonschema.ResultError.Description is very nice by itself for
> missing keys, extra properties, etc, but not enough information for
> invalid values, while ResultError.String() is overly verbose in the
> opposite way.)
>
> I'd like to get a bit of feedback on whether people would find this
> interesting, especially if we brought that all the way into the Param
> structs as well. I haven't done any benchmarking to determine if this
> is a large overhead or not. But the golfing community seems determined
> to not do a Strict Unmarshal function, and seems to be recommending
> using a Schema instead.
>
> I'm not completely sold either way, though I do find the YAML format
> for the schema description to be far more human readable than the JSON
> format.
>
> Thoughts?
>
> John
> =:->

-- 
Katherine

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

Re: Small script to connect to Juju's mongo in LXD

[Katherine Cox-Buday]

It's in the pastebin I linked.

But yes, I find it extremely useful for debugging. I could see how having it 
handy at client sites would be super useful.

John Meinel <j...@arbash-meinel.com> writes:

> Did you intend to attach the script to the email? It does sound like
> something useful. I know when we were investigating at some client
> sites we had a small snippet of a bash function to dig the content out
> of agent.conf and launch mongo with the right options. It would be
> nice to have that in a more official place so it doesn't get
> forgotten.
>
> John
> =:->
>
> On Wed, Jul 27, 2016 at 6:19 PM, Katherine Cox-Buday
> <katherine.cox-bu...@canonical.com> wrote:
>
> I frequently need to connect to Juju's Mongo instance to poke
> around and see if something I've done is having the desired
> effect. Back when we were using LXC, I had a script that would
> pull the password from agent.conf and open a shell. When we
> switched to LXD my script broke, and I never updated it. I finally
> got frustrated enough to modify[1] it, and thought others might
> find this useful for poking around Mongo.
> 
> Let me know if you have any suggestions.
> 
> --
> Katherine
> 
> [1] - http://pastebin.ubuntu.com/21155985/
> 
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
>
>

-- 
Katherine

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

Small script to connect to Juju's mongo in LXD

[Katherine Cox-Buday]

I frequently need to connect to Juju's Mongo instance to poke around and see if 
something I've done is having the desired effect. Back when we were using LXC, 
I had a script that would pull the password from agent.conf and open a shell. 
When we switched to LXD my script broke, and I never updated it. I finally got 
frustrated enough to modify[1] it, and thought others might find this useful 
for poking around Mongo.

Let me know if you have any suggestions.

-- 
Katherine

[1] - http://pastebin.ubuntu.com/21155985/

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

Re: grabbing resources when deploying via api Application.Deploy

[Katherine Cox-Buday]

So just to follow up on our conversation in IRC:

- You do need to upload resource metadata prior to deploying a charm. You can 
do so via the "resources" facade, version 1. Call "AddPendingResources".
- This will give you a list of IDs back; associate these in a map of 
resource-name -> id, and include those in the deploy request.

Hope this helps anyone else trying to use the resources feature programatically.

Adam Stokes  writes:

> I've noticed a difference between calling:
>
> juju deploy cs:~containers/trusty/etcd-3
>
> And using the API:
>
> Application.Deploy({'applications': [{'constraints': {},
> 'application': 'etcd', 'num-units': 3, 'charm-url':
> 'cs:~containers/trusty/etcd-3'}]})
>
> Using the juju client it'll automatically pull down the resources
> associated with it in the charmstore. Using the API call will not.
>
> Question is if this is intended? Do I need to pass something to my
> Deploy call to grab those resources as well?

-- 
Katherine

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

Re: Cleansing Mongo data

[Katherine Cox-Buday]

As I have only just discovered the need to cleanse mongo data, I can't say for 
sure, but it looks like we may have been cleansing things in the parts of Juju 
that need it. William may know more.

If not, I imagine a small upgrade step would make short work of any problems.

roger peppe <roger.pe...@canonical.com> writes:

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

-- 
Katherine

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

Re: Cleansing Mongo data

[Katherine Cox-Buday]

Thanks Menno, I'll get that docstring corrected!

I'm not sure it needs to be in its own package. I put it there because the 
taxonomy made sense in my head, and I get the impression that we have built up 
a lot of utility-like functions for Mongo over time, but YAGNI may apply here.

I don't plan on moving this over (mostly due to time constraints), but I would 
not be opposed if someone wanted to. It might be helpful to inventory other 
utility-like functionality first.

Menno Smits <menno.sm...@canonical.com> writes:

> Thanks, this is really useful - especially when writing data into the
> database that comes sources that the code doing the writing doesn't
> have control over.
>
> Two little things:
>
> 1. The docstring for EscapeKeys still mentions statusDoc. 
> 2. Are you sure this needs to be in it's own package, especially one
> called "utils"? Given we already have the widely used
> github.com/juju/utils - as well as others with that name under
> juju/juju - this one is predestined to be aliased everywhere it's
> imported. Couldn't these escaping functions just live in their own
> file in github.com/juju/juju/mongo? Even when the import isn't
> aliased, the intent of "mongo.EscapeKeys(...)" is clearer than
> "utils.EscapeKeys(...)".
>
> - Menno
>
> On 24 June 2016 at 08:09, Katherine Cox-Buday
> <katherine.cox-bu...@canonical.com> wrote:
>
> Hey all,
> 
> 
> William gave me a good review and it came up that I wasn't
> cleansing some of the data being placed in Mongo. I wasn't aware
> this had to be done, and after talking to a few other folks it
> became apparent that maybe not many people know we should be doing
> this.
> 
> 
> At any rate, William also pointed me to some existing code which
> did this. I've pulled it out into the mongo/utils package for
> general consumption. The comments do a pretty good job of
> elucidating why this is necessary.
> 
> 
> https://github.com/juju/juju/blob/master/mongo/utils/data_cleansing.go
>
> 
> 
> 
> -
> Katherine
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
>
>

-- 
Katherine

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

Cleansing Mongo data

[Katherine Cox-Buday]

Hey all,

William gave me a good review and it came up that I wasn't cleansing some
of the data being placed in Mongo. I wasn't aware this had to be done, and
after talking to a few other folks it became apparent that maybe not many
people know we should be doing this.

At any rate, William also pointed me to some existing code which did this.
I've pulled it out into the mongo/utils package for general consumption.
The comments do a pretty good job of elucidating why this is necessary.

https://github.com/juju/juju/blob/master/mongo/utils/data_cleansing.go

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

Re: Regarding Synnefo environment provider for Juju

[Katherine Cox-Buday]

Hey Thodoris,

Congratulations on beginning your provider! :)

Do you have your code visible anywhere? It would help with diagnosing any 
issues.

-
Katherine

Thodoris Sotiropoulos  writes:

> Hi all,
>
> You may remember previous e-mails sent by my partner Stavros
> Sachtouris regarding the case of implementing a Juju environment
> provider for our open source IaaS called Synnefo.
>
> We have started implementation of the basics (configuration schema,
> instance creation, instance queries, preparation of environment,
> etc). Our goal is to make a proof of concept implementation of the
> bootstrap command and that's why we have ignored networking and
> storage configuration, a.k.a mocked.
>
> So far, we have managed to create and communicate with a machine
> instance. However, during the last step of bootstrap process
> (insertion of the admin model to database) we are facing an unexpected
> problem (method `NewModel` of `state/model.go`).
>
> Here is the corresponding log file:
> https://pithos.okeanos.grnet.gr/public/8EHM5jpEm2W7bSwly9wFG
>
> I tried to investigate the problem but I cannot figure out why I get
> the `model %s for %q already exists`. What am I missing? I would
> appreciate any help or guidance.»
>
> Thank you in advance
>
> Thodoris Sotiropoulos Developer @ GRNET theo...@grnet.gr

-- 
Katherine

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

Re: Juju support for Synnefo

[Katherine Cox-Buday]

Hey Stavros, welcome!

We have a Wiki page[1] up on contributing new providers to Juju. If you find 
yourself stuck, please reach out to the list so we can continue to improve this 
page.

[1] https://github.com/juju/juju/wiki/Implementing-environment-providers

Kindest Regards,
Katherine

Stavros Sachtouris  writes:

> Hello,
>
> I am currently investigating ways for utilizing Juju on our own IaaS
> software (*), with the intention of suggesting it as the de facto PaaS
> layer.
>
> We have already considered using external CLI scripts for provisioning
> and scaling. This approach seems to work, but it limits the
> utilization of Juju features (e.g., you cannot scale from UI). What we
> really need is a provider with full support for Synnefo.
>
> We already had a glimpse in Juju code, trying to familiarize ourselves
> with the code, but we would appreciate any guidance on how to develop
> complete providers for Juju. Where do we get started? Are there any
> "developer Guides" or other documents? What is your policy on provider
> extensions?
>
> Thank you in advance
>
> Stavros Sachtouris
> Developer @ GRNET
> saxto...@grnet.gr
>
> (*) It is called Synnefo ( synnefo.org ) and is an opensource IaaS
> developed by the Greek Research Network of Technology (GRNET). It
> powers ~okeanos ( okeanos.grnet.gr ), a large IaaS providing resources
> to the Greek and other European academic communities. Synnefo is
> OpenStack compatible (in theory...)

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

Re: The mean time for a CI run has risen to 33 minutes

[Katherine Cox-Buday]

Not sure if this is the isolation problem you're speaking of, but if so, it's 
been fixed.

https://launchpad.net/bugs/1564511

Martin Packman  writes:

> On 16/05/2016, David Cheney  wrote:
>> This got significantly worse in the last 6 weeks. What happened ?
>
> Either the juju tests are slower, or trusty on aws is slower. It's a
> fresh cloud instance each run, and still trusty because we switched to
> xenial and the lxd tests failed due to lack of isolation. Could change
> back to xenial now Curtis added some lxd setup support the the
> makefile I think, but that is unlikely to help speed at all.
>
> Martin

-- 
Katherine

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

Re: adding unit tests that take a long time

[Katherine Cox-Buday]

On 04/27/2016 09:51 PM, Nate Finch wrote:
> So, this is exactly why I didn't want to mention the nature of the
> test, because we'd get sidetracked. I'll make another thread to talk
> about that specific test.
>
> I do still want to talk about what we can do for unit tests that take
> a long time.  I think giving developers the option to skip long tests
> is handy - getting a reasonable amount of coverage when you're in the
> middle of the develop/test/fix cycle.  It would be really useful for
> when you're making changes that affect a lot of packages and so you
> end up having to run full tests over and over.  Of course, running
> just the short tests would not give you 100% confidence, but once
> you've fixed everything so the short tests pass, *then* you could do a
> long run for thorough coverage.

I believe Cheryl has something like this in the works and will be
sending a note out on it soon.

> This is a very low friction way to increase developer productivity,
> and something we can implement incrementally.  It can also lead to
> better test coverage over all.  If you write 10 unit tests that
> complete in milliseconds, but were thinking about writing a couple
> longer-running unit tests that make sure things are working
> end-to-end, you don't have the disincentive of "well, this will make
> everyone's full test runs 30 seconds longer", since you can always
> skip them with -short.
>
> The only real negative I see is that it makes it less painful to write
> long tests for no reason, which would still affect landing times
> but hopefully everyone is still aware of the impact of long-running
> tests, and will avoid them whenever possible.

I will gently point out that we were prepared to land a test that takes
~17s to run without discussion. The motivations are honest and good, but
how many others think the same? This is how our test suite grows to be
unmanageable.

I also agree with Andrew that the nature of the test should be the
delineating factor. Right now we tend to view everything through the
lens of the Go testing suite; it's a hammer, and everything is a nail.
Moving forward, I think we should try much harder to delineate between
the different types of tests in the so-called test pyramid,
 place like tests with
like tests, and then run classes of tests when and where they're most
appropriate.

This is definitely static analysis and should be run in the same stage
as other static analysis tools.

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

Re: adding unit tests that take a long time

[Katherine Cox-Buday]

On 04/27/2016 09:51 PM, Nate Finch wrote:
> So, this is exactly why I didn't want to mention the nature of the
> test, because we'd get sidetracked. I'll make another thread to talk
> about that specific test.
>
> I do still want to talk about what we can do for unit tests that take
> a long time.  I think giving developers the option to skip long tests
> is handy - getting a reasonable amount of coverage when you're in the
> middle of the develop/test/fix cycle.  It would be really useful for
> when you're making changes that affect a lot of packages and so you
> end up having to run full tests over and over.  Of course, running
> just the short tests would not give you 100% confidence, but once
> you've fixed everything so the short tests pass, *then* you could do a
> long run for thorough coverage.

I believe Cheryl has something like this in the works and will be
sending a note out on it soon.

> This is a very low friction way to increase developer productivity,
> and something we can implement incrementally.  It can also lead to
> better test coverage over all.  If you write 10 unit tests that
> complete in milliseconds, but were thinking about writing a couple
> longer-running unit tests that make sure things are working
> end-to-end, you don't have the disincentive of "well, this will make
> everyone's full test runs 30 seconds longer", since you can always
> skip them with -short.
>
> The only real negative I see is that it makes it less painful to write
> long tests for no reason, which would still affect landing times
> but hopefully everyone is still aware of the impact of long-running
> tests, and will avoid them whenever possible.

I will gently point out that we were prepared to land a test that takes
~17s to run without discussion. The motivations are honest and good, but
how many others think the same? This is how our test suite grows to be
unmanageable.

I also agree with Andrew that the nature of the test should be the
delineating factor. Right now we tend to view everything through the
lens of the Go testing suite; it's a hammer, and everything is a nail.
Moving forward, I think we should try much harder to delineate between
the different types of tests in the so-called test pyramid,
 place like tests with
like tests, and then run classes of tests when and where they're most
appropriate.

This is definitely static analysis and should be run in the same stage
as other static analysis tools.

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

Re: adding unit tests that take a long time

[Katherine Cox-Buday]

That is an awesome idea! +1

On 04/27/2016 05:51 PM, Andrew Wilkins wrote:
> On Thu, Apr 28, 2016 at 1:44 AM Nate Finch  > wrote:
>
> I was actually trying to avoid talking about the test itself to
> keep things shorter ;)  
>
> The test is parsing the entire codebase under github.com/juju/juju
>  to look for places where we're
> creating a new value of crypto/tls.Config instead of using the new
> helper function that I wrote that creates one with more secure
> defaults.  There's not really any getting around the fact that
> parsing the whole tree takes a long time.
>
>
> The nature of the test is important here: it's not a test of Juju
> functionality, but a test to ensure that we don't accidentally use a
> TLS configuration that doesn't match our project-wide constraints.
> It's static analysis, using the test framework; and FWIW, the sort of
> thing that Lingo would be a good fit for.
>
> I'd suggest that we *do* organise things like this separately, and run
> them as part of the "scripts/verify.sh" script. This is the sort of
> test that you shouldn't need to run often, but I'd like us to gate
> merges on.
>
> Cheers,
> Andrew
>  
>
> On Wed, Apr 27, 2016 at 1:25 PM Nicholas Skaggs
>  > wrote:
>
> This is a timely discussion Nate. I'll avoid saying too much
> off the
> top, but I do have a question.
>
> On 04/27/2016 12:24 PM, Nate Finch wrote:
> > I just wrote a test that takes ~16.5 seconds on my machine.
> Why does the test take so long? Are you intending it to be a
> short /
> small scoped test?
>
> Nicholas
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>

-- 
-
Katherine

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

Re: Go 1.6 is now in trusty-proposed

[Katherine Cox-Buday]

Totally agreed: 2.0 is obviously the priority. I didn't think anyone was
talking about a short-term pivot.

On 03/28/2016 10:34 AM, Cheryl Jennings wrote:
> Addressing flaky tests is definitely a long term goal we should have.
>
> Given that we are aiming for beta4 next week, I'd rather our energies
> in the short term are directed at fixing stakeholder bugs than fixing
> intermittent failures that prevent us from releasing because we are no
> longer retrying tests.
>
> On Mon, Mar 28, 2016 at 10:27 AM, Katherine Cox-Buday
> <katherine.cox-bu...@canonical.com
> <mailto:katherine.cox-bu...@canonical.com>> wrote:
>
> While agreeing with the spirit of your email, Cheryl, I'd like to
> opine that in the long-term fixing flaky tests will improve the
> code and help to fix (and prevent!) bugs.
>
> Put another way, flaky tests are indirectly causing pain for our
> users.
>
>
> On 03/28/2016 10:24 AM, Cheryl Jennings wrote:
>> These intermittently failing unit tests are often due to
>> unreliable unit tests, rather than problems in the code.  As nice
>> as it would be to not have to retry tests (particularly unit
>> tests), I'd much rather we spend our precious resources on fixing
>> bugs that are causing pain for our users.  
>>
>> There are currently 168 Triaged bugs targeted against 2.0-beta4
>> [0], many of which have been reported by actual users and have
>> been deferred release after release.  For comparison, there are
>> 18 go 1.5 /1.6 bugs found by CI.
>>
>> Thanks,
>> -Cheryl
>>
>> [0] https://launchpad.net/juju-core/+milestone/2.0-beta4
>>
>> On Mon, Mar 28, 2016 at 9:08 AM, Nate Finch
>> <nate.fi...@canonical.com <mailto:nate.fi...@canonical.com>> wrote:
>>
>> +1, don't retry... devs need to feel the pain in order to get
>> proper motivation to fix this stuff...
>>
>> On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday
>> <katherine.cox-bu...@canonical.com
>> <mailto:katherine.cox-bu...@canonical.com>> wrote:
>>
>> Just wanted to say thank you 100x to all involved!
>>
>> On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
>> > Hi,
>> >
>> > As of a few minutes ago, there is now a golang-1.6
>> package in
>> > trusty-proposed:
>> > https://launchpad.net/ubuntu/trusty/+source/golang-1.6
>> (thanks for the
>> > review and copy, Steve).
>> >
>> > One difference between this and the package I prepared
>> earlier is that
>> > it does not install /usr/bin/go but rather
>> /usr/lib/go-1.6/bin/go so
>> > Makefiles and such will need to be adjusted to invoke
>> that directly or
>> > put /usr/lib/go-1.6/bin on $PATH or whatever. (This
>> also means it can
>> > be installed alongside the golang packages that are
>> already in
>> > trusty).
>> >
>> > Cheers,
>> > mwh
>> > (Hoping that we can now really properly ignore
>> gccgo-4.9 ppc64el bugs!)
>> >
>> > On 17 February 2016 at 07:58, Michael Hudson-Doyle
>> > <michael.hud...@canonical.com
>> <mailto:michael.hud...@canonical.com>> wrote:
>> >> I have approval for the idea but also decided to wait
>> for 1.6 and upload
>> >> that instead. I'm also on leave currently so hopefully
>> this can all happen
>> >> in early March.
>> >>
>> >> Cheers,
>> >> mwh
>> >>
>> >> On 17/02/2016 1:17 am, "John Meinel"
>> <j...@arbash-meinel.com <mailto:j...@arbash-meinel.com>>
>> wrote:
>> >>> To start with, thanks for working on this. However,
>> doesn't this also
>> >>> require changing the CI builds to use your ppa?
>> >>>
>> >>> What is the current state of this? I was just looking
>> around and noticed
>> >>> golang1.5-go isn't in anyt

Re: Go 1.6 is now in trusty-proposed

[Katherine Cox-Buday]

While agreeing with the spirit of your email, Cheryl, I'd like to opine
that in the long-term fixing flaky tests will improve the code and help
to fix (and prevent!) bugs.

Put another way, flaky tests are indirectly causing pain for our users.

On 03/28/2016 10:24 AM, Cheryl Jennings wrote:
> These intermittently failing unit tests are often due to unreliable
> unit tests, rather than problems in the code.  As nice as it would be
> to not have to retry tests (particularly unit tests), I'd much rather
> we spend our precious resources on fixing bugs that are causing pain
> for our users.  
>
> There are currently 168 Triaged bugs targeted against 2.0-beta4 [0],
> many of which have been reported by actual users and have been
> deferred release after release.  For comparison, there are 18 go 1.5
> /1.6 bugs found by CI.
>
> Thanks,
> -Cheryl
>
> [0] https://launchpad.net/juju-core/+milestone/2.0-beta4
>
> On Mon, Mar 28, 2016 at 9:08 AM, Nate Finch <nate.fi...@canonical.com
> <mailto:nate.fi...@canonical.com>> wrote:
>
> +1, don't retry... devs need to feel the pain in order to get
> proper motivation to fix this stuff...
>
> On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday
> <katherine.cox-bu...@canonical.com
> <mailto:katherine.cox-bu...@canonical.com>> wrote:
>
> Just wanted to say thank you 100x to all involved!
>
> On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
> > Hi,
> >
> > As of a few minutes ago, there is now a golang-1.6 package in
> > trusty-proposed:
> > https://launchpad.net/ubuntu/trusty/+source/golang-1.6
> (thanks for the
> > review and copy, Steve).
> >
> > One difference between this and the package I prepared
> earlier is that
> > it does not install /usr/bin/go but rather
> /usr/lib/go-1.6/bin/go so
> > Makefiles and such will need to be adjusted to invoke that
> directly or
> > put /usr/lib/go-1.6/bin on $PATH or whatever. (This also
> means it can
> > be installed alongside the golang packages that are already in
> > trusty).
> >
> > Cheers,
> > mwh
> > (Hoping that we can now really properly ignore gccgo-4.9
> ppc64el bugs!)
> >
> > On 17 February 2016 at 07:58, Michael Hudson-Doyle
> > <michael.hud...@canonical.com
> <mailto:michael.hud...@canonical.com>> wrote:
> >> I have approval for the idea but also decided to wait for
> 1.6 and upload
> >> that instead. I'm also on leave currently so hopefully this
> can all happen
> >> in early March.
> >>
> >> Cheers,
> >> mwh
> >>
> >> On 17/02/2016 1:17 am, "John Meinel"
> <j...@arbash-meinel.com <mailto:j...@arbash-meinel.com>> wrote:
> >>> To start with, thanks for working on this. However,
> doesn't this also
> >>> require changing the CI builds to use your ppa?
> >>>
> >>> What is the current state of this? I was just looking
> around and noticed
> >>> golang1.5-go isn't in anything specific for Trusty that I
> can see. I realize
> >>> if its going into an SRU it requires a fair amount of
> negotiation with other
> >>> teams, so I'm not  surprised to see it take a while. I
> just wanted to check
> >>> how it was going.
> >>>
> >>> Thanks,
> >>>
> >>> John
> >>> =:->
> >>>
> >>> On Mon, Jan 18, 2016 at 7:32 AM, Michael Hudson-Doyle
> >>> <michael.hud...@canonical.com
> <mailto:michael.hud...@canonical.com>> wrote:
> >>>> Hi all,
> >>>>
> >>>> As part of the plan for getting Go 1.5 into trusty (see here
> >>>> https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty)
> I've built
> >>>> packages (called golang1.5-go rather than golang-go) for
> trusty in my
> >>>> ppa:
> >>>>
> >>>>
> https://launchpad.net/~mwhudson/+archive/ubuntu/go15-trusty/+packages
> 
> <https://launchpad.net/%7E

Re: Go 1.6 is now in trusty-proposed

[Katherine Cox-Buday]

Just wanted to say thank you 100x to all involved!

On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
> Hi,
>
> As of a few minutes ago, there is now a golang-1.6 package in
> trusty-proposed:
> https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the
> review and copy, Steve).
>
> One difference between this and the package I prepared earlier is that
> it does not install /usr/bin/go but rather /usr/lib/go-1.6/bin/go so
> Makefiles and such will need to be adjusted to invoke that directly or
> put /usr/lib/go-1.6/bin on $PATH or whatever. (This also means it can
> be installed alongside the golang packages that are already in
> trusty).
>
> Cheers,
> mwh
> (Hoping that we can now really properly ignore gccgo-4.9 ppc64el bugs!)
>
> On 17 February 2016 at 07:58, Michael Hudson-Doyle
>  wrote:
>> I have approval for the idea but also decided to wait for 1.6 and upload
>> that instead. I'm also on leave currently so hopefully this can all happen
>> in early March.
>>
>> Cheers,
>> mwh
>>
>> On 17/02/2016 1:17 am, "John Meinel"  wrote:
>>> To start with, thanks for working on this. However, doesn't this also
>>> require changing the CI builds to use your ppa?
>>>
>>> What is the current state of this? I was just looking around and noticed
>>> golang1.5-go isn't in anything specific for Trusty that I can see. I realize
>>> if its going into an SRU it requires a fair amount of negotiation with other
>>> teams, so I'm not  surprised to see it take a while. I just wanted to check
>>> how it was going.
>>>
>>> Thanks,
>>>
>>> John
>>> =:->
>>>
>>> On Mon, Jan 18, 2016 at 7:32 AM, Michael Hudson-Doyle
>>>  wrote:
 Hi all,

 As part of the plan for getting Go 1.5 into trusty (see here
 https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty) I've built
 packages (called golang1.5-go rather than golang-go) for trusty in my
 ppa:

 https://launchpad.net/~mwhudson/+archive/ubuntu/go15-trusty/+packages

 (assuming 3:1.5.3-0ubuntu4 actually builds... I seem to be having a
 "make stupid packaging mistakes" day)

 I'll write up a SRU bug to start the process of getting this into
 trusty tomorrow but before it does end up in trusty it would seem like
 a good idea to run the CI tests using juju-core packages built with
 this version of the go compiler. Is that something that's feasible to
 arrange

 The only packaging requirement should be to change the build-depends
 to be on golang1.5-go rather than golang-go or gccgo.

 Cheers,
 mwh

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

-- 
-
Katherine


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

Re: Go 1.6 is now in trusty-proposed

[Katherine Cox-Buday]

Generally +1 on this, but I'm also intrigued by Martin's statistic... do
we currently weight test failures by how likely they are to fail (i.e.
how likely they are flaky)? That seems like it would be a great metric
to use to decide which to fix first.

On 03/28/2016 01:29 AM, David Cheney wrote:
> I know if we didn't retry constantly, the Juju tests'd never pass. But
> by retrying, there is no impetus to fix them.
>
> How about we stop retrying flaky tests? The blocked build get's the grease.
>
> On Mon, Mar 28, 2016 at 5:23 PM, Martin Packman
>  wrote:
>> On 27/03/2016, David Cheney  wrote:
>>> Hi Martin,
>>>
>>> I was told that the Go 1.6 tests were voting, so these bugs should be
>>> blocking bugs. Is this not the case ?
>> The tests are voting, and giving blesses, so no blocking bugs, but a
>> lot of the remaining issues are low-occurrence failures. Basically the
>> unit tests pass generally given the three attempts, but overall fail a
>> lot from a number of issues that all happen only occasionally.
>>
>> For instance, bug 1553292:
>>
>> 
>>
>> This is maybe ~5% chance of failing, but given the number of jobs now
>> using go 1.5+ that's still six failures in the last week.
>>
>> We have enough issues like this that CI spends a lot more time
>> retesting on go 1.6 than we do on go 1.2 with the same unit tests.
>>
>> Martin

-- 
-
Katherine


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

Re: Units & resources: are units homogeneous?

[Katherine Cox-Buday]

Thanks, Adam.

Playing devil's advocate to my own question here: why isn't this 1 charm 
broken up into separate charms that handle the different bits of the 
workflow? It sounds like you'd want to break this up into different 
charms along lines of modeled responsibility and then deploy using bundles?


Sorry if I'm over-simplifying.

-
Katherine

On 02/16/2016 12:35 PM, Adam Collard wrote:

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday 
<katherine.cox-bu...@canonical.com 
<mailto:katherine.cox-bu...@canonical.com>> wrote:


The team is looking closely at some of our CLI surrounding
resources, and an interesting question came up: should units be
considered homogeneous?

My understanding is that it's a goal to make the management of
units more consistent, and making the units more homogeneous would
support this, but I'm wondering from a workload perspective if
this is also true? One example I could think of to support the
discussion is a unit being elected leader and thus taking a
different path through it's workflow than the other units. When it
comes to resources, maybe this means it pulls a different sub-set
of the declared resources, or maybe doesn't pull resources at all
(e.g. it's coordinating the rest of the units or something).


Yes, as a concrete example the Landscape charm[0], does just that and 
runs different Landscape services on different units, using the leader 
to decide what goes where. The units are heterogeneous and under the 
control of the charm.


Cheers,

Adam
[0] https://jujucharms.com/landscape-server/trusty/


--
-
Katherine

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

Re: Units & resources: are units homogeneous?

[Katherine Cox-Buday]

Thanks, Adam.

Playing devil's advocate to my own question here: why isn't this 1 charm 
broken up into separate charms that handle the different bits of the 
workflow? It sounds like you'd want to break this up into different 
charms along lines of modeled responsibility and then deploy using bundles?


Sorry if I'm over-simplifying.

-
Katherine

On 02/16/2016 12:35 PM, Adam Collard wrote:

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday 
<katherine.cox-bu...@canonical.com 
<mailto:katherine.cox-bu...@canonical.com>> wrote:


The team is looking closely at some of our CLI surrounding
resources, and an interesting question came up: should units be
considered homogeneous?

My understanding is that it's a goal to make the management of
units more consistent, and making the units more homogeneous would
support this, but I'm wondering from a workload perspective if
this is also true? One example I could think of to support the
discussion is a unit being elected leader and thus taking a
different path through it's workflow than the other units. When it
comes to resources, maybe this means it pulls a different sub-set
of the declared resources, or maybe doesn't pull resources at all
(e.g. it's coordinating the rest of the units or something).


Yes, as a concrete example the Landscape charm[0], does just that and 
runs different Landscape services on different units, using the leader 
to decide what goes where. The units are heterogeneous and under the 
control of the charm.


Cheers,

Adam
[0] https://jujucharms.com/landscape-server/trusty/


--
-
Katherine

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

Units & resources: are units homogeneous?

[Katherine Cox-Buday]

Hey All,

The team is looking closely at some of our CLI surrounding resources, 
and an interesting question came up: should units be considered homogeneous?


My understanding is that it's a goal to make the management of units 
more consistent, and making the units more homogeneous would support 
this, but I'm wondering from a workload perspective if this is also 
true? One example I could think of to support the discussion is a unit 
being elected leader and thus taking a different path through it's 
workflow than the other units. When it comes to resources, maybe this 
means it pulls a different sub-set of the declared resources, or maybe 
doesn't pull resources at all (e.g. it's coordinating the rest of the 
units or something).


I'm curious what people are seeing out in the field, and hearing 
opinions too.


Thanks :)

 
-

Katherine

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

Re: Introducing, juju resources!

[Katherine Cox-Buday]

Hey Gabbey!

On 02/12/2016 03:57 PM, Gabriel Samfira wrote:

Is there a limit on the filesize I can upload?

Not to my knowledge; they are streamed to the controller.
What happens if multiple users try to upload the same file (does it 
get stored twice, or does juju just increment a reference counter)?
For the moment, the bytes will always be uploaded so that it can 
calculate a fingerprint. If the fingerprint is the same, it won't store 
a new copy. I'm not sure if it will consider the duped version a new 
revision or not; I'll have to check on that.


Do I need to attach more storage to the controller if I need to upload 
a bunch of ISO files (3-4 ISO files of about 3 GB each)? On openstack, 
the default is a small instance with 20 GB of disk space.
We're storing it in Juju's blobstore which has deduping, so I believe 
you'll need some amount less than the sum of the size of all your files. 
But yes, ultimately it's cached on the controller so you'll want to bump 
the size of that up if you're planning on storing lots of resources.

Thanks for this great feature!

And thanks for the great questions :)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Introducing, juju resources!

[Katherine Cox-Buday]

Hey Gabbey!

On 02/12/2016 03:57 PM, Gabriel Samfira wrote:

Is there a limit on the filesize I can upload?

Not to my knowledge; they are streamed to the controller.
What happens if multiple users try to upload the same file (does it 
get stored twice, or does juju just increment a reference counter)?
For the moment, the bytes will always be uploaded so that it can 
calculate a fingerprint. If the fingerprint is the same, it won't store 
a new copy. I'm not sure if it will consider the duped version a new 
revision or not; I'll have to check on that.


Do I need to attach more storage to the controller if I need to upload 
a bunch of ISO files (3-4 ISO files of about 3 GB each)? On openstack, 
the default is a small instance with 20 GB of disk space.
We're storing it in Juju's blobstore which has deduping, so I believe 
you'll need some amount less than the sum of the size of all your files. 
But yes, ultimately it's cached on the controller so you'll want to bump 
the size of that up if you're planning on storing lots of resources.

Thanks for this great feature!

And thanks for the great questions :)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Copyright headers for auto-generated files?

[Katherine Cox-Buday]

Nate ran into an interesting problem yesterday. If we begin to use go 
generate directives to auto-generate code, do we care that this code 
doesn't have a Copyright header? We check the generated file into source 
control, but as the file is meant to be regenerated in the event of a 
change, we don't want to edit it by hand to add the header.


--
-
Katherine


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

Comprehensive reviews & when to do them?

[Katherine Cox-Buday]

Hey All,

I think we have a mis-alignment in how we currently do reviews and 
feature branches.


We've switched over to feature-branches which is great and has allowed 
Moonstone to land "good enough" code into our feature branch to support 
a bi-weekly demo and solicit feedback. At the same time, I feel like 
we're wasting people's time asking for a +1 on code that is not intended 
to be landed into master. Often this code will take shortcuts or stub 
out some code, and as the lead I'll make a judgment call to circle-back 
later. Reviewers don't necessarily know this.


Conversely, when we go to land the feature branch into master, these PRs 
are generally rubber-stamped.


I feel like maybe we have this backwards?

-
Katherine

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

Re: Latest on the LXD Provider!

[Katherine Cox-Buday]

Simon, I've gone ahead and added you as a subscriber to the blueprint 
 
for this feature. That was as things develop you can stay in the loop.


Would you be willing to give feedback on how this feature is shaping up 
when we begin developing?


-
Katherine

On 11/16/2015 11:07 AM, Rick Harding wrote:

On Mon, 16 Nov 2015, Simon Davy wrote:


Some uses cases OTTOMH:

- mounting specific code branches into the lxd for development

This is a feature we're looking at Juju adding to support sharing the local
filesystem to the unit deployed with lxd in order to speed up development
cycles. There's a current spec on this that's under iteration and requires
the LXD work to land before it can begin. It'll build on top of the storage
work so that it's meant to be modeled as sharing generic filesystems in all
of the supported providers.


- mount users $HOME dir for convenience (ssh keys, bash/editor/bzr config, etc)

Kind of the same as above I'd think. Maybe there's some magic bits to this
example.


- controlling the network bridge, a la Jay's recent post.

- adding additional veths/bridges, in order to test your charm's
handling of public/private ip addresses (currently only possible by
deploying to an actual cloud provider, AFAIK)

- likewise for volumes - if adding an lxd disk device could link into
the new storage hooks, then we can test our storage hooks locally.

Hmm, maybe some of these are not solved by custom lxd profiles, but
just lxd provider feature requests :)

Yes, as the provider lands I think there'll be room to make sure it gets
first class support for Juju modeling of things such as storage and
networking.



I would happily write up a proposal - is this list the correct venue?

Preferably a google doc that folks can comment, question, and refer back
to.



I'm paraphrasing, but the idea is to tell Juju not to lookup the image
("trusty", "precise") the way it normally would, but just to trust you
and wing it with that base image. This wants to be done in a way which
works for LXD and on any cloud that can provide a named snapshot or
image for launch.

\o/ - hurrah!  This would be great. We could publish these images out
of our CI process, for our application charms. As well as maybe
consume an IS-provided base image for other services, rather than the
cumbersome basenode scripts we currently use.

Is there a spec document for this?

It's a more recent add to the roadmap and we're investigating what it would
take to support this. I'll make sure the team adds you in as a feature
buddy and gets you a copy of the doc as it comes together.

Thanks for the feedback! It's great to see folks excited to use things and
to find guinea pigs as things land and become available.

--
Rick Harding



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

Latest on the LXD Provider!

[Katherine Cox-Buday]

Hey all,

Moonstone spent last iteration tightening up the LXD provider. You can 
see the latest results in our latest Demo Day 
. It's a ~9 minute video 
which demonstrates:


1. The format of the entry into environments.yaml.
2. LXD bootstrapping locally.
3. The fact that it's no longer necessary to tweak permissions of the
   unix socket to utilize this.
4. Juju LXD coming back up when the host is rebooted.

We're also very happy to announce that this will land in the upcoming 
1.26-alpha2 milestone on 2015-11-17! If you'd like to play with this in 
the meantime, feel free to build from our feature branch 
 and log bugs against 
the blueprint 
. 
Documentation and release notes will be forthcoming.


Thanks, and have fun!

-
Katherine

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

Re: Latest on the LXD Provider!

[Katherine Cox-Buday]

Thanks, Rick. We can definitely try out multiple environments locally.

I forgot to mention, Wayne did a great blog post 
<http://waynewitzel.com/2015/11/05/juju-and-remote-lxd-host/> discussing 
using the LXD provider on remote hosts.


On 11/09/2015 12:19 PM, Rick Harding wrote:
Thanks Katherine. That's looking great. One request, next demo I'd be 
curious to see how easy it is to run multiple lxd environments 
locally. I know it's been possible with lxc before with a bunch of 
config. Ideally we'd just be able to create a new named section and 
say it's lxd and boom, I can bootstrap the new one and have it 
distinct from the first.


Keep up the great work!

On Mon, Nov 9, 2015 at 11:59 AM Katherine Cox-Buday 
<katherine.cox-bu...@canonical.com 
<mailto:katherine.cox-bu...@canonical.com>> wrote:


Hey all,

Moonstone spent last iteration tightening up the LXD provider. You
can see the latest results in our latest Demo Day
<https://www.youtube.com/watch?v=QyXLRDN0ERo>. It's a ~9 minute
video which demonstrates:

 1. The format of the entry into environments.yaml.
 2. LXD bootstrapping locally.
 3. The fact that it's no longer necessary to tweak permissions of
the unix socket to utilize this.
 4. Juju LXD coming back up when the host is rebooted.

We're also very happy to announce that this will land in the
upcoming 1.26-alpha2 milestone on 2015-11-17! If you'd like to
play with this in the meantime, feel free to build from our
feature branch <https://github.com/juju/juju/tree/lxd-provider>
and log bugs against the blueprint

<https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-lxd-provider>.
Documentation and release notes will be forthcoming.

Thanks, and have fun!

-
Katherine



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

New feature in 1.25.0: Payload Management!

[Katherine Cox-Buday]

Hey All,

Moonstone have been working hard this cycle on delivering a way to manage 
payloads from within a Juju Charm, and providing a nice way to expose 
information about the payloads through the Juju client. We got off course for a 
bit there, but with the help of Mark and some others, we're very happy to 
announce that this work has landed in v1.25.0 (now in proposed)!

Throughout work on this feature, we've worked very closely with our amazing 
Ecosystems team, and we're happy to point you all to a blog post[1] Chuck 
(lazypower) put together demonstrating a charm he's written utilizing payload 
management (as well as our awesome new reactive charming!). The payload 
management stuff starts @ 3:40 in Chuck's video[2], but it's only 6 minutes 
long, so go ahead and watch the entire thing :)

Enjoy, and let me know if you have any questions!

-
Katherine

[1] http://blog.dasroot.net/2015-charming-2-point-oh.html
[2] https://youtu.be/aRQcERLnbIQ?t=221

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

Re: link to review request in launchpad

[Katherine Cox-Buday]

Seriously speaking -- and let me preface this by saying this is probably
very low on the priority list -- how hard would it be to take advantage of
Launchpad's new Git support to import branches from Github so that we could
tag bugs to branches/commits? Having never used any of these features, I
don't have any good feel for the level of effort.

It sure would be nice...

On Wed, Jun 17, 2015 at 3:34 PM, Tim Penhey tim.pen...@canonical.com
wrote:

 On 18/06/15 03:11, Eric Snow wrote:
  All,
 
  After posting a review request (i.e. a PR), please be sure to add a
  link to the review request/PR (as a comment) to the lp issue the patch
  addresses.  Otherwise it's a pain trying to track down which commits
  actually relate to the issue.
 
  Similarly, be sure to include a link to the related issue in the PR
 description.

 Ya know... if we were using branches on launchpad, this would be done
 automagically.

 *nudge* *nudge*

 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

Reminder: on June 15th, Go 1.4 will stop compiling things from code.google.com.

[Katherine Cox-Buday]

I think there was an effort to remove this from our code, but I thought I'd
send out a reminder to check and for personal projects. May the source be
with you...

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

Re: Request to support to work with Juju

[Katherine Cox-Buday]

Thanks for reaching out, Dinesh!

I have opened two bugs for these issues:

1.In *juju bootstrap. *It is *not downloading the  disc image* itself. But
 when I check juju status, it is showing machine-0 (started state).

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


 2.And when I try to *deploy any service*, it adding the charm but the new
 instance is staying in *pending state* forever and it is not *creating
 the template*.

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

Would you mind logging any relevant information there? It will help us to
triage the issue more quickly.

-
Katherine


On Thu, Apr 30, 2015 at 3:13 AM, Marco Ceppi ma...@ondina.co wrote:

 Hello, are you using the local provider? If so it can take several minutes
 to seed the initial download of the cloud image. You can find if the image
 was downloaded by checking /var/cache/lxc/cloud-* where * is precise,
 trusty, or the series you're trying to deploy. Images are downloaded only
 when you first attempt to deploy and then cached in that directory. Once
 cached it will attempt to build a LXC template (`sudo lxc-ls --fancy`
 should produce output with something like juju-trusty-lxc-template) if
 you don't see anything in the cache directory, or in the lxc-ls output, or
 you do, or you're not using local provider, let us know.

 Also, the version of juju you're using may also help us identify issues
 you're having.

 Thanks,
 Marco Ceppi

 On Thu, Apr 30, 2015 at 3:52 AM dinesh.senap...@wipro.com wrote:

  Hi,

 I have been working on Juju for last 2 weeks. There are some blockages
 while working on it like:

 1.In *juju bootstrap. *It is *not downloading the  disc image* itself.
 But when I check juju status, it is showing machine-0 (started state).

 2.And when I try to *deploy any service*, it adding the charm but the
 new instance is staying in *pending state* forever and it is not *creating
 the template*.



 Kindly help me figure out the way to solve the above problems.



 Thanks and Regards,

 Dinesh Kumar Senapaty,

 Wipro Technologies.
  The information contained in this electronic message and any attachments
 to this message are intended for the exclusive use of the addressee(s) and
 may contain proprietary, confidential or privileged information. If you are
 not the intended recipient, you should not disseminate, distribute or copy
 this e-mail. Please notify the sender immediately and destroy all copies of
 this message and any attachments. WARNING: Computer viruses can be
 transmitted via email. The recipient should check this email and any
 attachments for the presence of viruses. The company accepts no liability
 for any damage caused by any virus transmitted by this email.
 www.wipro.com
 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju


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


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

Janus: a fake rest api server

[Katherine Cox-Buday]

https://github.com/jijeshmohan/janus

Disclaimer: I haven't looked at this too closely.

Came across this the morning. If we want to maintain test-doubles, this
looks like a nice, declarative, way to specify mock responses from a local
server.

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

Re: Watch out for plural vs. singular

[Katherine Cox-Buday]

I ran into a similar type of issue recently. I discussed very briefly with
John M. and William, and I think a good thing to do would be to hide the
generic RegisterResource method, and only expose methods which take the
interface types. This would convert these types of issues from runtime to
compile-time bugs.

-
Katherine

On Thu, Mar 19, 2015 at 10:48 AM, Nate Finch nate.fi...@canonical.com
wrote:

 Wayne and I (and Horacio for some of the time) wasted a few days trying to
 figure out a problem with the watcher we'd created.  Turns out, the problem
 was a missing 's':
 https://github.com/natefinch/juju/commit/12ad8d64f26aca5541bbd0f0c10cd8b45bcbcc75

 Thanks to Dimiter and John Weldon for catching it last night.

 The reason the code still compiled is because all the facade caller (rpc)
 stuff uses empty interfaces and reflection to do
 serialization/deserialization.  This is, at some level, unavoidable.
 However, it's sort of our own fault, too, for naming two things so
 similarly in code that we *know* is not type safe.

 Please try to avoid making two types with very similar names if they're
 commonly used for serialization, especially if they're long names that only
 differ at the end.  It makes it way too easy for a typo to slip in and
 cause hard to find bugs.

 -Nate

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


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

Re: commands

[Katherine Cox-Buday]

Looks great, Nick! Cheers for the good work, and I love that it's
automatically synchronized! This should drive quality up in both places!

On Tue, Feb 3, 2015 at 6:08 AM, Nick Veitch nick.vei...@canonical.com
wrote:

 Hello,

 I have just finished updating the all-new exciting and more comprehensible
 commands reference page in the docs for 1.21.1:

 https://juju.ubuntu.com/docs/commands.html

 The more observant of you will notice that the content has almost all been
 autogenerated directly from juju help. This is exciting (for me
 anyway) because I have long yearned for these to sync better. Some
 commands are better explained than others, and some could do with some
 examples, but I can contribute those.

 Before I do that, I did have a question - there are some consistent
 inconsistencies in the style of the output; for example, there is
 'purpose:' and 'usage:', but 'Example:' is capitalised. Is there some
 compelling reason for this wrongness which people have passionate
 opinions about, or can I fix it (i.e. Usage:, etc.)?


 --
 Nick Veitch
 nick.vei...@canonical.com

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

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

Re: New Package for Feature Tests

[Katherine Cox-Buday]

A small update to this, I just landed a PR which allows you to filter out
these tests if you're only interested in short-running unit-style tests.
From the package godoc
https://github.com/juju/juju/blob/master/featuretests/doc.go#L20:

To run tests excluding the functional tests in this package, specify
 the --featuretests=false option:

go test github.com/juju/juju/... --featuretests=false


On Thu, Jan 8, 2015 at 9:00 PM, Ian Booth ian.bo...@canonical.com wrote:

 Thank you Katherine, it's great to see this important work come to
 fruition.

 One area of the code in particular which will benefit from this is the CLI,
 implemented in cmd/juju. Historically, cmd/juju unit tests were written
 on top
 of a full stack (as an aside, any test suite which embeds JujuConnSuite is
 not a
 unit test). Recently implemented commands have tests which stub out the api
 client and are written as true unit tests. However, these are missing
 end-end
 integration tests.

 Obviously we should look to split, as time allows, existing command tests
 into
 unit tests and feature tests. But could authors of recently added command
 tests
 which are missing feature tests please go ahead and add those.

 To reinforce what Katherine says, the feature tests should only really
 cover the
 happy path, to ensure that everything is wired together and working
 properly.

 Moving forward, reviewers should look to push back on branches which 1) do
 not
 use proper unit tests, 2) do not have feature tests.

 On 09/01/15 12:03, Katherine Cox-Buday wrote:
  Hey everyone,
 
  I just landed a PR which introduces a new package for Juju which is
  intended to host long-running end-to-end feature tests. You can have a
 look
  here: github.com/juju/juju/blob/master/featuretests/doc.go
 
  A little context as I understand it:
 
 1. This is the direct result of the team's discussion about
 segregating
 long-running tests from short-running tests.
 2. It is the intention of the team that tests now be written thus:
- Light-weight unit tests alongside Juju core packages.
- End-to-end feature tests in this new package.
 
  Hopefully this allows us to be more agile as we modify code, but still
  maintain the safety-net of end-to-end tests. The main difference for me
 is
  that the bulk of our tests -- where we test edge-cases, all permutations
 of
  calls, etc. -- will now be in lightweight unit tests. The heavier-weight,
  end-to-end tests will now be used in a 1:1 ratio with user-facing
 features,
  and the number of these that we have to maintain should drop off a bit.
 
  This has been a great team effort to steer a very large change; kudos to
  you all!
 
  -
  Katherine
 
 
 

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

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

New Package for Feature Tests

[Katherine Cox-Buday]

Hey everyone,

I just landed a PR which introduces a new package for Juju which is
intended to host long-running end-to-end feature tests. You can have a look
here: github.com/juju/juju/blob/master/featuretests/doc.go

A little context as I understand it:

   1. This is the direct result of the team's discussion about segregating
   long-running tests from short-running tests.
   2. It is the intention of the team that tests now be written thus:
  - Light-weight unit tests alongside Juju core packages.
  - End-to-end feature tests in this new package.

Hopefully this allows us to be more agile as we modify code, but still
maintain the safety-net of end-to-end tests. The main difference for me is
that the bulk of our tests -- where we test edge-cases, all permutations of
calls, etc. -- will now be in lightweight unit tests. The heavier-weight,
end-to-end tests will now be used in a 1:1 ratio with user-facing features,
and the number of these that we have to maintain should drop off a bit.

This has been a great team effort to steer a very large change; kudos to
you all!

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

Things which may be of interest in Go v1.4

[Katherine Cox-Buday]

Hey All,

I just got done reading through the Go v1.4 release-notes[1], and these are
some high-level thoughts about what pieces may be of interest to Juju
development. This is certainly not comprehensive, but I thought you all
might be interested. Happy release day :)

   -
*go generate *https://golang.org/doc/go1.4#gogenerate
   This is *very* powerful and could reduce the number of copy/paste
   snippets, or unsafe reflection code we have to write. For those of you who
   are familiar with the lisps, this is essentially macros. You write code
   that examines Go expressions and does something. This code is
triggered by *//go:generate
   command arg* comments in the code. As a quick example, our StringSet
   type could be generated and even expanded to encompass any type.
   -
*New func TestMain(m *testing.M) *https://golang.org/pkg/testing/#MainStart
   Since we use gocheck and gocheck requires you to register the testing
   subsystem, this now looks like the best place to do this. Without this, you
   can run into difficult to debug behavior when filtering to certain subsets
   of tests, or duplication of registration.
   - *Canonical Import Paths*
   https://golang.org/doc/go1.4#canonicalimports
   This helps out when using the gopkg.in pattern. For libraries that are
   specific to Juju, we may want to specify this to help enforce the notion
   that we want to use gopkg.in and not github.com/* or launchpad.net/*.
   - *Internal Packages*
   https://golang.org/doc/go1.4#internalpackages
   Just what it sounds like. We can now hide implementation details from
   importers. Probably more useful for the ancillary Juju packages as Juju
   Core is probably not imported very much.

-
Katherine

[1] https://golang.org/doc/go1.4
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Things which may be of interest in Go v1.4

[Katherine Cox-Buday]

On Thu, Dec 11, 2014 at 10:52 AM, Eric Snow eric.s...@canonical.com wrote:

 Cool.  So generics via macros?


Well, I intentionally didn't specify generics. Yes, that is a use-case. But
from what I gather, go generate is intended to be used once when first
writing code, not every time you compile.

So it's more like another tool than a language feature: you use the tool to
remove the tedium/errors from copy/pasting. So to continue the Set example,
if you were implementing a new type and you wanted to use it with Sets,
you'd reach for two tools: go generate, and a library which generates a Set
type specific to another type. It generates new source code which gives you
this functionality. It's much more intentful than generics in that you have
to make a decision to generate code.

 Also, while I think this will mostly be used to parse/generate Go code,
it's also not limited to that. Rob Pike gives yacc as an example of where
this might also be useful.


 Nice.  This would be good for our various testing sub-packages, among
 other things.


Good point, I hadn't thought of that.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Things which may be of interest in Go v1.4

[Katherine Cox-Buday]

Good point Gustavo; generating code was all doable before Go v1.4, go
generate just bakes it into the development process.

Can either of you go into some detail as to why you don't like code
generation?

To start off, a thought experiment: if I were to generate a new Set type
for my Foo struct, how would you know I didn't write it by hand?


On Thu, Dec 11, 2014 at 1:33 PM, Tim Penhey tim.pen...@canonical.com
wrote:

 I also couldn't help but read through the release notes of Go 1.4 last
 night.

 I agree with Gustavo that we should avoid code generation unless
 absolutely necessary.  I have a strong feeling that it won't be
 necessary given how far we have come without it.

 I did like the internal packages, however these are only enforced in the
 Go standard library with 1.4, and other packages with 1.5.  Still a good
 idea though.

 Tim

 On 12/12/14 06:56, Gustavo Niemeyer wrote:
  Thanks for the write up Katherine, and I agree these are all very nice
  improvements.
 
  On this list, the one I find slightly less exciting is go generate.
  This is essentially a standard way to run external processing tools,
  which might already be done before anyway via standard practices. For
  example, the gl package in Go QML was already being generated via a
  Makefile before, and it's nice that we can now give a hint about how to
  re-build the generated sources, but it's a nice convenience rather than
  an enabler.
 
  I'm also slightly worried about all the excitement that has surfaced in
  the community with go generate. Generating code is very useful and
  powerful, but comes with a price (debugging, readability, etc). I'd
  rather NOT generate code whenever possible.
 
 
 
  On Thu Dec 11 2014 at 2:21:20 PM Katherine Cox-Buday
  katherine.cox-bu...@canonical.com
  mailto:katherine.cox-bu...@canonical.com wrote:
 
  Hey All,
 
  I just got done reading through the Go v1.4 release-notes[1], and
  these are some high-level thoughts about what pieces may be of
  interest to Juju development. This is certainly not comprehensive,
  but I thought you all might be interested. Happy release day :)
 
* *go generate
  *https://golang.org/doc/go1.4#gogenerate
  This is *very* powerful and could reduce the number of
  copy/paste snippets, or unsafe reflection code we have to write.
  For those of you who are familiar with the lisps, this is
  essentially macros. You write code that examines Go expressions
  and does something. This code is triggered by ///go:generate
  command arg/ comments in the code. As a quick example, our
  StringSet type could be generated and even expanded to encompass
  any type.
* *New func TestMain(m *testing.M)
  *https://golang.org/pkg/testing/#MainStart
  Since we use gocheck and gocheck requires you to register the
  testing subsystem, this now looks like the best place to do
  this. Without this, you can run into difficult to debug behavior
  when filtering to certain subsets of tests, or duplication of
  registration.
* *Canonical Import Paths*
  https://golang.org/doc/go1.4#canonicalimports
  This helps out when using the gopkg.in http://gopkg.in
  pattern. For libraries that are specific to Juju, we may want to
  specify this to help enforce the notion that we want to use
  gopkg.in http://gopkg.in and not github.com/*
  http://github.com/* or launchpad.net/* http://launchpad.net/*
 .
* *Internal Packages*
  https://golang.org/doc/go1.4#internalpackages
  Just what it sounds like. We can now hide implementation details
  from importers. Probably more useful for the ancillary Juju
  packages as Juju Core is probably not imported very much.
 
  -
  Katherine
 
  [1] https://golang.org/doc/go1.4
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/__mailman/listinfo/juju-dev
  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: Proposal: feature flag implementation for Juju

[Katherine Cox-Buday]

I like the idea. Thinking out loud: do we want to combine this with the
wrench so that we have 1 consistent way to fiddle with Juju behavior?

On Tue, Nov 25, 2014 at 4:47 PM, Tim Penhey tim.pen...@canonical.com
wrote:

 Hi all,

 There are often times when we want to hook up features for testing that
 we don't want exposed to the general user community.

 In the past we have hooked things up in master, then when the release
 branch is made, we have had to go and change things there.  This is a
 terrible way to do it.

 Here is my proposal:

 http://reviews.vapour.ws/r/531/diff/#

 We have an environment variable called JUJU_FEATURE_FLAGS. It contains
 comma delimited strings that are used as flags.

 The value is read when the program initializes and is not mutable.

 Simple checks can be used in the code:

 if featureflag.Enabled(foo) {
   // do foo like things
 }

 Thoughts and suggestions appreciated, but I don't want to have the
 bike-shedding go on too long.

 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: Is ReviewBoard a good thing?

[Katherine Cox-Buday]

I don't yet have a strong opinion either way. I do think that since we
invested so much time in getting Review Board set up, we should use it for
a bit longer to see if these are growing pains.

On Fri, Sep 19, 2014 at 7:11 AM, Gabriel Samfira 
gsamf...@cloudbasesolutions.com wrote:

  Just a suggestion:

 A git plugin similar to what Gerrit has would simplify things. For
 example, Gerrit has a nice little plugin called Review. Simply doing:

 git review

 In your current branch would push the patchest to gerrit. Something
 similar for RB, would probably simplify things a lot. Chained PR's could
 probably be done by specifying in the commit message something like:

 depends on #PR ID

 Just a thought.

 Cheers


 On 19.09.2014 14:32, Nate Finch wrote:

 There's one thing that hasn't been mentioned - reviewboard gives us a
 unified review queue.  On github you need to look in 8 places to see all
 the stuff up for review, and anything not in juju/juju tends to get lost.
  This is really important since that can have a big effect on our velocity.

  I think we should continue using reviewboard until we've had more time
 to adjust to it.  Remember, we were ready to abandon github after the first
 week, too.

  I think tooling can solve most of our problems with complicated
 workflows.

 On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina 
 jaquil...@eagleeyet.net wrote:

  Hey guys.

 Long time lurker with the occasional suggestion.

 I have an idea for something that might be beneficial to the project as a
 whole. Has it been considered about custom coding a review system that will
 interface with github hooks and provide what is needed to all juju dev's
 and keep things rather mainstream as well so as not to increase the entry
 level requirements fore new contributors?

 ---
 Regards,
 Jonathan Aquilina
 Founder Eagle Eye T

   On 2014-09-19 10:14, Frank Mueller wrote:

  Right now I'm a bit undecided, the usage of ReviewBoard is too fresh.
 But Jesse made good points and in general Im always happy when we're using
 less instead of using more tools. I can live with the number of mails,
 GMail does grouping them fine. And I started to add my comments after a
 first pass through a PR. My greatest weakness so far has been the missing
 side-by-side diff, thankfully GitHub addressed this.

  So I'm with Jesse and will go with the team if we decide to use
 ReviewBoard, but I prefer returning to a GitHub based process as it is know
 in many other communities too.

  mue


 On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com
 wrote:

  On 19 September 2014 01:32, David Cheney david.che...@canonical.com
 wrote:
  There were three problem reviewboard was supposed to address, review
  comments are sent immediately, no side by side diffs, and no way to to
  chained proposals.
 
  I think that over the last few months we've all learnt to live with
  the first issue
 
  On the second, github now does nice side by side diffs.
 
  On the third, it appears reviewboard leaves you solidly to your own
  devices to implement chained proposals.
 
  I'm with Jesse, I vote to stop using reviewboard, I don't think it's
  paying it's way.

 The main thing I was hoping to get from reviewboard that's
 a constant pain to me in github was the ability to look
 at new changes in the context of old comments, to see
 where and how those comments have been addressed.

 So, assuming reviewboard did address that issue, I'm a
 bit sad but I think Jesse makes a very
 good point about keeping things mainstream.

 I guess there's the potential for some third party tool
 to address my issue above.

 So I agree that it might be better to cut losses here and embrace
 github, even if it is awkward in some ways.

   cheers,
 rog.

  On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com
 wrote:
  We moved to GitHub in the hope of lowering the bar to contributors
 outside
  the team. GitHub is *the* platform and process for open source
 software.
  This was the logic behind the move. It was deemed to have the most
 mindshare
  and we sacrificed our prefered platform and process to be part of that
  mindshare.
 
  We are now leaving that 'main stream' process to something that suits
 the
  tastes of our team - ReviewBoard. This adds friction for new
 contributors
  (friction everyone has experienced this week). If we value our
 preferred
  methods of reviewing over keeping to a well known process for outside
  contributors, the best process was launchpad + rietveld. Shouldn't we
 simply
  return to that.
 
  Considering we have been successfully using GitHub for several months
 now,
  using reviewboard is not a necessity. Obviously, I will go with
 whatever the
  team decides, but I'm concerned that we have moved to reviewboard
 without
  considering that it undermines (as far as I can see) our primary
 reason for
  using GitHub.
 
  Jess
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or 

Re: ReviewBoard is now the official review tool for juju

[Katherine Cox-Buday]

Let me preface this by saying I like the Reviewboard style of reviewing
changes.

It's somewhat concerning to me that our reviews are now disconnected from
what will actually be landed into trunk. In Github, you were reviewing the
actual diff which would be landed. In reviewboard, we're now reviewing a
diff manually uploaded by the developer. There's a lot of room for error in
terms of what diff we review vs. what diff we land.

Any thoughts on how to couple these things once again?

-
Katherine

On Mon, Sep 15, 2014 at 10:03 AM, Eric Snow eric.s...@canonical.com wrote:

 On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits menno.sm...@canonical.com
 wrote:
  It looks like the TRACKING_BRANCH option in .reviewboardrc could be
 helpful.
  It defaults to origin/master but if we changed it to upstream/master
 I
  suspect Reviewboard will then generate diffs against the shared master
  branch instead of what we might happen to have in master in our personal
  forks. The of course relies on every developer having a remote called
  upstream that points to the right place (which isn't necessarily true).

 FWIW, I have the following in $GOPATH/src/github.com/juju/juju/.git/config
 :

 [remote origin]
 url = g...@github.com:ericsnowcurrently/juju.git
 fetch = +refs/heads/*:refs/remotes/origin/*
 [remote upstream]
 url = https://github.com/juju/juju.git
 fetch = +refs/heads/*:refs/remotes/upstream/*

 and in ~/.reviewboardrc:

 TRACKING_BRANCH = upstream/master

 This has worked fine for me (once I realized master had to be up-to-date).

 -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

Commented-out tests?

[Katherine Cox-Buday]

Hey all,

I ran into some commented out tests while making a change:
https://github.com/juju/juju/pull/630/files#r16874739

I deleted them since keeping things around that we might need later is the
job of source control, not comments ;)

Ian just wanted me to check just to make sure this was OK. If not, please
chime in on the PR ASAP.

Thanks all!

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

Re: The tests now run godeps

[Katherine Cox-Buday]

I have toyed with the idea of adding a git hook that runs godeps whenever I
switch branches. I haven't gotten around to trying it out, but would that
possibly be another helpful thing for developers to do?


On Thu, Aug 21, 2014 at 5:14 AM, roger peppe roger.pe...@canonical.com
wrote:

 On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote:
  We've figured out that using godeps to print dependencies fails if you've
  installed Go from the PPA rather than from source, so that's why we're
  getting different results (Tim  Ian have the PPA, I have the source).

 I'm sorry this is the case. I have now pushed a change to godeps that
 should fix the problem.

 Please run go get -u launchpad.net/godeps to update.

   cheers,
 rog.

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

LXC OS Updates

[Katherine Cox-Buday]

Hey all!

Ian and I were discussing lp:1350493
https://bugs.launchpad.net/juju-core/+bug/1350493 (1.20.x local provider
not running apt-get update) and thought it might be good to raise a few
ideas here.

It is my understanding that currently we do LXC cloning in the interest of
saving time -- the thinking being: if I have an image set up, I want to use
it as a starting-point when provisioning machines. Pursuant to this
performance goal, Juju will not run the OS's upgrades if a clone is
performed. Of course, this is what is causing the aforementioned bug.

I am doing some work for another issue lp:1322302
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1322302 which
involves attempting to speed up provisioning of local providers. One of the
things we're introducing are config values (with sane, backwards-compatible
defaults) that allow the user to specify whether or not they'd like Juju to
refresh the available updates (in dpkg systems, apt-get update), and
whether or not they'd like Juju to execute any available updates (in dpkg
systems, apt-get upgrade).

We'd like to remove the assumption embedded in the code that if we're
cloning an LXC container, then we never want to perform OS upgrades.
Instead, the logic based on the config variable will take over, and the
user can have whatever behavior they desire. Local installations will be
snappy, and production installations will be up to date.

We feel this empowers both developers and end-users, but wanted to raise
this for discussion. Feedback welcome!

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

Parameter validation Juju

[Katherine Cox-Buday]

Hey all,

What is the general consensus on parameter validation in Juju? As a general
practice, I always like to see code that validates parameters passed into
methods so that it fails fast, and gives future developers a contract to
work off of.

Just yesterday I experienced a nil-reference panic which occurred after a
lot of heavy operations. Parameter validation would have kicked me out much
higher in the stack and given me some indication of what was wrong.

Always interested in discussion :)

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

Re: Enhancing our IRC bot?

[Katherine Cox-Buday]

Great to hear!

I'd love to scan your erlang code. I started learning it awhile ago, but I
never attempted any serious projects.


On Wed, Jul 23, 2014 at 12:02 PM, Gustavo Niemeyer gust...@niemeyer.net
wrote:

 Great timing, Kate.

 I was recently asked to take care of mup's deployment again, and I'm
 about to put live its third incarnation, reviving a hack I started
 back in 2011 to port the ancient Erlang bot I wrote too many years ago
 into a Go version. My goal, among other things, is to make plugin
 writing a lot easier, so this kind of problem fits well. I'm just
 finishing a few details and will send some notes soon.

 On Wed, Jul 23, 2014 at 11:55 AM, Katherine Cox-Buday
 katherine.cox-bu...@canonical.com wrote:
  Hey all,
 
  I thought my first post to the list would be something relatively
 innocuous
  :)
 
  Have we ever considered enhancing our IRC bot to report CI status? Maybe
  start off with important notifications such as job failures? It might
 bring
  more attention to the health of trunk, and IRC is already a major
  communication hub.
 
  Interested in your thoughts!
 
  -
  Katherine
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or unsubscribe at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev
 



 --

 gustavo @ http://niemeyer.net

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