Convert form to use DDF/React and API - parent issue https://github.com/ManageIQ/manageiq-ui-classic/issues/6825
Location: Configuration
Form: Diagnostics/Region/Database/Backup settings
current type: Angular
API state: https://github.com/ManageIQ/manageiq-api/issues/893
PM Input: 1 - Low
imported status: NOT ASSIGNED
There are two features here:
Do we really need these features? Isn't this something that should be only available through the appliance_console? @Fryguy @agrare
agree with @skateman - less is more!
The backup settings can be imported from a scheduled backup created under Settings -> Schedules. If I select a schedule from the list of available DB backup schedules, it prefills me the form below. So the two features are tied together, can the feature still be deleted?

@Fryguy does this even work in podified? should we remove these non-core features?
No idea... perhaps @jrafanie or @NickLaMuro might have more insight?
I think I'd be +1 for dropping backup support and having users go through either appliance console or some other prescribed method for pods, however one of the features is _scheduled_ backup, which isn't available via appliance console. I'm not even sure it is possible there alone since schedules are part of the schedule worker which is application oriented.
I'm also :+1: for dropping the database garbage collection...it should not be needed at all IMO, but want @jrafanie to weigh in.
NOTE: API issue which is in description is not relevant.
@lpichler are you sure? IMO we need the (missing) API endpoint to feed the dropdown with values
oh yes you are right, thanks (and it is good to know)
No idea... perhaps @jrafanie or @NickLaMuro might have more insight?
I think I'd be +1 for dropping backup support and having users go through either appliance console or some other prescribed method for pods, however one of the features is _scheduled_ backup, which isn't available via appliance console. I'm not even sure it is possible there alone since schedules are part of the schedule worker which is application oriented.
I'm also for dropping the database garbage collection...it should not be needed at all IMO, but want @jrafanie to weigh in.
any update?
Sorry, Im missed the ping many weeks ago.
I think I'd be +1 for dropping backup support and having users go through either appliance console or some other prescribed method for pods, however one of the features is _scheduled_ backup, which isn't available via appliance console. I'm not even sure it is possible there alone since schedules are part of the schedule worker which is application oriented.
I'm also for dropping the database garbage collection...it should not be needed at all IMO, but want @jrafanie to weigh in.
Vacuuming via db GC is definitely something we can delete. 馃敶
I haven't worked on scheduled backup in a few years but when I did, I think it did a straight db_dump and not a cluster backup so if that's the case, does it even work with embedded ansible since I think that still uses a separate awx db?
Since pods/appliances will have different workflows for doing backups, maybe it's time to just cut the stuff and have dev/field people document how to do it since it's now different? In other words, I doubt this backup ui will work in pods since it needs to be run on the pg pod since that's the only one with the pg binaries.
With that said, I don't even know if scheduled or adhoc backups initiated by UI is something people use.
So the garbage collection has been dropped, what's the final decision about the (scheduled) backups?
@skateman can you bring this up at the next meeting? If we don't need to do scheduled backups anymore because we can't easily do them in the same way in podified, it would be good to deprecate and remove it.
I'd be :+1: for removing scheduled database backup and perhaps moving to appliance console as a cron job. @chessbyte @bdunne Thoughts? We _might_ need some sort of migration for any users that have it already. Should we just kill it from the UI anyway and do the appliance console change separately? My only concern is that we won't move it fast enough and then leave users in a weird position.
Before removing DBA activities from UI, let's make sure that it is merged and working via appliance console. Also, what would our strategy be in podified?
This already doesn't work in podified, the solution there is to use Velero and Restic.
I'm 馃憤馃徎 for moving to the appliance console then removing from the UI.
Most helpful comment
This already doesn't work in podified, the solution there is to use Velero and Restic.
I'm 馃憤馃徎 for moving to the appliance console then removing from the UI.