Open bwalsh opened 10 months ago
[ ]
g3t status
- when performed after push, each time user executesg3t status
the status command will check k8s job command if job status in [Unknown, Running]. Once the job status changes, the response is cached and not checked again. However, if the user never executesg3t statu
for more than N minutes and then executes it. The job logs expires, we have no way of knowing status plus the gen3 client library logs a bunch of errata to the screen.@lbeckman314 : is there a workaround for this at the k8s level. i.e. long lived logs see here and k8s doc
Just updated Sower so that jobs are kept for 24 hours after completing. This can be changed by updating sower.sowerConfig.TTLSecondsAfterFinished
:
sower:
sowerConfig:
- name: fhir-import-export
action: fhir_import_export
TTLSecondsAfterFinished: 86400 <--- Job TTL (24 hours here, 1 hour if not specified)
Open Sower PR:
@lbeckman314 As I recall the TTLSecondsAfterFinished didn't work?
orphaned metadata:
Epic
As a release manager, I need a feature tracking system to identify and prioritize missing features with real value for the users.
Missing / incomplete features
easy:
rm
remove a file - we can do it viautilities file rm
However, this is not really "git like" LOE: easyinit
,utilities access sign
status
] we should immediately log "working" to console (in case server is slow) LOE: easylog
show commit log - we can do it viautilities file ls --is_metadata
However, this is not really "git like" LOE:easydiff
- no equivalent LOE:moderate ✅moderate:
[x]
pull "some"
- currently pull retrieves all the files, need to add some ability to pull only some files based on some parameters ✅ TBD: e.g.[x]
reset commit
- no equivalent LOE:moderatehard:
orphaned metadata
analyse server database(s), flag orphaned records, allow user to remove them, or automatically purge them. LOE: hardunknown:
g3t status
- when performed after push, each time user executesg3t status
the status command will check k8s job command if job status in [Unknown, Running]. Once the job status changes, the response is cached and not checked again.However
, if the user never executesg3t status
for more than N minutes and then executes it. The job logs expires, we have no way of knowing status plus the gen3 client library logs a bunch of errata to the screen. @lbeckman314 : is there a workaround for this at the k8s level. i.e. long lived logs see here and k8s doc