What's coming in 6.0 (take 2)
-
Some updates on volume management. There is now a volume view.
You add a host path as a volume and give it a name. This is most likely some EBS/external hard disk/Block Storage. There is also the file manager integration (the button next to the delete button).
You can then go to the app view and mount these volumes into the apps. There is a new Storage section.
There is a section overload in the app configure view
We are looking to reducing the list of sections in the left pane. It's making things hard to find. -
This looks wonderful!
Off the top of my head, I could see the Console + Repair sections being merged and the Resources + Access Control + Location sections being merged. But honestly I am struggling to come up with names so I suppose thats why you have them the way you have them now.
-
Some updates on volume management. There is now a volume view.
You add a host path as a volume and give it a name. This is most likely some EBS/external hard disk/Block Storage. There is also the file manager integration (the button next to the delete button).
You can then go to the app view and mount these volumes into the apps. There is a new Storage section.
There is a section overload in the app configure view
We are looking to reducing the list of sections in the left pane. It's making things hard to find.@girish Amazing!
It's almost like you develop with the power of telepathy sometimes
-
Some updates on volume management. There is now a volume view.
You add a host path as a volume and give it a name. This is most likely some EBS/external hard disk/Block Storage. There is also the file manager integration (the button next to the delete button).
You can then go to the app view and mount these volumes into the apps. There is a new Storage section.
There is a section overload in the app configure view
We are looking to reducing the list of sections in the left pane. It's making things hard to find.@girish Any chance of you adding a button in for resizing the partition after upgrading a VM?
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@girish Any chance of you adding a button in for resizing the partition after upgrading a VM?
-
@girish Any chance of you adding a button in for resizing the partition after upgrading a VM?
@marcusquinn said in What's coming in 6.0 (take 2):
@girish Any chance of you adding a button in for resizing the partition after upgrading a VM?
+1
Resizing my backup volume on Hetzner is one of the few reasons I have to occasionally ssh into my VPS.
-
@robi
s3 filesystem are not so mature, i read a lot on them because use s3 with dovecot in our mail server and the performance are terrible in u use s3 as FS, 20/40 ms depending on where you host the s3 server.The optimal solution is to use plugin or software that integrate s3 in to the App/script that you want to use.
Matteo. R.
Founder and Tech-Support Manager.
MooCloud MSP
Swiss Managed Service Provider -
@girish I could not have imagined a better system ! Looks amazing !
Three questions:
1/ How do you decide where in the app these are gonna be mounted? Is it in the same path for all apps ? Or could I create a given volume, and mount it at
/app/data/totoin app 1 and/app/data/tatain app 2 ?2/ How does it work when there already is data in the app's original
/app/databefore you mount the volume to it? Is it just hidden as long as the volume is mounted?3/ How does it work with regards to backups?
-
For 1 and 2: Those volumes will be mounted into the apps based on
/media/<volumename>and thus one volume associated with apps will always have the same mountpoint within the apps.For 3: Initially those won't be backed up at all, but we will likely add optional backup per volume as well. The user has to be aware of the fact that volumes are not part of the app backups as such!
-
For 1 and 2: Those volumes will be mounted into the apps based on
/media/<volumename>and thus one volume associated with apps will always have the same mountpoint within the apps.For 3: Initially those won't be backed up at all, but we will likely add optional backup per volume as well. The user has to be aware of the fact that volumes are not part of the app backups as such!
@nebulon said in What's coming in 6.0 (take 2):
For 1 and 2: Those volumes will be mounted into the apps based on
/media/<volumename>and thus one volume associated with apps will always have the same mountpoint within the apps.For 3: Initially those won't be backed up at all, but we will likely add optional backup per volume as well. The user has to be aware of the fact that volumes are not part of the app backups as such!
That’s the difference to storage mounted in „Resources“ - this will get backed up, correct?
-
The volumes are setup outside of the apps first and are essentially independent. Once you've created a volume you can then mount that into an app via the Storage section in the app configuration. Even if mounted though, it will not be part of the app backup, since the main reason for volumes is to be mounted into multiple apps. For that we have to first figure out how to manage those with regards to backups.
-
The volumes are setup outside of the apps first and are essentially independent. Once you've created a volume you can then mount that into an app via the Storage section in the app configuration. Even if mounted though, it will not be part of the app backup, since the main reason for volumes is to be mounted into multiple apps. For that we have to first figure out how to manage those with regards to backups.
@nebulon That makes sense. I’m of the opinion that optional block storage should effectively be backed up at the host level not the application level. In other words, taking a snapshot or something like that which many providers allow even volumes / block storage to be snapshotted. Much like how we need to snapshot our actual VPS on occasion too for a backup strategy of the entire server.
-
The volumes are setup outside of the apps first and are essentially independent. Once you've created a volume you can then mount that into an app via the Storage section in the app configuration. Even if mounted though, it will not be part of the app backup, since the main reason for volumes is to be mounted into multiple apps. For that we have to first figure out how to manage those with regards to backups.
@nebulon said in What's coming in 6.0 (take 2):
The volumes are setup outside of the apps first and are essentially independent. Once you've created a volume you can then mount that into an app via the Storage section in the app configuration. Even if mounted though, it will not be part of the app backup, since the main reason for volumes is to be mounted into multiple apps. For that we have to first figure out how to manage those with regards to backups.
No, I mean external volumes that you can currently already move the data dir to under „Resources“ in the app settings - this gets backed up, correct?
(
-
@robi
s3 filesystem are not so mature, i read a lot on them because use s3 with dovecot in our mail server and the performance are terrible in u use s3 as FS, 20/40 ms depending on where you host the s3 server.The optimal solution is to use plugin or software that integrate s3 in to the App/script that you want to use.
@MooCloud_Matt this is only true if you use dumb S3 connectors that treat it like a filesystem instead of an object store.
It's a very different experience when things are treated properly as objects.
-
Re: Volumes - I think this will create a solution for something that I have been trying to resolve - i.e. Nextcloud app backups WITHOUT the data!
I want to be able to back up the app via Cloudron natively - but backup the data via borg/restic/kopia or the like. This looks like it could resolve this issue if the data was an attached volume. Very much looking forward to this feature if it's like that.
-
Re: Volumes - I think this will create a solution for something that I have been trying to resolve - i.e. Nextcloud app backups WITHOUT the data!
I want to be able to back up the app via Cloudron natively - but backup the data via borg/restic/kopia or the like. This looks like it could resolve this issue if the data was an attached volume. Very much looking forward to this feature if it's like that.
@iqweb said in What's coming in 6.0 (take 2):
Re: Volumes - I think this will create a solution for something that I have been trying to resolve - i.e. Nextcloud app backups WITHOUT the data!
Yes, I think this will solve that use case. You mount a volume into nextcloud and configure nextcloud to use it as external storage.
