Prefered series could not selected for the applications in Kubernetes Bundles

Bug #1988595 reported by gulsum atici
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
High
Harry Pidcock

Bug Description

Hello,

We have a kubernetes bundle https://pastebin.ubuntu.com/p/DgXmN5BbWQ/ inluding several applications. Those application are released for 2 different bases: Ubuntu 20.04 and 22.04.
We would like to deploy the charm with series jammy in a bundle. However, series is not allowed for application in kubernetes bundles. Even changing model config as following does not work for us. "juju model-config default-series=jammy". Charms are deployed with focal base.

A sample charm status:
charmcraft status osm-lcm
Track Base Channel Version Revision Resources
latest ubuntu 20.04 (aarch64) stable 1 1 image (r1)
                                 candidate 1 1 image (r1)
                                 beta 2 2 image (r1)
                                 edge 1 1 image (r1)
         ubuntu 20.04 (amd64) stable 1 1 image (r1)
                                 candidate 1 1 image (r1)
                                 beta 4 4 lcm-image (r1)
                                 edge 1 1 image (r1)
         ubuntu 20.04 (arm64) stable 1 1 image (r1)
                                 candidate 1 1 image (r1)
                                 beta 2 2 image (r1)
                                 edge 1 1 image (r1)
         ubuntu 22.04 (amd64) stable - - -
                                 candidate - - -
                                 beta 5 5 lcm-image (r1)
                                 edge ↑ ↑ ↑

Steps to reproduce:
juju add model dev microk8s
juju deploy osm --channel=latest/beta --trust
juju show-application osm-lcm

Output:
lcm:
  charm: osm-lcm
  series: focal
  channel: beta
  constraints:
    arch: amd64
  principal: true
  exposed: false
  remote: false
  life: alive
  endpoint-bindings:
    "": alpha
    kafka: alpha
    mongodb: alpha
    ro: alpha
    vca: alpha

The expectation:
Application deployed with series: jammy.

Could you please help on this ?

Many thanks!

Revision history for this message
gulsum atici (gatici) wrote :

Built one of the charm by adding assumes expression in to metadata.yaml such as:

name: osm-lcm

display-name: OSM LCM

assumes:
  - any-of:
    - juju >= 2.9
    - K8s-api

It throws the error 'parsing "any-of" expression: malformed feature expression "K8s-api"'

$ juju deploy ./osm.zip --trust
Located charm "osm-lcm" in charm-hub, channel beta
Located charm "zookeeper-k8s" in charm-hub, channel stable

Executing changes:
- upload charm osm-lcm from charm-hub for series jammy from channel latest/beta with architecture=amd64
ERROR cannot deploy bundle: cannot add charm "osm-lcm": downloading charm "ch:amd64/jammy/osm-lcm-10" from origin {charm-hub charm 0xc004e1d258 beta amd64/ubuntu/jammy }: parsing expression 1 in top level "assumes" block: parsing "any-of" expression: malformed feature expression "K8s-api"

Revision history for this message
gulsum atici (gatici) wrote :

When used the any_of (with underscore) it throws another error:
assumes:
   - any_of:
     - juju >= 2.9
     - K8s-api

- upload charm osm-lcm from charm-hub for series jammy from channel latest/beta with architecture=amd64
ERROR cannot deploy bundle: cannot add charm "osm-lcm": downloading charm "ch:amd64/jammy/osm-lcm-9" from origin {charm-hub charm 0xc001999848 beta amd64/ubuntu/jammy }: parsing expression 1 in top level "assumes" block: malformed composite expression; expected an "any-of" or "all-of" block

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

The correct form is "k8s-api" with a lower case "k".
If that works, then the doc is wrong and we be fixed.

Revision history for this message
gulsum atici (gatici) wrote :

Here, tried again with the following contents:

charm metadata.yaml

assumes:
   - any_of:
     - juju >= 2.9
     - k8s-api

In bundle.yaml:

name: osm
applications:
  zookeeper:
    charm: zookeeper-k8s
    channel: latest/stable
    scale: 1
    storage:
      data: 100M
  lcm:
    charm: osm-lcm
    channel: latest/beta
    series: jammy
    scale: 1
    options:
      database-commonkey: osm
      log-level: DEBUG
    resources:
      lcm-image: opensourcemano/lcm:testing-daily

Output:

juju deploy ./osm.zip --trust
Located charm "osm-lcm" in charm-hub, channel beta
Located charm "zookeeper-k8s" in charm-hub, channel stable
Executing changes:
- upload charm osm-lcm from charm-hub for series jammy from channel latest/beta with architecture=amd64
- deploy application lcm from charm-hub on jammy with latest/beta using osm-lcm
  added resource lcm-image
- upload charm zookeeper-k8s from charm-hub from channel latest/stable with architecture=amd64
- deploy application zookeeper from charm-hub with latest/stable using zookeeper-k8s
  added resource zookeeper-image
- add unit lcm/0 to new machine 0
ERROR cannot deploy bundle: cannot add unit for application "lcm": adding units to a container-based model not supported (not supported)

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

That looks like you still need "bundle: kubernetes" because otherwise juju will try and use "AddUnit" instead of "ScaleApplication" api call when it deploys.
ie it treats the whole bundle as k8s or machine

Sorry, I should not have suggested to remove bundle:kubenetes at this stage, although we would like to get rid of that, but we can't yet.

It seems we need to do some work on the juju side to allow you to select the proper base ubuntu image for each charm container.

Changed in juju:
milestone: none → 2.9.35
status: New → Triaged
importance: Undecided → High
Harry Pidcock (hpidcock)
Changed in juju:
assignee: nobody → Harry Pidcock (hpidcock)
status: Triaged → In Progress
Changed in juju:
milestone: 2.9.35 → 2.9.36
Changed in juju:
milestone: 2.9.36 → 2.9.37
Changed in juju:
milestone: 2.9.37 → 2.9.38
Ian Booth (wallyworld)
Changed in juju:
status: In Progress → Fix Committed
Revision history for this message
Guillermo (gcalvino) wrote :

We did a test with Juju 2.9.37, and looks this is already fixed.

Changed in juju:
status: Fix Committed → Fix Released
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.