Open avolon42x opened 2 years ago
Hello @avolon42x . There are some other issues in here tracking dynamic lease adjustment. As far as CPU usage reporting, we don't have that on the roadmap but I think there is the possibility of getting that data from Kubernetes and displaying it.
Thx @hydrogen18 for commenting. Yes with metrics-server you can read out these stats. What was on my mind is that currently deployments are most of the time terribly inefficient since it is difficult to predict the workload requirements for tenants. Example from my small cluster:
As you can see with the exception of miners most deployments are grossly overscaled. Of course this is only a snapshot. But I expect most deployments to be like that. So in order to become truly cost-efficient we need to give tenants a feedback on how efficient their deployment really is. This could lead to a massive improvement (10x at least) on deployment efficiency and thus cost advantages for tenants as well as more capacity on provider side.
I guess implementation can reach from simple API / data exposure to complete dynamic pricing strategies. Ideas/Inputs are welcome!
@avolon42x I think a tenant can use the akash provider lease-shell
command to get some instant feedback by running htop
inside their container.
It would be better to have a standard API to snapshot the metrics and show them to the tenant, but we don't have that yet.
Is your feature request related to a problem? Please describe. As a tenant, I want to know how high the usage of my lease actually is, so that I can adjust my lease according to the needs of the deployment.
Describe the solution you'd like Expected: As a tenant, I can either by command line or ui (akashlytics) see my actual resource usage of my lease. E.g:
Lease: 1 vCPU, 128M RAM, 32GB ephemeral storage Actual (avg 15min): 0.5 vCPU, 48M RAM, 5GB ephemeral storage
non functional: I think an average of last 15min, 24h and 7 days would be sufficient. (?)
Describe alternatives you've considered An ideal solution would be a dynamic lease system with upper/lower bounds for resource. But I think this would make things overly complicated.
Additional context Benefits for tenants: can better adjust their actual usage and save potentially unnecessary costs. Benefits for providers: have a better actual utilization of their resources which contributes to efficiencies and effectiveness of akash itself.