Re: 16.07 OpenStack charm release

Hi, Congrats! I'm not sure if it's possible, but it would be nice if we could receive the future announcements in openstack-annouce as well: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce 2016-07-29 4:20 GMT+09:00 David Ames : > Hi All > > We

Re: 16.07 OpenStack charm release

Hi OpenStack charm team, Many thanks for your information about the new release. There is one question about deploying OpenStack by juju charm. What version of MAAS & Juju should we use to deploy new OpenStack charm? MAAS 1.9.3 + Juju 1.25.6 ? MAAS 1.9.3 + Juju 2.0 Beta 13 ? MAAS 2.0 RC2 +

16.07 OpenStack charm release

Hi All We are pleased to announce the 16.07 release of the OpenStack charms. Highlights include: * Nova compute apparmor support (Preview) * openstack-dashboard + Keystone v3 API support * SR-IOV (Preview) * External Network Update * DNS HA (Preview) * Enhancements to Ceph charms * New Charm:

Re: Schema for Juju RPC messages

On 28 July 2016 at 15:11, Mark Shuttleworth wrote: > On 28/07/16 13:47, roger peppe wrote: >> I agree with that. But we're talking about sugar here, I think. Added >> sugar doesn't *necessarily* imply a cleaner, less messy or better >> articulated component IMHO. That's one of

Re: Schema for Juju RPC messages

On 28/07/16 13:47, roger peppe wrote: > I agree with that. But we're talking about sugar here, I think. Added > sugar doesn't *necessarily* imply a cleaner, less messy or better > articulated component IMHO. That's one of the reasons I like Go - more > layers of abstraction can make things harder

Re: Schema for Juju RPC messages

On 28 July 2016 at 12:12, Mark Shuttleworth wrote: > On 28/07/16 12:57, roger peppe wrote: >> On 28 July 2016 at 10:01, Mark Shuttleworth wrote: >>> On 28/07/16 10:42, roger peppe wrote: On 28 July 2016 at 01:07, Rick Harding

Re: Interactive bootstrap has landed

On 28/07/16 11:39, John Meinel wrote: > AIUI, the idea is that if you are not supplying the bootstrap target, > then we don't know what you want to create, so we might as well ask. > If you start supplying arguments (even incomplete ones), then we'll > expect that you were intending to tell us,

Re: Schema for Juju RPC messages

On 28/07/16 12:57, roger peppe wrote: > On 28 July 2016 at 10:01, Mark Shuttleworth wrote: >> On 28/07/16 10:42, roger peppe wrote: >>> On 28 July 2016 at 01:07, Rick Harding wrote: However, an API client in any language should never be auto

Re: Schema for Juju RPC messages

On 28 July 2016 at 10:33, John Meinel wrote: > ... >> >> >> FWIW there is a proposal for strict field checking in the Go >> encoding/json package (https://github.com/golang/go/issues/15314) >> which would fix the specific issue raised at the start of this thread. >> It's

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

On 28 July 2016 at 18:01, John Meinel wrote: > Shouldn't we have a Mongo 3.2 client in /usr/lib/juju/* on Xenial? I think > the specific directory includes the Mongo version (the 2.4 ones were > /usr/lib/juju/bin/mongo IIRC) Only in -proposed, see

Re: Interactive bootstrap has landed

AIUI, the idea is that if you are not supplying the bootstrap target, then we don't know what you want to create, so we might as well ask. If you start supplying arguments (even incomplete ones), then we'll expect that you were intending to tell us, and we'll succeed/fail and give an error about

Re: Schema for Juju RPC messages

... > I actually think that local charm upload is different enough that it > justifies a separate entry point. I agree that AddCharmWithAuthorization > should be folded into AddCharm though. > FWIW, I'm pretty sure we have 2 APIs because someone didn't want to bump the API version to add some

Re: Schema for Juju RPC messages

... > > FWIW there is a proposal for strict field checking in the Go > encoding/json package (https://github.com/golang/go/issues/15314) > which would fix the specific issue raised at the start of this thread. > It's trivial to add that feature (4 lines of code) and pending Go 1.8, > we could

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:25, Rick Harding wrote: > My understanding is that we need three distinct calls in the API because of > Go and the way that these things need to be declared/defined. Actually, it would be perfectly possible in Go for there to be only a single

Re: Schema for Juju RPC messages

On 28/07/16 10:42, roger peppe wrote: > On 28 July 2016 at 01:07, Rick Harding wrote: >> However, an API client in any language should never be auto generated. > This is a strong statement. I feel that, as with most things in > software engineering, > there's a

Re: Apache Aria

Thanks Nicolas, thats a really interesting plan! Looking forward to find out more. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:07, Rick Harding wrote: > However, an API client in any language should never be auto generated. This is a strong statement. I feel that, as with most things in software engineering, there's a trade-off. Personally I'm with Katherine "use the

Re: Schema for Juju RPC messages

On 28/07/16 05:30, Tim Penhey wrote: > Just doing this would catch the typos of keys, and would also make us > be more strict in the "I'll just add this extra field" to existing > facade versions, as they could then fail with older versions of the > server with "unknown field" type errors.

Re: Schema for Juju RPC messages

On Wed, Jul 27, 2016 at 8:25 PM Rick Harding wrote: > That being said, any API client that requires three API calls to login >> should be beat over the head with a fail stick, but there are many cases >> where performing some workflow might require multiple api calls.

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

Shouldn't we have a Mongo 3.2 client in /usr/lib/juju/* on Xenial? I think the specific directory includes the Mongo version (the 2.4 ones were /usr/lib/juju/bin/mongo IIRC) John =:-> On Jul 28, 2016 05:11, "Menno Smits" wrote: > Nice. I'd suggest 2 things: > >-