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 ? Stein Myrseth Bjørkesvingen 6J 3408 Tranby mob: +47 909 62 763 mailto:stein.myrs...@gmail.com
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
