list resources owned by "expired" projects

[msherman64]

this lists resources owned by projects with no active allocation

TODO:

• configure resource types to search, also for compatibility between kvm and baremetal
  • (and uncomment types for KVM)
• configure grace period for allocation expiry

[pdmars]

Just some high-level questions for this repo to get my bearings as I start to use it / learn it:

1. Do we doc the different tools in here? E.g. what they are, how to run them, what to expect to get from them (and then what to do with that output)
2. Also, I notice things like typing, and a variety of dependencies included for this tool. Are these pretty standard across all the tools? Do we doc expectations here of how to install the deps and run any type checking (or tests - ok if not)?

[msherman64]

Just some high-level questions for this repo to get my bearings as I start to use it / learn it:

1. Do we doc the different tools in here? E.g. what they are, how to run them, what to expect to get from them (and then what to do with that output)
2. Also, I notice things like typing, and a variety of dependencies included for this tool. Are these pretty standard across all the tools? Do we doc expectations here of how to install the deps and run any type checking (or tests - ok if not)?

those are good questions.
for (1), I've been attempting to document tools in the readme here, but a lot of these are more "beta" than might be desirable. There's a tension between "here's a quick tool that solves problems, and here's a tool without sharp edges".

My "goal" for when we distributed it in chi-in-a-box is that we at least have a clearly defined set of well-documented, tested tools with the sharp edges addressed, even if we still have a second area of "these are useful but brittle things, don't count on them".

For the same reason, the dependencies, typing, and tests have been a bit inconsistent, and it would be nice to arrive at a common subset.
For now, the commonality has been:

• argparse for argument parsing
• openstacksdk for auth, connection, hitting openstack apis
• iso8601 for timestamps, as it's the format openstack standardized on

There are clearly places I haven't matched the "common base" though, such as logging vs oslo.log, requests vs other tools, and what forms of parallelism are in use, whether subprocess, asyncio, etc, etc....

asyncio + aiohttp was specifically to parallelize the "cheap requests" to portal, but it does add complexity.

I'd welcome suggestions on firming it up, review guidelines, linters / pre-commit checks, and so on.

At a very high level, this is part of why openstack pins "upper-constraints", so that any addition to, or change of, python dependencies requires a review.