I didn’t see anything in the documentation that specifically answered my confusion so I’m looking for help here.
I plan to use Juju with a manual cloud of machines. I want to have a database server running on those machines. How would the storage pools work if there is no cloud backing to create something like EBS? I understand there is rootfs that I could use, however how does that work? Are you only able to attach rootfs storage to the same server that is running the unit? If I wanted to move the database unit to another server, would the rootfs be migrated? What’s the best practice to do what I want to accomplish given that I’m running on a manual cloud?
Thank you so much.
PS: Is there anyway to tag machines with a friendly name so I can recognize which machine I’m deploying something to?
If you are using manual machines, then Juju doesn’t do any form of special storage mounting. What the machine has is what you can use. There is no storage pool usable with manual machines.
Charms are deployed into /var/lib/juju under the unit agent’s directory. Other than that, it is up to the charm where it deploys the workload.
Currently there is no way in Juju to tag machines with other names. However Juju does allow you to use the unit name for many uses where you might care about the machine once things are deployed. Like juju ssh postgresql/2 will ssh to the machine that hosts the unit postgresql/2.
Is it possible to configure the data directory? Then I could at least move them onto an NFS share. Or perhaps it’s preferable to run a Ceph cluster if you’re running manual machines? Then perhaps you could make use of the storage provided across multiple machines into your k8s cluster also running on juju?
It would be nice if the documentation would be updated for such an instance. Anyone using manual clouds would likely run into the same question/problems.
I think you might be a little confused between the data directory that juju uses for itself, which is /var/lib/juju, and where any particular charm may install software or store data.
For example, I’m sure the postgresql charm has a configurable location for the database. And it is likely that most charms that store presistent data will have some config value, with a meaningful default, that they use to identify the workload data location.
I think the issue is that the postgres charm does have a storage point that people can use to set an ebs volume or use local disk, etc. Though I don’t think our storage pool semantic allows you to specify paths on disk. (The intent was more that Juju would be able to tell Postgres where the volume was attached, but not that the system admin would need to care.)
With manually provisioned machines, we don’t have storage sources that the manual provisioner understands. We could implement something like “path on host”, but the concern is that feel very local to a machine and not inherently applicable across machines. (is the path on disk for machine 1 the same as the path on machine 2?)
Given it is already “manual” having to trust that you’ve set things up appropriately is probably reasonable.
Perhaps I’m confused but the Postgres charm does not have any configuration options to specify the path of it’s data directory. This makes it pretty hard or impossible to have some NFS share you mount to store postgres data. You’d have to manually explore the /var/lib/juju directory and find where it’s installed. This could also break between versions or operating systems which I thought would be against Juju’s principals.
I understand manual clouds are expected to be “configured right” but from what I can tell it’s not even possible or viable to configure Juju properly when running stateful applications.
If I’m wrong it would be super appreciated if there was some additional documentation added to the Manual Cloud page about how volumes or stateful applications /should/ be done with Juju.
