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.hard...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
