The gap make-k8s-charm aimed to fill was to avoid having to duplicate ~100 lines for each charm creation (which charm now mainly avoids).
All the examples I’d found previously were more advanced than what you need to just get started.
Also, when you have to manually import too much code, you end up forgetting to remove things like “YourClassNameGoesHere”.
I have a pretty simple charm to create in mind, will have a go at creating it starting with charm create, will file bug if I have suggestions !
Thanks @timClicks for the operator framework getting started…
one thing as I get started with charming via this list of instructions … is it expected that the .git/ folder is brought in with this command
charm create -t operator-python <charm>
I did this command inside an empty .git folder and then realized this was nesting a .git project within my own… my guess here is to perform the command outside of my empty project, then move the contents sans .git/ yes?
EDIT: Is there other material with this that talks about how to add say some bash related commands I want to run… do I just run them via python in the appropriate method name (ie on_install)
I first mistakenly tried adding commands to the install directly… until I noticed it seemed to not work…
The template script is rather naive and doesn’t expect that you’re already within a git repository. One option is available is to delete the inner .git directory.
it is a little bit tricky, because ‘hooks/install’ might be a symlink to ‘src/charm.py’ or it might be a shim python script that invokes ‘src/charm.py’, etc. We believe we’ve caught all the edge cases.
With the current operator framework you need to trigger main.main() on all the hooks. You can do this with a symlink from ‘hooks/install’ (which is what I think the template does, and works with Juju 2.7 and 2.8). Or you can create a ‘dispatch’ file in your charm’s root directory and point it at src/charm.py. (Which will work with 2.8 and means we don’t need a big symlink farm.) The operator framework can handle you doing both, so if you want to get the new stuff in 2.8+ you can have both.
However, if you want to have some of your charm in python, but test something in bash, you can very much create ‘dispatch’ and point it at src/charm.py, and then drop in a shell script as ‘hooks/install’. And the operator framework will exec ‘hooks/install’ and then trigger ‘on_install’ events.
I would have expected this to work, even before we landed support for it. Are you sure that ‘src/charm.py’ was marked executable?
It might be that the code that says “if invoked via ‘install’, create all the symlinks for all the other hooks” doesn’t work if you wrap it in a bash script. (it used the target of the install hook to determine what target to create for the other hooks.)
You could create them yourself, or use ‘dispatch’ instead for Juju 2.8.
Is there any reason why charm config is accessed as model.config ?
juju has model and mode-config, which are totally different from charm config.
IIRC, the thinking around that is that the model object represents everything in the Juju model from the charm’s current perspective. Charms can’t directly see model-level config, only their own charm-level config, and the hook tool used to get the charm’s config is config-get, hence model.config was chosen to reflect “the config that the charm can see in the model”.
That said, I totally agree that it’s confusing. Even though a charm author might know that they can’t directly access the model-level config, they will surely be aware that it exists. And there has also been some discussion about potentially allowing the charm access to at least some subset of the model-level config. Additionally, we also have shortcuts on the CharmBase class for the charm’s app, unit, meta, and charm dir, so it seems like it would be much more natural to include a config shortcut there so that it is accessed with self.config. That would then allow for deprecating the model.config name and moving / renaming it to make it less ambiguous (model.charm_config or maybe model.app.config come to mind).
$ sudo snap install charm
error: Esta revisión del snap "charm" se publicó usando el confinamiento clásico por lo cual podría
realizar cambios arbitrarios del sistema fuera de la caja de seguridad en el que los snaps
suelen estar confinados, lo cual podría suponer un riesgo para su sistema.
Si lo entiende y desea continuar repita la orden incluyendo --classic.
If I use the --classic option everything seems to be fine:
$ sudo snap install charm --classic
Se ha instalado charm 2.7.8 por Canonical✓
The charm snap is no longer the recommended way to get started with operator framework charms. I updated the post to describe using charmcraft instead, and worked through updating a few of the examples to be in line with the latest version of the framework, though I’ve run out of time for today to updating all of them. I hope the getting started and first few examples are enough to get you going for now, though!
(I should note that the self.config alias is available in the master branch of the framework but hasn’t been released as of 0.10.0, so you may have to change that to self.model.config for now.)
@chipaca or @jldev are also good people to ask, since they are driving the Operator framework.
My understanding is that they have been working on more official docs for the framework over the last month or so, but I don’t think those have been published yet.
@jameinel I’m about to start learning operator now, so I’m kind of curious if I should wait before there is more polished docs?
I like very much the format that timClicks started here with very clear and hands on examples for the tasks that normally are part of the development process for a charm.
There should be some clearer documentation being published later this week. Getting your eyes on it and helping with some feedback will certainly be appreciated.
