New Multipass blueprint

[Abuelodelanada]

This PR add a new blue print for charm development.

The new blueprint charm-dev-batteries is based on charm-dev but with "batteries included". The main idea behind this blueprint is to make charm authors daily work easier.

After launching the blueprint, you will have a VM with 3 CPUs, 4GB RAM with:

• juju stable 3.0
• microk8s 1.25-strict
• ZSH as a default SHELL with oh-my-zsh and bira theme with plugins:
  • autosuggestions
  • syntax highlighting
  • juju
• jhack

[Abuelodelanada]

Hi @Abuelodelanada, thanks for this!

If merging this PR, there will be two charm dev environments. I agree this Blueprint improves the developer experience, but I'd like to discuss:

1. is it foreseeable to merge both charm dev environments toghether?

2. can this Blueprint replace `charm-dev`?

We have to consider the fact that all Multipass users will see this Blueprint when issuing multipass find, so I'd like to polish this to obtain the best user experience, both for charm developers and the rest of the users.

Maybe if you can give us more context on this we can converge into merging a good Blueprint.

Thanks!

Hi @luis4a0 !

The answer to both questions is: Yes.

I was thinking that sometimes as a charm author you need to test your work in different juju versions... Maybe we can merge both blueprints into more than one, for instance:

• charm-dev-juju-2.9
• charm-dev-juju-3

[luis4a0]

I was thinking that sometimes as a charm author you need to test your work in different juju versions... Maybe we can merge both blueprints into more than one, for instance:

• charm-dev-juju-2.9
• charm-dev-juju-3

This makes sense to me. We'd need then to rename the charm-dev Blueprint to charm-dev-juju-2.9 and this one to charm-dev-juju-3. Is that what you are proposing? What about juju-2.9-dev and juju-3-dev, is shortening the names too confusing?

[Abuelodelanada]

I was thinking that sometimes as a charm author you need to test your work in different juju versions... Maybe we can merge both blueprints into more than one, for instance:

• charm-dev-juju-2.9
• charm-dev-juju-3

This makes sense to me. We'd need then to rename the charm-dev Blueprint to charm-dev-juju-2.9 and this one to charm-dev-juju-3. Is that what you are proposing? What about juju-2.9-dev and juju-3-dev, is shortening the names too confusing?

Truth be told: I would prefer charm-dev-* so it is clear the purpose of the blueprint. Anyway it's up to you.

[sed-i]

I think we can keep having just one charm-dev. Switching to 2.9, depending on use case, is either

• snap refresh; or
• juju deploy --agent-version

Seems unnecessary to have two blueprints for just for that. WDYT?

[Abuelodelanada]

I think we can keep having just one charm-dev. Switching to 2.9, depending on use case, is either

* snap refresh; or

* juju deploy --agent-version

Seems unnecessary to have two blueprints for just for that. WDYT?

As far as I understand there is no way to send arbitrary configs to multipass launch command like:

$ multipass launch charm-dev --config juju=2.9

If so, would be nice to have only one blueprint.

From my point of view it would be worthwhile to avoid charm-authors having to run commands inside the VM after launching it to get the desired environment. That's why I would prefer to have 2 blueprints.

[Abuelodelanada]

Hi @luis4a0

If you agree we can close this PR since I have created a new repo with some cloud-init files.

[luis4a0]

Hi @luis4a0

If you agree we can close this PR since I have created a new repo with some cloud-init files.

Hey @Abuelodelanada, I agree. Thanks for the effort of driving this!