Re: I want to understand this juju charm innovation properly —

Dmitrii Shcherbakov dmitrii.shcherbakov at canonical.com
Mon Jul 17 23:32:22 UTC 2017


Hi Simon,

Answers inline.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Mon, Jul 17, 2017 at 4:44 AM, Simon Lafrenière <
simon.lafreniere09 at gmail.com> wrote:

> Hey,
>
> This seems like a good initiative. I want to know more.
>

Good stuff.


>
> If someone could explain to me for what reason I could get paid using juju
> charms that would help me understand what I could do with this for clients.
>

The idea might be that you would sell Juju models: could be an entire
architecture comprised of multiple related applications on multiple
machines instead of just having images with templates.

It used to be the same with software on a single machine: at first we had
flat assembly language code, then high-level languages, static libraries,
loadable dynamic libraries (which could be used by multiple processes on
the same host). But now we need to model connections and data exchange on
different hosts - cannot just ship a single package with libraries anymore
for it to be enough.

---

JAAS is getting there in a certain way for providing hosted Juju
controllers for you to be able to use models on different public clouds
without having your own infrastructure.
https://jujucharms.com/jaas

In terms of providing models and services related to them, I think Spicule
is a good example to look at.
http://spicule.co.uk/2017/07/07/data-processing-with-spicule-data-engine/
https://youtu.be/WNs5vA3Pljg?t=1251
https://www.youtube.com/watch?v=akpiHie0QEs

https://lists.ubuntu.com/archives/juju/2017-April/008887.html

You could also do charm maintenance services: e.g. if a customer wants to
have a certain functionality in charms and wants continuous support with
new versions released, tests etc. you could easily qualify this as an
engineering effort which should be paid for.

---

In essence, Juju itself is a client-server type of software to remotely
execute arbitrary code based upon certain events and send data across
different agents on used machines.

https://github.com/juju/juju/blob/develop/doc/architectural-overview.md#
juju-components

The other part is charms which is that arbitrary code that gets executed
and acquires certain context from Juju about a particular event that
triggered the execution.

This is what is called the 'operational' code that does everything you
would do manually in an alternative situation. The difference between
one-shot deployment tools is that charms are executed based on different
lifecycle events and are applications in a certain sense: they can get
quite complex in handling config changes, relation events, upgrade events,
periodic update status events, storage events and leadership events.

https://jujucharms.com/docs/2.2/developer-event-cycle#hook-event-cycle

This is where, as a developer or a company you can bring in your expertise
in providing the right application-specific operational code to manage
applications or models that customers need. Juju will not do that for you
on its own - it is a system that allows you to do it via the primitives it
provides but all of the application-specific work is coded in a charm.

>From a charm developer's point of view you see this: Juju agent -> executes
a file with an event name (can be anything really in terms of a programming
language) -> control gets to your own code.

What is used a lot now:

classic charms: Juju agent -> *hooks.py file -> a decorated function gets
executed + charm-helpers library + your own library code calls
reactive charms: Juju agent -> charms.reactive main function -> hooks and
reactive handlers + charm-helpers library + your own library code calls


I am oversimplifying because there are other features out there but this is
the most basic thing to realize.

If you need an analogy, Juju would be similar to a complex responsive GUI
application:

- you have a main loop that decides which operation to do next (e.g. a user
clicked a button, or pressed something on a keyboard so you need to handle
that)
- events have custom handlers that act upon them in a custom way

You could also compare Juju to an MVC type of application but more
distributed as there are many machines involved.

For a single unit, it could be something like that:

Model - a context you get from Juju and relation data;
View - a set of actions to perform on a target machine or configs to render;
Controller - a charm code that operates on the model's data to present a
view.


>
> I usually develop sites based on container images but I want to know for
> what else I could use this for.


> Are there lists of use cases and problems solved ?
>

If you have a single image with a template, you cannot model relations
between services easily. You just have a one-shot template rendering code
which prepares your container image but oftentimes this is not enough.

A simple example would be a desire to scale a model like this:

load-balancer -> web servers -> database backend

You could also add something like a charm that automatically gets a TLS
certificate from Let's Encrypt.

Things get more complicated if you want to deploy something like OpenStack
or Kubernetes.

This is a simple model of OpenStack (non-HA):
https://jujucharms.com/openstack-base/
k8s: https://jujucharms.com/canonical-kubernetes/

https://jujucharms.com/big-data
https://jujucharms.com/u/prometheus-charmers/prometheus/


>
> Can I power devices and do iot type of projects ?
>

I can't see why not. Juju is written in golang and is easy to run on any
operating system. Like I said before, Juju unit agents do remote code
execution and connect to a controller via TCP so no hard requirements in
terms of running code on IoT devices. The question is how small is the
target IoT device and how to provision those devices because Juju allocates
machines via a cloud API and with bare-metal servers we do it with MAAS
which in turn provisions via PXE boot over a network.

For IoT devices the provisioning scenario needs to be figured out if you
want to deploy charms onto IoT devices via Juju.

Although, if you only care about providing infrastructure for your IoT
devices and not using them as a management target for Juju you do not care
as much - just deploy your infra and point your devices at it.


>
> Is it about serving programs to user and teams of programmers ?
>

Not 'serving' in terms of just deployment - more like modeling and
operating which includes deployment.


>
> can I connect maker type electronic projects and charms so that my arduino
> or raspberry py get to execute code and produce outcomes ?
>

If you put a Juju agent there - yes.


>
> Who could I work with to experiment doing fun stuff with juju charms  ?
>

https://jujucharms.com/community

IRC channels at freenode.net

#juju
#juju-gui
#juju-dev


>
> Is there a list of videos of people showcasing their realizations with
> juju charms ?
>

You can have a look here:
https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

>
> Thank you for reading and good day !
>
>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170718/72bf397b/attachment.html>


More information about the Juju mailing list