Where is the Juju-gui heading ?

Matthew Williams matthew.williams at canonical.com
Wed Nov 12 17:24:43 UTC 2014


Hi Stein,

The friday session that Jose mentioned is this one:

http://summit.ubuntu.com/uos-1411/meeting/22387/whats-new-and-upcoming-in-the-work-of-juju-ui-engineering/

Thanks

Matty

On Wed, Nov 12, 2014 at 4:58 PM, Richard Harding <rick.harding at canonical.com
> wrote:

> On Wed, 12 Nov 2014, Stein Myrseth wrote:
>
> > In earlier versions of the Juju-gui it was easy and simple to deploy a
> > charm, by just dragging and dropping it into the canvas and hit commit.
> >
> > With the latest versions the same process it is no more intuitive how to
> > deploy anymore. I hit “confirm” and “commit” and nothing happens. I have
> > create a machine first, or auto place, or add the constraints or as part
> > of the unit configuration, or as part of the machine configuration to
> > create a machine and assign the unit etc. And the approach is different
> > if I do it from the CLI and UI.
> >
> >  To me this set the focus on two things. There will be two very distinct
> >  different user groups using Juju with different requirements.
> >
> >
> > 1) A charm designer/developers want to expose options for configuration
> >
> > 2) A charm consumer, want to add a “service” to his or her deployment and
> > is interested in a “serious relationships” :-)
> >
> >  The first category has all the data, info and knows all requirements
> >  needed for the charm regarding constraints etc.
> >
> >
> > The constraints are a part of my frustrations here. Today constraints are
> > detached from the charm, which to me does not make sense regarding the
> > two different target user groups. It’s detached in the UI on creation,
> > but can be assigned from the CLI, and also copied as a constraint on
> > export.
> >
> >  As a charm developer I would very much like to see the support of adding
> >  the constraints like RAM, cores etc. as part of the charm config itself.
> >  This could be added to either the config.yaml or in a separate
> >  constraints.yaml file as an option.
> >
> >
> >  In this way as a charm developer I have an option to enforce the
> >  constraints on deployment, either using the CLI or the UI. It could be
> >  easy to check on deployment (as done when deploying bundles) if there is
> >  available machine resource matching the constraints or if the user would
> >  like a new machine matching the constraints to be created automatically.
> >  The deployment part has become to complex, and involved to many steps
> >  for the charm consumer. For the consumer the machines, assigned units,
> >  where etc. are completely secondary. The consumer is looking for
> >  storage, db proxy service relation without the need to learn how Mongodb
> >  works. Thats’s my focus.
> >
> >
> >  So as
> >
> >
> > 1) As a charm developer I need a way to make the constraints of my charms
> > consistent across the different way of deploying.
> >
> > 2) As a charm consumer I don’t care about machines, only services and the
> > relationships provided and deploying should be simple.
> >
> >
> > What is the future plans and directions for the the UI, define
> > constraints and the easy of deployments ?
>
>
> Thanks for the feedback Stein. As was mentioned your concern with charm
> constraints is valid and something we've got on the list. We hit it all the
> time as things like Jenkins (go go java) don't like to run on the default
> small machines Juju uses out of the box. Having the charm author, who knows
> more than anyone what you need to operate, defined that in the
> charm level makes a lot of sense.
>
> As to the ease of getting something deployed, I think there's a different
> here. The GUI with machine view and the deployment bar is an attempt to
> help realize that people are not just going out and deploying a single
> thing. They're building a set of services that provide a complete solution
> for some infrastructure need. To help with that, and make it easier to do
> that work in total, we hold off on just 'hit deploy' so that the user can
> freely build out everything they want, build relations, set config, and
> really basically construct a custom bundle, before the tell Juju to go do
> anything.
>
> You don't mention the particular use case for the immediate deploy option.
> We have the ability to do that and perhaps what we want is a bit of both
> worlds.
>
> https://demo.jujucharms.com/?deploy-target=precise/mysql
>
> Is your use case primarily around using the GUi to manage your environment?
> Is it usually a speedy demo situation? If we gave you the option in the
> GUI config (you can get access to that via the ? key to set some config
> options) so that immediate deployment was a default behaviour for the demo
> would that help?
>
> I'd love to hear some more details on how you're using the GUI and when the
> extra deployment summary steps cause you pain and see if there's a good way
> to address them.
>
> Thanks again for the great feedback.
>
>
> --
>
> Rick Harding
>
> Juju UI Engineering
> https://launchpad.net/~rharding
> @mitechie
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20141112/2d9eb50d/attachment.html>


More information about the Juju mailing list