Getting cannot deploy now while doing local charm dev if charm exists in model

charmcraft
1

recently a change occurred in juju v2.9.x which finally bit me today… while doing some local charm development work… I went to deploy a bundle which has reference to a local file path… this seems to no longer work if the node is already deployed … in past it simply trusted the charmed node was alright and to me moved on…

https://github.com/juju/juju/pull/12846

I am trying to figure out what is the expectation now, seems I need the yaml file to be in a certain path … and then any “downstream” charms to be in folders named after the yaml key entry… instead of the charm path?

series: focal 
applications:
  postgresql:
    charm: cs:postgresql
    num_units: 1
    to:
    - "1"
  ibgateway:
    charm: /home/myuser/Dev/git/someproject/charms/inprogress-charm
    num_units: 1
    to:
    - "2"

$  juju deploy ./config.yaml
Located charm "postgresql" in charm-store, channel stable
Executing changes:
- upload charm inprogress-charm from local for series focal with architecture=amd64
ERROR cannot deploy bundle: cannot deploy local charm at "/home/myuser/Dev/git/someproject/charms/bundled-charm/inprogress-charm": file does not exist

I version control my bundles in seperate repos… so putting the charms directly in the path would require me to likely move the yaml file and possibly lose track of the version control without some … I guess symbolic links? not worried as I can just wipe that node and deploy without issue thereafter but… this will bite me during development later and I cannot understand the way forward

EDIT:

I see this language in the docs but… I think this needs to be clarified… I cannot really understand on it’s face what to do… so instead will need to just try some things out?

Using local charms

To integrate a local charm into a bundle a local bundle file, say bundle.yaml, will be needed and where the charm field points to the directory of the charm in question. Here is an example:

Relative paths

Relative paths are resolved relative to the path of the entity that describes them. That is, relative to the overlay bundle file itself.

Change in behaviour: Before Juju 2.7, relative paths within overlay bundles were resolved relative to the base bundle.

Source: Juju | Charm bundles

1 Like
2

okay here’s my workaround - problems left so far

  1. move the config.yaml file up one directory

problem , it’s now not in git repo but… okay

  1. due to a naming conflict … one of my charms when I published it to the store… was named apache-superset instead of superset … but in my local I was still “getting away” with this… To get this relative path thing to work I’ve had to take all the charm repos… whatever they’re called… and name them what the charm published name is…

so in a simple case superset-charm , the name of my git repo… has to be moved

mv superset-charm/ apache-superset/

the con here is… the name of the folder in my dev environment does not match git repo actual name… (I like to put -charm on all charm repos as a signal that… this is the repo for just charm code)

now I can rock and roll now… with some caveats… in the end I guess the biggest downsides are highlighted but, I am sure this was done for some good reason like avoiding that weird naming business (apache-superset vs having superset locally)

1 Like