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 also a demo bundle seeded with sample data, to do this I'd need to run some actions behind the scenes to get the stuff in place which I can't do 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 to a place you define.
Tom -------------- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> goal, but you can always help by sponsoring the project <http://www.meteorite.bi/products/saiku/sponsorship>) On 16 March 2016 at 16:03, roger peppe <[email protected]> wrote: > On 16 March 2016 at 15:04, Kapil Thangavelu <[email protected]> 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 consumer service. > > Great, I hoped that's what you meant. > I'm also +1 on this feature - it would enable all kinds of useful > flexibility. > > One recent example I've come across that could use this feature > is that we've got a service that can hand out credentials to services > that are related to it. At the moment the only way to state that > certain services should be handed certain classes of credential > is to have a config value that holds a map of service name to > credential info, which doesn't seem great - it's awkward, easy > to get wrong, and when a service goes away, its associated info > hangs around. > > Having the credential info associated with the relation itself would be > perfect. > > > > > On Wed, Mar 16, 2016 at 9:17 AM roger peppe <[email protected]> > > wrote: > >> > >> On 16 March 2016 at 12:31, Kapil Thangavelu <[email protected]> wrote: > >> > > >> > > >> > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <[email protected]> > >> > 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 > >> >> priorities - feel free to reply on-list or to me privately. > >> >> > >> >> An early cut of topics of interest is below. > >> >> > >> >> Operational concerns > >> >> > >> >> * LDAP integration for Juju controllers now we have multi-user > >> >> controllers > >> >> * Support for read-only config > >> >> * Support for things like passwords being disclosed to a subset of > >> >> user/operators > >> >> * LXD container migration > >> >> * Shared uncommitted state - enable people to collaborate around > >> >> changes > >> >> they want to make in a model > >> >> > >> >> There has also been quite a lot of interest in log control - debug > >> >> settings for logging, verbosity control, and log redirection as a > >> >> systemic > >> >> property. This might be a good area for someone new to the project to > >> >> lead > >> >> design and implementation. Another similar area is the idea of > >> >> modelling > >> >> machine properties - things like apt / yum repositories, cache > settings > >> >> etc, > >> >> and having the machine agent setup the machine / vm / container > >> >> according to > >> >> those properties. > >> >> > >> > > >> > ldap++. as brought up in the user list better support for aws best > >> > practice > >> > credential management, ie. bootstrapping with transient credentials > (sts > >> > role assume, needs AWS_SECURITY_TOKEN support), and instance role for > >> > state > >> > servers. > >> > > >> > > >> >> > >> >> Core Model > >> >> > >> >> * modelling individual services (i.e. each database exported by the > db > >> >> application) > >> >> * rich status (properties of those services and the application > >> >> itself) > >> >> * config schemas and validation > >> >> * relation config > >> >> > >> >> There is also interest in being able to invoke actions across a > >> >> relation > >> >> when the relation interface declares them. This would allow, for > >> >> example, a > >> >> benchmark operator charm to trigger benchmarks through a relation > >> >> rather > >> >> than having the operator do it manually. > >> >> > >> > > >> > in priority order, relation config > >> > >> What do you understand by the term "relation config"? > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
