Hey guys! I'm using Juju as a local environment a while now, and trying to implement Juju local a default workflow of our developers, which half of them have generally an Ubuntu (or at least based) and the other Mac OS X, but all are using the Vagrant workflow.
And I have to tell you, what a challenge. So here is some feedback as an application (and charm) developer: *Behold the Vagrant workflow* For some of the developers, this flow was terrible mysterious, only the list of things you have to install or know what does each and every software, here's the list: Vagrant and the download a box, Virtualbox, Juju, Juju-local, Juju-gui (yes, it's important to separate, client <> server <> gui), LXC and the containers paradigm, SSHFS (which is quite difficult in Mac OS X) to access and edit the files on the container, and finally the slow Sshuttle to access the containers via ssh from the host. Thats a lot to understand, so many things and we don't even start to explain how to use the charms, relations and stuff like the charm's hooks. So in the process, started to appear so many issues that we had to stop using it for a while, till it gets more dev-friendly. But we are trying again! and also trying to make things more easy. *Here are some suggestions:* *Accessing your app services:* Sshuttle is not the best solution, so let's use Virtualbox networking features. I created a private network interface (containerseth0), and then setting the networking configurations of the lxc container to it (containerseth0). That was one of the best solution I came up till now, but I know this is not the right way to do that, but I don't know that much about network bridges. *Download, install and configure = Waste* When you want to be more efficient, the first thing you have to identify is the waste and try to decrease it the best you can. For example, if I'm a Drupal developer that wants to start developing in a new or existent project he has to wait for download (apt-proxy this is being done right now I think), install all the dependencies and then configuring process, again, for the same service (charm). So, some ideia is to try to clone service unit (container) before the "started" status of the charm, so in that way whenever I want a new project I don't have to wait all of that, just the config-changed and start process. Today the only (not 100% sure) thing is being using cloning is with units scaling. *Why my machine is so slow!! /O\* Every developer have more than 2 projects cloned in their workspace, and that result in a lot of deployed running charms, with all their services like Nginx, Php-fpm, Varnish and MySQL. It's naturally that the machine and consequently the applications appear to be very slow, there's too many containers running at same time. The solution to this where not defined yet, but we are trying to: - Use one Vagrant VM for each project, but thats painfully when you must see other projects running. - Manually turning off all the containers using lxc-stop, which is other painfully process. - Parallel local type environments, so it's an env for each project, but that needs tweeks to avoid ports conflicts and still we had to manually stop/start all the containers. So we didn't figure it out yet. *juju set mysql dataset-size="20%"* Fuuuu.... why MySQL isn't starting? Telling to the developers and making predefined bundles and config files, was not enough, they forgot about to set the MySQL dataset-size when are working in a local environment. The charms could react better to the environments types. *Charm's development is a slow and a complex process* You are developing a complex charm and guess what? error in the logs, the charm's deploy failed, then you modify the charm code and repeat the hall process all over again. This is the workflow today if you don't know other approaches, for example: - Connect to the service unit via ssh, then find the charm's code in the server, and then edit it in Vi or Nano and retry. And if it works, you will have to remember to replicate all your changes into your beautiful versioned source code. Which generally is in GitHub, so go learn how to mix bzr and git, because you are gonna need it if you want to put your charm in the charm store. - Since you are using linux containers, you can create a symbolic link between your source code and where the charm code must to be into the container's juju agent (/var/lib/juju/...). But! this doesn't work, and I currently don't know why. - I wish to know if there's another better way... I hope that everyone understand this feedback as what it is, a feedback, a part of the process of continues improvement. In other words, I'm just trying to help :) It's not the end, I have more feedbacks about this awesome experience. Cheers!, Sebas.
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
