Default bundle scale is "0"

Bug #1891344 reported by Benjamin Allot
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Expired
High
Unassigned

Bug Description

Hello,

Trying a new k8s charm with juju 2.8.1 and a bundle looking like this

bundle: kubernetes
applications:
  mm-pd-bot:
    charm: {{ charm_dir }}/mm-pd-bot
    options:
      image_path: stg-is.docker-registry.canonical.com/mm-pd-bot:latest
      mm_pd_bot_cfg: include-file://{{ local_dir }}/bot.cfg
      tls_secret_name: mm-pd-bot-staging-canonical-com-tls
      # Those parameters are k8s specific
      juju-external-hostname: mm-pd-bot.staging.canonical.com

The result was a deployed application but no pod.
It took me some time to understand that I needed "scale: 1".
The only reference I could find was https://juju.is/docs/charm-bundles about the Kubernetes bundle and it's mentioned nowhere that "scale: 1" MUST be used.

That's pretty confusing because usually, you want at least one pod for your application.
I would rather have a default to "scale: 1" and the possibility to set "scale: 0" if really needed.

What do you think ?

Revision history for this message
Paul Collins (pjdc) wrote :

This sounds similar to the existing bug for max_units defaulting to 0, LP:1595330.

Revision history for this message
Ian Booth (wallyworld) wrote :

Yes, it is the same issue as that older linked bug 1595330.

"scale" was implemented to have the same behaviour as "num_units", and "num_units" is treated as an alias for "scale". The issue with changing the default is as highlighted in the linked bug, so there's not necessarily a quick fix.

Changed in juju:
milestone: none → 2.9-beta1
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Tytus Kurek (tkurek) wrote :

I don't think the importance "Medium" is relevant here. The default scale of 0 is not intuitive, confusing and forces people to use bundles which are more complex than artifacts used by other open source projects.

Revision history for this message
Pen Gale (pengale) wrote :

@tkurek do you have the bits to change the importance of this one? Changing the importance isn't necessarily going to change that the fix is an involved one, and we have only so much time available. But you're the Product Manager, and I think that it's reasonable to expect you to be able to change the priority for a bug when you believe that we've got it wrong.

Changed in juju:
milestone: 2.9-beta1 → 2.9-rc1
Revision history for this message
Pen Gale (pengale) wrote :

This is planned roadmap work for the 3.0.0 release. Changed tagging and milestone to reflect that.

Changed in juju:
milestone: 2.9-rc1 → 3.0.0
importance: Medium → High
Changed in juju:
milestone: 3.0.0 → 3.0.1
Changed in juju:
milestone: 3.0.1 → 3.0.2
Changed in juju:
milestone: 3.0.2 → 3.0.3
Revision history for this message
Juan M. Tirado (tiradojm) wrote :

This looks already fixed. Please reopen it if needed.

Changed in juju:
milestone: 3.0.3 → none
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Canonical Juju because there has been no activity for 60 days.]

Changed in juju:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.