Re: Proposal: making apt-get upgrade optional

2014-07-07 Thread Andrew Wilkins
On Sat, Jul 5, 2014 at 4:05 AM, Antonio Rosales antonio.rosa...@canonical.com wrote: On Thu, Jul 3, 2014 at 7:41 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, Jul 4, 2014 at 5:23 AM, Tim Penhey tim.pen...@canonical.com wrote: I do just want to make the point that we are

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread roger peppe
On 4 July 2014 15:17, Gustavo Niemeyer gust...@niemeyer.net wrote: On Fri, Jul 4, 2014 at 10:32 AM, roger peppe roger.pe...@canonical.com wrote: It won't be possible to shard the transaction log. Why not? I had assumed that because every client needs to see every transaction there would

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 10:09 AM, roger peppe roger.pe...@canonical.com wrote: I had assumed that because every client needs to see every transaction there would likely be no benefit to sharding the log, although technically you could shard on transaction id. I'd be Clients don't need to see

Re: Proposed new charm store API

2014-07-07 Thread Aaron Bentley
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks. One thing juju-reports needs is a list of all the charms. I think the API spec doesn't include that. Aaron On 14-07-07 05:14 AM, roger peppe wrote: Francesco Banconi and I have produced a possible specification for the new charm store

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread roger peppe
On 7 July 2014 14:27, Gustavo Niemeyer gust...@niemeyer.net wrote: On Mon, Jul 7, 2014 at 10:09 AM, roger peppe roger.pe...@canonical.com wrote: I had assumed that because every client needs to see every transaction there would likely be no benefit to sharding the log, although technically

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread roger peppe
On 7 July 2014 16:59, Gustavo Niemeyer gust...@niemeyer.net wrote: On Mon, Jul 7, 2014 at 12:26 PM, roger peppe roger.pe...@canonical.com wrote: On 7 July 2014 14:27, Gustavo Niemeyer gust...@niemeyer.net wrote: On Mon, Jul 7, 2014 at 10:09 AM, roger peppe roger.pe...@canonical.com wrote:

move towards using gopkg.in

2014-07-07 Thread roger peppe
I think it would be a good idea if we moved towards defining stable APIs, particularly for repositories outside github.com/juju/juju itself. In particular, I hope we can make go get work without people needing to jump through the godeps hoop. This is a particular issue as we move towards having

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 2:03 PM, roger peppe roger.pe...@canonical.com wrote: The latter might turn out to be quite awkward, though there's probably a nice solution I don't see. Suppose we've got three environments, A, B and C. We have transactions that span {A, B}, {B, C} and {C, A}. How

Re: move towards using gopkg.in

2014-07-07 Thread Tim Penhey
On 08/07/14 09:00, Ian Booth wrote: gopkg.in is a decent solution to this problem, I believe, and a good direction to head in general. After discussion with (and approval by) several juju-core members, we have pushed the new API to gopkg.in/juju/charm.v2 (the code now lives in the v2 branch

Re: move towards using gopkg.in

2014-07-07 Thread roger peppe
On 7 Jul 2014 22:03, Tim Penhey tim.pen...@canonical.com wrote: On 08/07/14 09:00, Ian Booth wrote: gopkg.in is a decent solution to this problem, I believe, and a good direction to head in general. After discussion with (and approval by) several juju-core members, we have pushed the

Re: RFC: mongo _id fields in the multi-environment juju server world

2014-07-07 Thread Ian Booth
On 04/07/14 23:56, Gustavo Niemeyer wrote: On Thu, Jul 3, 2014 at 10:01 PM, Tim Penhey tim.pen...@canonical.com wrote: As far as I know (and I may be wrong), if you are adding a document to the mongo collection, and you do not specify an _id field, mongo will create a unique value for you.

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 6:00 PM, Ian Booth ian.bo...@canonical.com wrote: I'm somewhat wary of depending on an another unknown third party website being That's hilarious. I haven't been pushing for its usage on juju, and I'm still not the one actively pushing it, but that's a pretty bad

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth ian.bo...@canonical.com wrote: It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite prudent to ensure that critical infrastructure on which our development depends meets expectations with regard to uptime, reliability etc (a case

Re: move towards using gopkg.in

2014-07-07 Thread Ian Booth
On 08/07/14 08:32, Gustavo Niemeyer wrote: On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth ian.bo...@canonical.com wrote: It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite prudent to ensure that critical infrastructure on which our development depends meets expectations

Dropbox has open sourced some of their Go libraries

2014-07-07 Thread Menno Smits
Hey look - another errors package! */me ducks* https://tech.dropbox.com/2014/07/open-sourcing-our-go-libraries/ -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 8:49 PM, David Cheney david.che...@canonical.com wrote: I don't want to introduce another thing to break CI, we already pull from github which is bad enough, but going via gopkg.in introduces an additional point of failure which can further reduce the already bullet

Re: move towards using gopkg.in

2014-07-07 Thread Tim Penhey
On 08/07/14 13:49, Gustavo Niemeyer wrote: go list -f '{{range .Deps}}{{printf %s\n .}}{{end}}' | grep gopkg.in | sort -u | sed 's/\.v[0-9]\+$/\.vN/' | uniq -c | sed '/ 1 /d' Yay pipes !?!? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: