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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
