Re: Planning for Juju 2.2 (16.10 timeframe)

On 9 March 2016 at 06:51, Mark Shuttleworth wrote: > Hi folks > > We're starting to think about the next development cycle, and gathering > priorities and requests from users of Juju. I'm writing to outline some > current topics and also to invite requests or thoughts on relative

Re: Planning for Juju 2.2 (16.10 timeframe)

On 9 March 2016 at 06:51, Mark Shuttleworth wrote: > Hi folks > > We're starting to think about the next development cycle, and gathering > priorities and requests from users of Juju. I'm writing to outline some > current topics and also to invite requests or thoughts on relative

Re: Planning for Juju 2.2 (16.10 timeframe)

+1 for DNS as this was request in other community project as well which uses JUJU. Thanks and Regards, Narinder Gupta (PMP) narinder.gu...@canonical.com Canonical, Ltd.narindergupta [irc.freenode.net] +1.281.736.5150

Re: Planning for Juju 2.2 (16.10 timeframe)

Lots of interesting ideas here. Some other ideas (apologies if these have already been proposed, but I don't *think* they have) a) A small one - please can we have 'juju get '? See https://bugs.launchpad.net/juju-core/+bug/1423548 Maybe this is already in the config schema work, but it would

Re: Planning for Juju 2.2 (16.10 timeframe)

On 1 April 2016 at 20:50, Mark Shuttleworth wrote: > On 19/03/16 01:02, Stuart Bishop wrote: >> On 9 March 2016 at 10:51, Mark Shuttleworth wrote: >> >>> Operational concerns >> I still want 'juju-wait' as a supported, builtin command rather than >> as a fragile

Re: Planning for Juju 2.2 (16.10 timeframe)

On 1 April 2016 at 20:50, Mark Shuttleworth wrote: > On 19/03/16 01:02, Stuart Bishop wrote: >> On 9 March 2016 at 10:51, Mark Shuttleworth wrote: >> >>> Operational concerns >> I still want 'juju-wait' as a supported, builtin command rather than >> as a fragile

Re: Planning for Juju 2.2 (16.10 timeframe)

On 01/04/16 14:34, Mark Shuttleworth wrote: > >> * cli for storage is not as nice as other juju commands. For example we >> have the in the docs: >> >> juju deploy cs:~axwalk/postgresql --storage data=ebs-ssd,10G pg-ssd >> >> I suspect most charms will use single storage device so it may be >>

Re: Planning for Juju 2.2 (16.10 timeframe)

On 19/03/16 01:02, Stuart Bishop wrote: > On 9 March 2016 at 10:51, Mark Shuttleworth wrote: > >> Operational concerns > I still want 'juju-wait' as a supported, builtin command rather than > as a fragile plugin I maintain and as code embedded in Amulet that the > ecosystem team

Re: Planning for Juju 2.2 (16.10 timeframe)

ator > Liferay, Inc. > Enterprise. Open Source. For life. > > From: Mark Shuttleworth <m...@ubuntu.com> > >> Date: Tue, Mar 8, 2016 at 6:52 PM >> Subject: Planning for Juju 2.2 (16.10 timeframe) >> To: juju <j...@lists.ubuntu.com>, juju-dev@lists.ubunt

Storage documentation (Was "Re: Planning for Juju 2.2 (16.10 timeframe)")

Just changed subject so we don't derail the 2.2 discussion. On Tue, Mar 29, 2016 at 6:27 PM Jacek Nykis wrote: > On 19/03/16 03:20, Andrew Wilkins wrote: > > It seems like the issues you've noted below are all documentation issues, > > rather than limitations in the

Re: Planning for Juju 2.2 (16.10 timeframe)

On 19/03/16 03:20, Andrew Wilkins wrote: > It seems like the issues you've noted below are all documentation issues, > rather than limitations in the implementation. Please correct me if I'm > wrong. > > >> If we come up with sensible defaults for different providers we could >> make end users'

Re: Planning for Juju 2.2 (16.10 timeframe)

. For life. From: Mark Shuttleworth <m...@ubuntu.com> > Date: Tue, Mar 8, 2016 at 6:52 PM > Subject: Planning for Juju 2.2 (16.10 timeframe) > To: juju <juju@lists.ubuntu.com>, juju-...@lists.ubuntu.com < > juju-...@lists.ubuntu.com> > > > Hi folks >

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 12:31, Kapil Thangavelu wrote: > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: >> >> Hi folks >> >> We're starting to think about the next development cycle, and gathering >> priorities and requests from users of Juju. I'm

Re: Planning for Juju 2.2 (16.10 timeframe)

Here's another one, which I can't find in the docs, but apologies if it exists. It would be good to be able to specify allowed origin IPs for juju expose for cloud types that support it. For example in EC2 instead of allowing 0.0.0.0 allow a specific address or range. But also expand that

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 15:04, Kapil Thangavelu wrote: > Relations have associated config schemas that can be set by the user > creating the relation. I.e. I could run one autoscaling service and > associate with relation config for autoscale options to the relation with a > given

Re: Planning for Juju 2.2 (16.10 timeframe)

Couple of new things cropped up today that would be very useful. a) actions within gui, currently its a bit weird to drag stuff around in the gui then drop to shell to run actions. Doesn't make much sense to a user. b) actions within bundles. For example, I'd like a few "standard" bundles, but

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 23:51, Mark Shuttleworth wrote: > *Storage* > > * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts) > * object storage abstraction (probably just mapping to S3-compatible APIS) > > I'm interested in feedback on the operations aspects of storage. For > example, whether it

Re: Planning for Juju 2.2 (16.10 timeframe)

On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: > Hi folks > > We're starting to think about the next development cycle, and gathering > priorities and requests from users of Juju. I'm writing to outline some > current topics and also to invite requests or thoughts on

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 12:31, Kapil Thangavelu wrote: > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: >> >> Hi folks >> >> We're starting to think about the next development cycle, and gathering >> priorities and requests from users of Juju. I'm

Re: Planning for Juju 2.2 (16.10 timeframe)

On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: > Hi folks > > We're starting to think about the next development cycle, and gathering > priorities and requests from users of Juju. I'm writing to outline some > current topics and also to invite requests or thoughts on

Re: Planning for Juju 2.2 (16.10 timeframe)

Yeah, I guess that would be a good solution for sample data and stuff. Doesn't work for user defined bits and pieces though. For actions we current "cat" the content into a parameter, but of course that doesn't work for everything, and really really sucks when you try and cat unescaped JSON into

Re: Planning for Juju 2.2 (16.10 timeframe)

On Fri, Mar 18, 2016 at 8:57 AM, Tom Barber wrote: > c) upload files with actions. Currently for some things I need to pass in > some files then trigger an action on the unit upon that file. It would be > good to say path=/tmp/myfile.xyz and have the action upload that

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 15:04, Kapil Thangavelu wrote: > Relations have associated config schemas that can be set by the user > creating the relation. I.e. I could run one autoscaling service and > associate with relation config for autoscale options to the relation with a > given

Re: Planning for Juju 2.2 (16.10 timeframe)

Another one bundle inheritance. For example I want to create a saiku bundle, that uses a sharded mongodb setup, I import the bundle and attach saiku to it and deploy that. Why not let me reference it like layers and import it so if changes are made to the original bundle I get their goodness

Re: Planning for Juju 2.2 (16.10 timeframe)

On 9 March 2016 at 10:51, Mark Shuttleworth wrote: > Operational concerns I still want 'juju-wait' as a supported, builtin command rather than as a fragile plugin I maintain and as code embedded in Amulet that the ecosystem team maintain. A thoughtless change to Juju's status

Re: Planning for Juju 2.2 (16.10 timeframe)

On Sat, Mar 19, 2016 at 12:53 AM Jacek Nykis wrote: > On 08/03/16 23:51, Mark Shuttleworth wrote: > > *Storage* > > > > * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts) > > * object storage abstraction (probably just mapping to S3-compatible > APIS) > >

Re: Planning for Juju 2.2 (16.10 timeframe)

On Fri, Mar 18, 2016 at 8:57 AM, Tom Barber wrote: > c) upload files with actions. Currently for some things I need to pass in > some files then trigger an action on the unit upon that file. It would be > good to say path=/tmp/myfile.xyz and have the action upload that

Re: Planning for Juju 2.2 (16.10 timeframe)

Mark, It is very exciting to see this list of future feature topics! I feel these are all very legitimate feature topics, and of the feature topics you have listed, the operational concerns will definitely help to continue to solidify an enterprise-y feature set within the Juju ecosystem, which,

Fwd: Planning for Juju 2.2 (16.10 timeframe)

+1 for invoking actions from relations. I'd also really like to have the ability to change config values from relations. An example of this is my dhcp server. The network it should broadcast to started out as a config value. Now, other Charms in my setup are becoming smarter so they can pass the

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 16:04, Tom Barber wrote: > Also, for stuff like monitoring, being able to position a charm service on > a different service provider to bolster resiliency. That comes implicitly with cross-model relations, since the different models can be on different clouds. This enables pretty

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 15:59, Tom Barber wrote: > From my perspective relationship joins that can span models would be great. > I know I brought it up before, but being able to create, for example a > central monitoring model, or central Gitlab model that charms in my various > other models could tap into

Re: Planning for Juju 2.2 (16.10 timeframe)

Also, for stuff like monitoring, being able to position a charm service on a different service provider to bolster resiliency. Tom On 8 Mar 2016 23:59, "Tom Barber" wrote: > Hi Mark > > From my perspective relationship joins that can span models would be > great. I

Re: Planning for Juju 2.2 (16.10 timeframe)

Hi Mark >From my perspective relationship joins that can span models would be great. I know I brought it up before, but being able to create, for example a central monitoring model, or central Gitlab model that charms in my various other models could tap into without them being merged into a

Planning for Juju 2.2 (16.10 timeframe)

Hi folks We're starting to think about the next development cycle, and gathering priorities and requests from users of Juju. I'm writing to outline some current topics and also to invite requests or thoughts on relative priorities - feel free to reply on-list or to me privately. An early cut of