-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to filter instances by price range, and expose the prices/spot prices in output #71
Comments
I think price column in output could be very handy. We can get this info from pricing api from aws |
This has been merged and can be built from source for testing. I'm going to hold off on doing an official release because we'll have to increment the major version to v3 because of some lib changes that were required to support the pricing retrieval changes. |
Thanks a lot! @bwagner5 |
Would love to hear feedback here! |
A few things. First the nit picks:1. In
|
Thanks so much for taking the time to try it out and write this feedback! I'll investigate the regions not working, thanks for bringing that up. I'm fine with doing price retrieval when --usage-class is specified too. Just to clarify, you mean retrieve pricing on usage-class and price-per-hour filter right (not just on usage-class) ? Feel free to raise a PR for that! |
I am suggesting to retrieve price in all cases of table wide output. (On-demand price for Current code (only hydrate if price per hour is given): if pricePerHour != nil {
if usageClass == nil || usageClass == on-demand {
// Hydrate on demand cache
} else {
// Hydrate spot cache
}
} My suggestion (always hydrate): if usageClass == nil || usageClass == on-demand {
// Hydrate on demand cache
} else {
// Hydrate spot cache
} |
Just like we list hypervisor, current gen, gpu, ENI, etc. we should always list price. Is that okay? |
I see, I'm not opposed to figuring out a way that we could enable it all the time for table-wide output, but as it stands right now, hydrating the cache will still not expose it on the table. Currently the outputs know nothing about how the filtering works. Hydrating the cache will speed up price retrieval when calling the selector, but the selector will only retrieve pricing data if a pricing filter is present. So basically the change you're suggesting would not be sufficient to show the price on the table-wide view and if we make a further change in selector to fetch pricing data on every filter call, then it would slow down for all filters not just ones that are displayed w/ table-wide. We may be able to refactor a bit to check if the cache is already hydrated and if it is, then go ahead and add pricing data... It feels little dirty to do that since we're inferring information about which output we're using to do further filter work (even if it's just attaching the data to the instanceType struct). |
Yes, ofc I meant not just this if condition but other relevant changes overall to make it possible. If you are okay with the startup time of hydration, I can add that in table-wide, make whatever change is needed. Should I start development then? |
I am sure we can prevent this, so that if a user does not want table wide output, we do not hydrate. I can try. |
Sure! Would love for you to help on this! I agree, I think it's solvable. Looking forward to seeing what you come up with :) |
I haven't had time to investigate the other regions not pulling pricing data but I will check on that probably tomorrow. |
@bwagner5 I figured out why other regions are not working. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html#pe-endpoint Except this region issue, I have given a PR [WIP] for the other things we discussed. I am still sorting a few things out. |
This has been released for a while just forgot to close :D |
It would be great if the support is added to filter out instances based on live price range. Also, to show the price of the instances (both spot and on-demand) in the output.
The text was updated successfully, but these errors were encountered: