juju will attempt to deploy a lxd profile on a non-lxd cloud

[Peter Jose De Sousa]

Hello,

When embedding a profile with unsupported keys Juju will attempt to deploy this profile even if the cloud is not a lxd cloud.

Steps to reproduce:

1. Create a non-lxd cloud
2. use a charm with a unsupported lxd profile like this one: https://pastebin.canonical.com/p/Bh5KGRrQtK/
3. Attempt to deploy the charm either in a bundle or on it's own without --force
4. Observe that juju will fail with 'ERROR invalid lxd-profile.yaml: contains device type "disk"' or other unsupported key value.

Expected Behaviour:

Juju ignores profile and deploys

Actual:

Deployment fails with error in step 4.

Cheers,
Peter

[John A Meinel (jameinel)]

I don't see why an invalidity crafted charm should be ignored. It is always
possible on any cloud that you would "add-unit --to lxd:3" which would put
the unit into a container where the profile would be in play. While we
could wait until you try to create a container, it does feel like a case
where we shouldn't be accepting bad data in the first place.

John
=:->

On Thu, Jul 11, 2019, 20:40 Peter De Sousa <email address hidden>
wrote:

> Public bug reported:
>
> Hello,
>
>
> When embedding a profile with unsupported keys Juju will attempt to deploy
> this profile even if the cloud is not a lxd cloud.
>
> Steps to reproduce:
>
> 1. Create a non-lxd cloud
> 2. use a charm with a unsupported lxd profile like this one:
> https://pastebin.canonical.com/p/Bh5KGRrQtK/
> 3. Attempt to deploy the charm either in a bundle or on it's own without
> --force
> 4. Observe that juju will fail with 'ERROR invalid lxd-profile.yaml:
> contains device type "disk"' or other unsupported key value.
>
> Expected Behaviour:
>
> Juju ignores profile and deploys
>
> Actual:
>
> Deployment fails with error in step 4.
>
> Cheers,
> Peter
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1836226
>
> Title:
> juju will attempt to deploy a lxd profile on a non-lxd cloud
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1836226/+subscriptions
>

[Tim Van Steenburgh (tvansteenburgh)]

Well, it's not really an invalid charm, it's a charm with a lxd profile that requires --force. But I can see your point - you don't know at deployment time if the charm will be installed on lxd later. So you'd have to add --force to add-unit as well.

Anyway, I can see the reasoning behind the current behavior. It's just unfortunate that a "special" profile has repercussions for *every* deployment, not just deployments to lxd. Logically it seems reasonable to assume that a lxd profile would only impact lxd deployments.

In the case of Charmed Kubernetes, it may never be possible to pare the profile down to something that doesn't require --force, due to assumptions made by the upstream k8s binaries. Which means that we'd need to either 1) require --force for every deployment of the charms, regardless of substrate, or 2) not use the embedded lxd profile feature of juju. The former is gross, and the latter makes life difficult for anyone deploying on lxd.

Really not sure what the "correct" solution is, just wanted to open this bug for awareness and discussion. If no changes are planned, it's okay to close as Won't Fix.

[Richard Harding (rharding)]

I think it's reasonable that the --force turns into an argument on the add-unit due to the violation at that time. It's not setup that way at this time so worth leaving the bug open towards that end.

[Richard Harding (rharding)]

Though I do think that the best thing is to try to avoid things in the profile that need --force if at all possible. It was setup in this way with collaboration with the lxd team and it's a generally not great to have things in there that require it if it can be helped.

[John A Meinel (jameinel)]

The fact that one of our flagship bundles needs --force to operate means we
need to rethink *something* in the mix. (Either we need to back off from
refusing disk because it really is needed, or we should try to rework how
enable that support.)

That said, I agree with Rick that we could defer the --force out of
'deploy' and into 'add-unit'.

On Mon, Jul 22, 2019 at 4:50 PM Richard Harding <email address hidden>
wrote:

> Though I do think that the best thing is to try to avoid things in the
> profile that need --force if at all possible. It was setup in this way
> with collaboration with the lxd team and it's a generally not great to
> have things in there that require it if it can be helped.
>
> ** Changed in: juju
> Status: New => Triaged
>
> ** Changed in: juju
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1836226
>
> Title:
> juju will attempt to deploy a lxd profile on a non-lxd cloud
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1836226/+subscriptions
>

[Peter Jose De Sousa (pjds)]

Currently preparations are being made to ensure that `--force` is not effective default.

The way that this currently works doesn't seem to make sense, I guess moving --force into add-unit would work, also I know it adds complexity but are there not different code paths for different clouds?

The reason I filed this bug was that when I was trying out the change, I moved onto another bug, forgot I built the profile on my local, then was faced with this situation.

Why does this profile get validated even when it's not being deployed? I may be missing some design decision or something, but again can't we just not deploy when the context is non-lxd?

If there's something I'm missing please feel free to correct me. I'm new. :-)

[Kevin W Monroe (kwmonroe)]

> Why does this profile get validated even when it's not being deployed [to lxd]?

@pjds, because Juju doesn't know if the charm is going to be deployed to lxd on one of your non-lxd cloud machines in the future. To expand on @jam's comment 1, let's say you have 2 machines in AWS. If Juju allowed this deployment to machine 1 without --force:

juju deploy naughty-charm --to 1

What should it do when you add another unit of that charm to a lxd container on AWS machine 2?

juju add-unit naughty-charm --to lxd:2

Today --force is only available during deploy, so that's when Juju validates the profile; it barks at all clouds because of the '--to lxd' potential. In the future, @rick_h and @jam are proposing to move that validation closer to the lxd-specific problem areas. I think it's a terrific idea, fwiw.

[Peter Jose De Sousa (pjds)]

@kwmonroe Thank you for that, I was missing that background

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.