Thoughts about Juju local as Dev

[José Antonio Rey]

Hey Sebas!

Thanks for pointing out all of this. It is great to see people pitching
in to gather feedback on where things can go better in both the
production and development areas.

As for your last point, the DHX plugin now exists, which will help you
do everything you do manually but automatically. All changes that are
made on the remote host are copied automatically to your machine. You
can check more about the DHX plugin here:
https://github.com/juju/plugins/blob/master/juju-dhx

On 12/04/2014 08:54 PM, Sebastian wrote:
> 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.
> 
> 
> 

-- 
José Antonio Rey