add workflows for charm development

[sed-i]

This PR introduces one new workflow:

• charm-dev, which brings up a complete juju environment (controller + model) ready to go so one could juju deploy right away, in line with the official docs. In addition, it sets swappiness to zero and disables a few resource-consuming services, which makes the instance better suited for use in load tests. The juju plugin for ohmyzsh is included as well.

Resolves #4.

[sed-i]

@Saviq, could this kind of workflow be considered for a merge? It still a draft but I'm wondering if it is not too specific to be listed on everyone's multipass find.

[Saviq]

@sed-i hey, one of the ideas behind workflows is helping discoverability, so certainly showcasing Juju fits the bill :)

It could be both a developer environment and a demo in one, right? Like the simplest way to try Juju locally on all platforms?

[sed-i]

Yes @Saviq, the idea is to have a controller + model ready to go so one could juju deploy right away.

[Saviq]

Yes @Saviq, the idea is to have a controller + model ready to go so one could juju deploy right away.

The only thing I always struggled with a local cloud was exposing services. Can Juju expose apps deployed in containers on the outside interface?

[sed-i]

I think this is ready for review, @Saviq . @jnsgruk and @rbarry82 may have some valuable input as well.

The only hiccup is that launch timeouts before the specified timeout: 900 so I have to manually watch for /var/log/cloud-init.log to know when it is really finished.

[Saviq]

@sed-i that's what timeout: is for - set it to something sane for the amount of work this workflow has.

But yeah canonical/multipass#1039 discusses how to improve this regardless of the timeout.

[sed-i]

Yes, understood, but the issue I have is:

1. the measured time to completely finish a workflow is under 15 min
2. the launch timeouts before the specified 900 seconds (15 min) - I think it times out ~5 min after launch is invoked
3. no matter what I set timeout to (even 10,000), it still timeouts - that's why I filed https://github.com/canonical/multipass/issues/2313

[Saviq]

Yes, understood, but the issue I have is:

1. the measured time to completely finish a workflow is under 15 min
2. the launch timeouts before the specified 900 seconds (15 min) - I think it times out ~5 min after launch is invoked
3. no matter what I set timeout to (even 10,000), it still timeouts - that's why I filed launch command to display time elapsed and/or remaining multipass#2313

Hmm. Need a slower machine…

$ time multipass launch charm-dev
Launched: charm-dev
multipass launch charm-dev  0,08s user 0,11s system 0% cpu 7:14,31 total

###

# ...
Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:final' at Wed, 27 Oct 2021 13:31:16 +0000. Up 115.69 seconds.
The system is finally up, after 424.67 seconds

How about if you go multipass launch --timeout 900?

(sorry for closing, fat fingers)

[sed-i]

In my case it timeouts after ~5min but the full workflow successfully completes after ~10min (654 sec, see below).

$ time multipass launch charm-dev -n try13
launch failed: The following errors occurred:                                   
timed out waiting for initialization to complete
multipass launch charm-dev -n try13  0.11s user 0.09s system 0% cpu 5:15.68 total

# /var/log/cloud-init.log
2021-10-27 14:55:42,497 - util.py[DEBUG]: cloud-init mode 'init' took 0.483 seconds (0.49)
2021-10-27 14:55:47,063 - util.py[DEBUG]: resize_devices took 0.704 seconds
2021-10-27 14:55:47,245 - util.py[DEBUG]: Resizing took 0.177 seconds
2021-10-27 14:55:47,500 - util.py[DEBUG]: cloud-init mode 'init' took 1.333 seconds (1.33)
2021-10-27 14:55:51,869 - util.py[DEBUG]: Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:config' at Wed, 27 Oct 2021 14:55:51 +0000. Up 14.87 seconds.
2021-10-27 14:55:51,886 - cc_emit_upstart.py[DEBUG]: not upstart system, 'emit_upstart' disabled
2021-10-27 14:59:41,472 - util.py[DEBUG]: cloud-init mode 'modules' took 229.667 seconds (229.66)
2021-10-27 14:59:41,839 - util.py[DEBUG]: Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:final' at Wed, 27 Oct 2021 14:59:41 +0000. Up 244.84 seconds.
2021-10-27 15:06:30,936 - util.py[DEBUG]: The system is finally up, after 654.00 seconds
2021-10-27 15:06:30,939 - util.py[DEBUG]: cloud-init mode 'modules' took 409.164 seconds (409.16)
2021-10-27 15:06:33,349 - util.py[DEBUG]: cloud-init mode 'hotplug-hook' took 0.031 seconds (0.03)
2021-10-27 15:06:35,991 - util.py[DEBUG]: cloud-init mode 'hotplug-hook' took 0.041 seconds (0.04)

# /var/log/cloud-init-output.log
Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:final' at Wed, 27 Oct 2021 14:59:41 +0000. Up 244.84 seconds.
The system is finally up, after 654.00 seconds

However, --timeout 900 as cli arg works. Maybe the yaml spec is documented incorrectly?

[Saviq]

However, --timeout 900 as cli arg works. Maybe the yaml spec is documented incorrectly?

More like we have a bug and ignore the timeout: 900 from the workflow… Will investigate :)

[rbarry82]

I like this in general, though I worry about the reported conflict between docker and LXD. Is there a bug reported for that somewhere? This seems like something which needs a fix above and beyond a multipass profile.

That said, there are some other things which could be done here. Instead of sleep 180, you can absolutely use shell semantics, though it would be an awfully long/ugly oneliner.

sh -c 'while true; do...

Really, it would be better to template the script somewhere in /tmp and execute it directly from runcmd, though, for readability. I'll leave some comments inline.

[sed-i]

@rbarry82 I do not know at the moment how to check if the storage is really ready. I filed https://github.com/ubuntu/microk8s/issues/2686.

[rbarry82]

@rbarry82 I do not know at the moment how to check if the storage is really ready. I filed ubuntu/microk8s#2686.

I forgot to "finish review" with the comments, so it showed up later, but microk8s storage uses hostpath-provisioner, so we can wait for the pod. It gets a randomized name, but the k8s-app label is predictable.

[sed-i]

Seems to work well now without sleep.

[simskij]

30GB sounds excessive. Why is it needed?

[sed-i]

30GB sounds excessive. Why is it needed?

For spring music. This setting can be overridden with multipass launch --disk but we should find a good balance for the default option. How much would you suggest as the default "min"?

[simskij]

30GB sounds excessive. Why is it needed?

For spring music. This setting can be overridden with multipass launch --disk but we should find a good balance for the default option. How much would you suggest as the default "min"?

José told me why, and then it sounds fine. 👍🏽

[simskij]

Anything in the way of getting this merged?

[sed-i]

@Saviq how does this look now? Qualifies merging?

[Saviq]

Hi @sed-i, quite likely so!

Can you please split the docker one out, though? We're working on getting a good experience of Docker on Windows and macOS through Multipass, so we'd like to only have a single workflow for that. Yours would be a great base.

I'll have another look through the charm-dev one today. There's a couple outstanding comments in there, care to clear those out?

[sed-i]

@Saviq comments resolved and docker-playground split to #11

[sed-i]

please add some commentary as to "first steps" after it's launched, what's available etc.? -- @Saviq

Where do I add that? /etc/update-motd.d/10-help-text?

[Saviq]

Where do I add that? /etc/update-motd.d/10-help-text?

Hey, sorry I wasn't clear. Just a comment at the top of the YAML would be good for now so we can later move it where we need it.

[sed-i]

Just a comment at the top of the YAML -- @Saviq

Added. Was that the kind of content you were looking for?

[Saviq]

@sed-i exactly, thanks :)

Will get this in tomorrow