Charms should be able to specify minimum hardware constraints

[Tim McNamara]

Charms don't currently have the ability to directly influence the instance selection for their application.

Allowing charms to define their own constraints would provide resource-intensive applications the ability to run well using default settings. It could also allow charms that need very few resources, such as proxy charms, to run at low cost.

[Richard Harding (rharding)]

I think things like this are worth treating a bit like series. Charms can indicate a preference and if the operator is ok with that great, but there should be awareness to the operator to help avoid surprise bills of doom where something huge was selected and the operator wasn't expecting it. We've tended to be very very careful with behavior that touches on people's wallets.

[Tim McNamara (tim-clicks)]

> Charms can indicate a preference

Sorry, just clarifying. Is this something that's available now?

[Richard Harding (rharding)]

Sorry, should say "If charms can indicate a preference"

[Richard Harding (rharding)]

For instance, the idea is that the operator should have some basic expectations (default constraint settings?) and if a charm were to request, by the charm's metadata, something larger than the model default constraints it would fuss to the operator and make then "ok" the deploy. Think of how the juju trust idea works. The charm can request it, but the operator has to OK it before the charm gets it.

[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.