Folks, I just wanted to share my experience with Juju during the last few months using it for real at work. I know it's pretty long but stay with me as I wanted to see if some of these points are bugs, design decisions or if we could simply to talk about them :-)
General: 1. Seems that if you happen to have more than... say, 30 machines, Juju starts behaving weirdly until you remove unused machines. One of the weird things is that new deploys all stay stuck with a pending status. That happened at least 4 times, so now I always destroy-environment when testing things just in case. Have anyone else seen this behaviour? Can this because of LXC with Juju local? I do a lot of Juju testing so it's not usual for me to have a couple hundreds of machines after a mont by the way. 2. It's not reliable to use Juju in laptops, which I can understand why of course but just in case... if the system is suspended Juju will not recover itself like the rest of the system services. It looses its connection from its API apparently? Hooks fail too (resuming always seems to call hooks/config-changed)? Is this just with me? 3. The docs recommend writing charms in Python versus shell script. Compared to Python they are subpar enough that I'd recommend saying they are not officially supported then. It's quite common to have race conditions in charms written in shell script. You have to keep polling the status of things because if you just call deploys and set relations in a row they will fail, because Juju won't queue the commands in a logical sequence, it'll just run them dumbly and developers are left in the wild to control it. I'm assuming a Python charm does not have this problem at all? 4. It's not very clear how many times hooks/config-changed runs to me, I'd just guess many :-) so you have to pay attention to it and write extra checks to avoid multiple harmful runs of this hook. I'd say the sequence and number of hooks called by a new deploy is not very clear based on the documentation because of this. Hmm perhaps I could print debug it and count the hits... 5. Juju should queue multiple deployment in order not to hurt performance, both of disk and network IO. More than 3 deployments in parallel on my machine makes it all really slow. I just leave Juju for a while and go get some coffee because the system goes crazy. Or I have to break up manually the deployments, while Juju could have just queued it all and the CLI could simply display it as "queued" instead. I know it would need to analyse the machine's hardware to guess a number different from 3 but think about it if your deployments have about 10 different services... things that take 20 minutes can easily take over 1 hour. 6. There is no way to know if a relation exists and if it's active or not, so you need to write dummy conditionals in your hooks to work around that. IMHO it's hackish to check variables that are only non-empty during a relation because they will vanish anyway. A command to list the currently set relations would be awesome to have, both inside the hooks and in the CLI. Perhaps charmhelpers.core.services.helpers.RelationContext could be used for this but I'm not totally sure as you only get the relation data and you need to know the relation name in advance anyway, right? 7. When a hook fails (most usually during relations being set) I have to manually run resolved unit/0 multiple times. It's not enough to call it once and wait for Juju to get it straight. I have to babysit the unit and keep running resolved unit/0, while I imagined this should be automatic because I wanted it resolved for real anyway. If the failed hook was the first in a chain, you'll have to re-run this for every other hook in the sequence. Once for a relation, another for config-changed, then perhaps another for the stop hook and another one for start hook, depending on your setup. 8. Do we have to monitor and wait a relation variable to be set? I've noticed that sometimes I want to get its value right away in the relation hook but it's not assigned yet by the other service. So I'm finding myself adding sleep commands when it happens, and that's quite hackish I think? IMHO the command to get a variable from a relation should be blocking until a value is returned so the charm doesn't have any timing issues. I see that happening with rabbitmq-server's charm all the time, for instance. 9. If you want to cancel a deployment that just started you need to keep running remove-service forever. Juju will simply ignore you if it's still running some special bits of the charm or if you have previously asked it to cancel the deployment during its setting up. No errors, no other messages are printed. You need to actually open its log to see that it's still stuck in a long apt-get installation and you have to wait until the right moment to remove-service again. And if your connection is slow, that takes time, you'll have to babysit Juju here because it doesn't really control its services as I imagined. Somehow apt-get gets what it wants :-) 10. I think there's something weird about relation-set and relation-get between services when you add and remove relations multiple times. For example, the first time I set a relation to a Postgres charm I get a database back and my desired roles configured, but if I remove the relation and then add it back I only get the database settings. The roles parameter is missing setup, so I don't have the right permissions in the DB the second time I set the relation. Anyone has seen this too with other charms? Juju GUI: 11. Juju's GUI's bells and whistles are nice, but I think there's a bug with it because its statuses are inaccurate. If you set a relation, Juju says the relation is green and active immediately, which is not true if you keep tailing the log file and you know things can still fail because scripts are still running. 12. Cancelling actions on Juju's GUI does not make much sense since you need to click on commit, then click on clear, then confirm it. Why not simply having a different cancel button instead? It's like shutting down Windows from the start menu. The cancel button should cancel the action, and the actual X button should simply dismiss it. That clear button seems useless UX-wise? 13. Juju's GUI's panel with charmstore stays open all the time wasting window space (so I have to zoom out virtually all my deployments because of the amount of wasted space, every time). There could be a way to hide that panel, because honestly it's useless locally since it never lists my local charms even if I export JUJU_REPOSITORY correctly. I'd rather have my local charms listed there too or just hide the panel instead. 13. Juju's GUI shows new relations info incorrectly. If I set up a DB relation to my service it simply says in the confirmation window that "db relation added between postgresql and postgresql". I've noticed sometimes this changes to "between myservice and myservice" so perhaps it has to do with the order of the relation, from what service to the other? Anyway, both cases seem to show it wrong? 14. Juju's GUI always shows the service panel even if the service unit has been destroyed, just because I opened it once. Also, it says "1 dying units" (sic) forever until I close it manually. 15. Why subordinate charms don't have a color bar beneath their icons too? Because if it fails then it will appear in red right? Why not always display it to indicate it's been correctly deployed or set up? 16. Juju's GUI lists all my machines. Like, all of them, really. In the added services part of the panel it lists even inactive machines, which does not make much sense I'd say because it makes it seem only deployed machines are listed. I think that count is wrong. That's it, thank you for those who made it to the end :-D
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju