Re: Sharing environments - a proposal

... > > PROBLEM: right now all connections to the api server are secured with > > TLS and the client-cert. > > As John says, this isn't actually true - connections are secured with > a server cert and a password. > > Unfortunately I believe it is impossible to lose either one of these > without r

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

Masking is often necessary, and information hiding is valuable, and depending on spooky action at a distance is generally foolish. But the granularity with which we want to track the propagation of a given error is *much* finer than the granularity of judicious information hiding: the error is like

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

Note that this kind of error masking doesn't need to be done in the same package as the base error package. I made a little standalone package that does it, we could do something similar if we wanted to keep the error package simpler (which is always

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

What Roger is talking about, is when an error is implementation-specific and may change if the implementation changes. For example, if you have a black box service that saves data, it might write to the network or it might write to a filesystem, but where it saves is an implementation detail. Let

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

On 2014-05-29 09:50, roger peppe wrote: On 29 May 2014 04:03, Tim Penhey wrote: Errors are worth treating specially here because they're they pass up through multiple layers, so it's very easy to break abstraction boundaries by relying on specific error types. I believe it's very important to

Re: Sharing environments - a proposal

[This discussion originated on juju-dev@lists.ubuntu.com - I'm replying to juju-...@lists.canonical.com because it touches on JAAS issues] On 29 May 2014 06:46, Tim Penhey wrote: > Hi folks, > > The onyx team is dealing with sharing environments between multiple > people. Currently how this is h

Re: Sharing environments - a proposal

that makes it easy for Eric to connect to the environment. Now ideally > where we'd like to get to is the following: > >juju connect eric@ [] > > ... > PROBLEM: right now all connections to the api server are secured with > TLS and the client-cert. > I'm pretty sure none of them use client

Re: Schema migration process

On Thu, May 29, 2014 at 4:00 PM, Menno Smits wrote: > Team Onyx is accumulating tasks that can't be completed until the schema > migrations infrastructure is in place so I've started digging in to the > details to figure out what exactly needs to be done. I'm aiming to come up > with an approach

Re: critical regression blocks 1.19.3 release

On 28/05/14 21:54, Curtis Hovey-Canonical wrote: I don't think we can do a release this week, or if we do, the release will be from a version that works from last week. The current blocker is lp:juju-core r2803 or lp:juju-core r2804 broke local precise deployments. Juju cannot bootst

Re: Schema migration process

Team Onyx is accumulating tasks that can't be completed until the schema migrations infrastructure is in place so I've started digging in to the details to figure out what exactly needs to be done. I'm aiming to come up with an approach and some the work items for the initial incarnation of schema

Re: HTTP Response for PUT vs POST

+1. I think that the only information that leaks is information about the implementation, that can be inferred by reading the source anyway, right? On Thu, May 29, 2014 at 1:14 PM, John Meinel wrote: > We currently have a test that we get 401 Unauthorized when you try to do a > PUT instead of

Re: HTTP Response for PUT vs POST

It also returns a "text/plain" response rather than an application/json one. So we aren't actually encoding the error into a JSON response. I can workaround the Post vs Put stuff by just registering all handlers and leaving the code in place that just checks for only POST, but it seemed a bit of a

HTTP Response for PUT vs POST

We currently have a test that we get 401 Unauthorized when you try to do a PUT instead of a POST for stuff like trying to push up Tools, etc. However, HTTP Spec seems to have a 405 Method Not Allowed, which is meant to handle this case of PUT isn't allowed, but POST would be. I'm looking into cha

Re: Not logging jenv data

We also need to sanitize the actual debug log messages (not just the first one during bootstrap), because all agents end up reporting their passwords via the API, as well as users, etc. So it isn't *just* sanitizing this one message. Though I also agree that I've definitely been aided by looking at

Re: Replica sets re-enabled for local provider

On Thu, May 29, 2014 at 5:18 PM, John Meinel wrote: > Didn't we find that things started breaking on Precise? > It wasn't precise only (at least before it wasn't). Ian was having issues on Trusty. > John > =:-> > > > On Wed, May 28, 2014 at 6:05 PM, Michael Foord < > michael.fo...@canonical.co

Re: Replica sets re-enabled for local provider

Didn't we find that things started breaking on Precise? John =:-> On Wed, May 28, 2014 at 6:05 PM, Michael Foord wrote: > Hey all, > > When we switched to replica sets we explicitly disabled them for the local > provider because it caused mongo to fail to start for "some people". It > turns ou

Re: Sharing environments - a proposal

On Thu, May 29, 2014 at 7:46 AM, Tim Penhey wrote: > > In the future we will have servers that we can connect to over the API > where the connections are over SSL with signed certificates, and so the > client will not need a client-cert for authenticated connections. > > So in that world, we would

Re: critical regression blocks 1.19.3 release

On 28/05/14 21:54, Curtis Hovey-Canonical wrote: I don't think we can do a release this week, or if we do, the release will be from a version that works from last week. The current blocker is lp:juju-core r2803 or lp:juju-core r2804 broke local precise deployments. Juju cannot bootst

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

On 28 May 2014 19:40, Nate Finch wrote: > I think the main problem with errgo as it exists, is that it is very awkward > to allow error type information to pass through: > > return errgo.Mask(err, errgo.Any) > > This line is very misleading. It's saying - mask the error type, except > wait,

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

On 29 May 2014 04:03, Tim Penhey wrote: > On 29/05/14 01:11, roger peppe wrote: >> Writing code to explicitly declare function return types is also >> a perpetual drag on refactoring, but it's also incredibly useful. >> >> The set of possible returned errors *should* be part of the contract >> of