feat(charm): add vm charm #7
Conversation
matthew-hagemann
force-pushed
the
vm-charm
branch
from
0fffd73
to
0b78044
Compare
matthew-hagemann
force-pushed
the
vm-charm
branch
from
b5167a1
to
5d9d9b9
Compare
|
@tim-hm I believe the integration test is failing because I haven't updated the k8s charm with all the changes that have happened to the services |
matthew-hagemann
force-pushed
the
vm-charm
branch
from
b3ee286
to
1184b31
Compare
Absolutely, especially as it falls behind what the service does. I'll make that change next 👍 |
|
What about the k8s charm test and the ROCKS CI action? |
I found a good resource on how to do the tests, and they do seem fairly standard to include, so I'll:
|
matthew-hagemann
force-pushed
the
vm-charm
branch
from
bcf85e3
to
deb1fe6
Compare
matthew-hagemann
force-pushed
the
vm-charm
branch
from
deb1fe6
to
16e34fc
Compare
| @@ -0,0 +1,32 @@ | |||
| options: | |||
There was a problem hiding this comment.
I wouldn't include this much config - it might sound odd but you want to be exposing as little config as possible to keep the operator code simple.
I'd consider dropping:
app-hostapp-jwt-secret- this is probably better autogenerated?app-nameapp-port- unless you're thinking of co-locating this unit on machines with other services on 443?
Both the postgres options need to be removed - this should be handled by relations to postgres.
With squid, it's worth asking IS, as I believe you should also be able to get this from a relation, though I could be wrong here.
There was a problem hiding this comment.
Following up - some of these don't actually seem to be used at all in the code.
I'd recommend the following:
env- keep this, with some code to validate the entry as eitherprodordevlog_level- again with some validation of the valid options
vm_operator/src/charm.py
Outdated
| self.unit.status = MaintenanceStatus("Installing rustc, cargo and other dependencies") | ||
|
|
||
| # Install via apt | ||
| self._install_apt_packages(["curl", "git", "gcc", "libssl-dev", "pkg-config","protobuf-compiler"]) | ||
|
|
||
| # Ensure squid proxy, done after apt to not interfere | ||
| self._set_squid_proxy() | ||
|
|
||
| # Curl minial rust toolchain | ||
| try: | ||
| check_output("curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --profile minimal", shell=True) | ||
| self._stored.install_completed = True | ||
| self.unit.status = MaintenanceStatus("Installation complete, waiting for database.") | ||
|
|
||
| except CalledProcessError as e: | ||
| logger.error(f"Curl command failed with error code {e.returncode}") | ||
| self.unit.status = BlockedStatus("Curl command failed") | ||
| return |
There was a problem hiding this comment.
This is pretty heavy, and you'll end up with the whole toolchain installed on the machines running in production.
If you're planning on running on VMs in the long term, I'd recommend building this as a snap, then installing the snap package (pinned to a specific revision) in your charm. FWIW you can use the same parts definition from the removed rockcraft.yaml to build the snap :)
| self.unit.status = BlockedStatus("Curl command failed") | ||
| return | ||
|
|
||
| def _render_systemd_unit(self): |
There was a problem hiding this comment.
If you build with a snap, this can be taken care of for you automatically by snapd
|
@matthew-hagemann good effort on this! Charming can be a little dense to get started with! I've left some comments above and I'm happy to have a call or another round of review if you or @tim-hm think it'd be useful. A nice clean example of using a snap within a charm and how to model it can be seen here: https://github.com/jnsgruk/parca-operator |
matthew-hagemann
force-pushed
the
vm-charm
branch
from
9f43d27
to
9f65541
Compare
Closes #4
Due to the infrastructure provisioned for the team, we were not able to move ahead with our k8s charm, and needed a charm that was set up to run on a vm instead.