Where is the Juju-gui heading ?

[Richard Harding]

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