fix: Query both ABS and vmpooler services to find all active VMs

.diataxis

@@ -1,7 +1,6 @@
 {
+  "default": "docs",
   "readme": "docs/README.md",
-  "howtos": "docs/how-to",
-  "tutorials": "docs/tutorials",
-  "adr": "docs/adr"
+  "adr": "docs/adr",
+  "projects": "docs/_gtd"
 }
-

.rubocop_todo.yml

@@ -1,6 +1,6 @@
 # This configuration was generated by
 # `rubocop --auto-gen-config`
-# on 2026-07-08 19:38:12 UTC using RuboCop version 1.76.2.
+# on 2026-07-09 11:16:03 UTC using RuboCop version 1.76.2.
 # The point is for the user to remove these configuration records
 # one by one as the offenses are removed from the code base.
 # Note that changes in the inspected code, or installation of new
@@ -14,27 +14,32 @@ Gemspec/DevelopmentDependencies:
   Exclude:
     - 'bolt_dynamic_inventory.gemspec'
 
-# Offense count: 2
+# Offense count: 4
 # Configuration parameters: AllowedMethods, AllowedPatterns, CountRepeatedAttributes.
 Metrics/AbcSize:
-  Max: 20
+  Max: 26
 
 # Offense count: 1
 # Configuration parameters: CountComments, CountAsOne.
 Metrics/ClassLength:
-  Max: 129
+  Max: 195
 
-# Offense count: 1
+# Offense count: 2
 # Configuration parameters: AllowedMethods, AllowedPatterns.
 Metrics/CyclomaticComplexity:
-  Max: 8
+  Max: 9
 
-# Offense count: 3
+# Offense count: 5
 # Configuration parameters: CountComments, CountAsOne, AllowedMethods, AllowedPatterns.
 Metrics/MethodLength:
   Max: 20
 
 # Offense count: 1
+# Configuration parameters: AllowedMethods, AllowedPatterns.
+Metrics/PerceivedComplexity:
+  Max: 9
+
+# Offense count: 3
 RSpec/AnyInstance:
   Exclude:
     - 'spec/bolt_dynamic_inventory_spec.rb'
@@ -46,15 +51,15 @@ RSpec/ContextWording:
   Exclude:
     - 'spec/bolt_dynamic_inventory_spec.rb'
 
-# Offense count: 10
+# Offense count: 13
 # Configuration parameters: CountAsOne.
 RSpec/ExampleLength:
   Max: 26
 
-# Offense count: 7
+# Offense count: 9
 # Configuration parameters: AllowSubject.
 RSpec/MultipleMemoizedHelpers:
-  Max: 8
+  Max: 11
 
 # Offense count: 3
 # Configuration parameters: AllowedGroups.

CODE_OF_CONDUCT.md

@@ -2,73 +2,45 @@
 
 ## Our Pledge
 
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment
-include:
+Examples of behavior that contributes to creating a positive environment include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
-advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at gavin.didrichsen@gmail.com. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <gavin.didrichsen@gmail.com>. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at [http://contributor-covenant.org/version/1/4][version]
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
 
 [homepage]: http://contributor-covenant.org
 [version]: http://contributor-covenant.org/version/1/4/

README.md

@@ -7,17 +7,35 @@ A Bolt inventory generator for VMs on various providers including orbstack and v
 ### System Dependencies
 
 - **Ruby** (version 2.7 or later)
-- **nmap** (required for VMPooler connectivity filtering).  For example, `brew install nmap`
-- **floaty** (required for VMPooler).  For example, `gem install floaty`.
+- **nmap** (required for VMPooler connectivity filtering). For example, `brew install nmap`
+- **floaty** (required for VMPooler). For example, `gem install floaty`.
 - **bolt**
 
 ## Usage
 
-This `bolt_dynamic_inventory` gem queries either VMPooler or Orbstack and generates a Bolt inventory.  It can be used in 2 ways:
+### Quick Start
 
-- **as a gem**.  For more information see [How to use as a gem](./docs/how_to/how_to_use_as_a_gem.md).
-- **as a bolt dynamic inventory plugin**.  For more information see [How to use as a bolt dynamic plugin](./docs/how_to/how_to_use_as_a_bolt_dynamic_plugin.md).
+This `bolt_dynamic_inventory` gem queries either VMPooler or Orbstack and generates a Bolt inventory. It can be used in 2 ways:
+
+- **as a gem**. For more information see [How to use as a gem](./docs/how_to/how_to_use_as_a_gem.md).
+- **as a bolt dynamic inventory plugin**. For more information see [How to use as a bolt dynamic plugin](./docs/how_to/how_to_use_as_a_bolt_dynamic_plugin.md).
 
 This repository also explains [How to create a basic dynamic inventory plugin](./docs/how_to/how_to_create_a_basic_bolt_inventory_plugin.md).
 
-For a listing of various how-to guides and design decisions, see the [documentation](./docs/README.md).
+## References
+
+For a complete listing of various how-to guides and design decisions, see the [documentation](./docs/README.md). The following list is a good place to start.
+
+**Getting Started**
+
+- [How to setup the environment](howto_how_to_setup_the_environment.md)
+- [How to use as a gem](howto_how_to_use_as_a_gem.md)
+- [How to use as a bolt dynamic plugin](howto_how_to_use_as_a_bolt_dynamic_plugin.md)
+- [How to use the `role` fact](howto_how_to_use_the_role_fact.md)
+- [How to create a basic dynamic inventory plugin](howto_how_to_create_a_basic_dynamic_inventory_plugin.md)
+
+**Provider Guides**
+
+- [How to create and remove orbstack VMs from the command-line](howto_how_to_create_and_remove_orbstack_vms_from_the_command_line.md)
+- [How to setup windows credentials for vmpooler](howto_how_to_setup_windows_credentials_for_vmpooler.md)
+- [How to Test VMPooler Inventory Features](howto_how_to_test_vmpooler_inventory_features.md)

docs/README.md

@@ -2,22 +2,6 @@
 
 ## Description
 
-## Usage
-
-## Appendix
-
-### HowTos
-
-<!-- howtolog -->
-
-<!-- howtologstop -->
-
-### Tutorials
-
-<!-- tutoriallog -->
-
-<!-- tutoriallogstop -->
-
 ### Design Decisions
 
 <!-- adrlog -->
@@ -28,4 +12,20 @@
 * [ADR-0005](adr/0005-add-role-fact-that-matches-the-group-name-making-puppet-switching-easier.md) - Add 'role' fact that matches the group name making puppet switching easier
 * [ADR-0006](adr/0006-extend-the-plugin-to-handle-not-only-orbstack-but-vmpooler-as-well.md) - Extend the plugin to handle not only orbstack but vmpooler as well
 * [ADR-0007](adr/0007-use-nmap-ssh-port-scan-for-vmpooler-vm-connectivity-filtering.md) - Use nmap SSH port scan for VMPooler VM connectivity filtering
+* [ADR-0008](adr/0008-query-both-abs-and-vmpooler-services-to-find-all-active-vms.md) - Query both ABS and vmpooler services to find all active VMs
+* [ADR-0009](adr/0009-cache-vm-data-with-smart-ttl-based-invalidation.md) - Cache VM data with smart TTL-based invalidation
+* [ADR-0010](adr/0010-surface-unavailable-vms-in-a-dedicated-group-instead-of-silently-dropping.md) - Surface unavailable VMs in a dedicated group instead of silently dropping
 <!-- adrlogstop -->
+
+### How-To Guides
+
+<!-- howtolog -->
+* [How to create a basic dynamic inventory plugin](howto_how_to_create_a_basic_dynamic_inventory_plugin.md)
+* [How to create and remove orbstack VMs from the command-line](howto_how_to_create_and_remove_orbstack_vms_from_the_command_line.md)
+* [How to setup the environment](howto_how_to_setup_the_environment.md)
+* [How to setup windows credentials for vmpooler](howto_how_to_setup_windows_credentials_for_vmpooler.md)
+* [How to Test VMPooler Inventory Features](howto_how_to_test_vmpooler_inventory_features.md)
+* [How to use as a bolt dynamic plugin](howto_how_to_use_as_a_bolt_dynamic_plugin.md)
+* [How to use as a gem](howto_how_to_use_as_a_gem.md)
+* [How to use the `role` fact](howto_how_to_use_the_role_fact.md)
+<!-- howtologstop -->

docs/adr/0001-extend-this-gem-to-be-a-bolt-inventory-dynamic-plugin-also.md

@@ -8,7 +8,7 @@ Accepted
 
 ## Context
 
-Bolt plugins are very useful for enhancing bolt functionality, particularly around inventory control.  For example, a number of existing plugins exist to create dynamic inventory for Azure or AWS.  These kinds of plugins are known as [reference plugins](https://www.puppet.com/docs/bolt/latest/writing_plugins#reference-plugins).  While the implementation of a dynamic reference inventory plugin could live directly in the `tasks/resolve_reference.rb`, this is not good practice as it makes it difficult to test the logic.  Also, it hides the underlying bolt `inventory.yaml` that is generated making it very difficult to troubleshoot.  Further, this code is useful not only for a bolt dynamic inventory plugin but also for command-line.  I might just want to generate a raw `inventory.yaml` for my orbstack and not use the dynamic plug in feature.
+Bolt plugins are very useful for enhancing bolt functionality, particularly around inventory control. For example, a number of existing plugins exist to create dynamic inventory for Azure or AWS. These kinds of plugins are known as [reference plugins](https://www.puppet.com/docs/bolt/latest/writing_plugins#reference-plugins). While the implementation of a dynamic reference inventory plugin could live directly in the `tasks/resolve_reference.rb`, this is not good practice as it makes it difficult to test the logic. Also, it hides the underlying bolt `inventory.yaml` that is generated making it very difficult to troubleshoot. Further, this code is useful not only for a bolt dynamic inventory plugin but also for command-line. I might just want to generate a raw `inventory.yaml` for my orbstack and not use the dynamic plug in feature.
 
 One way to make the above possible is to make this code not only a gem for use in pure ruby, but also capable of acting as a bolt reference dynamic plugin.
 

docs/adr/0002-configure-bolt-inventory-with-native-ssh-to-keep-things-simple.md

@@ -8,7 +8,7 @@ Accepted
 
 ## Context
 
-Although there may be a number of ways to configure the SSH connectivity for a bolt dynamic inventory plugin, I want to implement this plugin as simply as possible and at the same time use the same ssh approach as on my terminal.  Troubleshooting is easier: if my command-line cannot ssh to my orbstack VMs, then my plugin won't either.  Fix the command-line and the plugin should work as well.
+Although there may be a number of ways to configure the SSH connectivity for a bolt dynamic inventory plugin, I want to implement this plugin as simply as possible and at the same time use the same ssh approach as on my terminal. Troubleshooting is easier: if my command-line cannot ssh to my orbstack VMs, then my plugin won't either. Fix the command-line and the plugin should work as well.
 
 ## Decision
 

docs/adr/0003-gather-inventory-metadata-via-the-cli-to-keep-things-simple.md

@@ -8,13 +8,13 @@ Accepted
 
 ## Context
 
-When I discovered orbstack and in particular how easy and fast it was to create VMs, I immediately wanted to start using bolt to provision my orbstack VMs.  Initially, I manually created the `inventory.yaml` but soon after created a ruby script to automatically generate the same `inventory.yaml`.  Anytime I added or removed an orbstack VM I ran this script to generate an up-to-date bolt inventory.  Since bolt plugins are useful for many tasks, including dynamic inventories, I decided to refactor my ruby script into a dynamic inventory plugin.  One easy way to access the orbstack VM metadata is through the `orb` CLI.
+When I discovered orbstack and in particular how easy and fast it was to create VMs, I immediately wanted to start using bolt to provision my orbstack VMs. Initially, I manually created the `inventory.yaml` but soon after created a ruby script to automatically generate the same `inventory.yaml`. Anytime I added or removed an orbstack VM I ran this script to generate an up-to-date bolt inventory. Since bolt plugins are useful for many tasks, including dynamic inventories, I decided to refactor my ruby script into a dynamic inventory plugin. One easy way to access the orbstack VM metadata is through the `orb` CLI.
 
 Other VM providers like vmpooler also have useful CLI commands for accessing VM metadata.
 
 ## Decision
 
-Therefore, I decided to keep the implementation simple by using the CLI to access VM metadata.  For orbstack VMs I use the `orb` cli; for vmpooler, the `floaty`.
+Therefore, I decided to keep the implementation simple by using the CLI to access VM metadata. For orbstack VMs I use the `orb` cli; for vmpooler, the `floaty`.
 
 ## Consequences
 

docs/adr/0004-create-dynamic-inventory-groups-based-on-hostname-regex-patterns.md

@@ -28,7 +28,7 @@ group_patterns:
 
 ## Consequences
 
-The bolt_dynamic_inventory plugin now supports dynamic group creation based on target name patterns. This allows users to group their targets into logical groups based on their names.  **NOTE**:
+The bolt_dynamic_inventory plugin now supports dynamic group creation based on target name patterns. This allows users to group their targets into logical groups based on their names. **NOTE**:
 
-* if `group_patterns` is empty, then no groups are created.
-* if a group's regex pattern fails to match any targets, then that group is skipped.
+- if `group_patterns` is empty, then no groups are created.
+- if a group's regex pattern fails to match any targets, then that group is skipped.

docs/adr/0005-add-role-fact-that-matches-the-group-name-making-puppet-switching-easier.md

@@ -8,11 +8,11 @@ Accepted
 
 ## Context
 
-I want my bolt inventory.yaml to **not only** have 'groups' defined by regex, **but also** a 'role' fact defined for each of these groups.  The role fact will have the same name as the group name.  The reason this is useful is that bolt does not have to wait for puppet to collect facts on each target before switching on this 'role'.  If I only wait for puppet to return a target's facts, then bolt is effectively blind for the first run.  It cannot switch on particular target facts that it doesn't have.  Since we're creating the bolt inventory and know relevant information about the targets, then I want this always available.  
+I want my bolt inventory.yaml to **not only** have 'groups' defined by regex, **but also** a 'role' fact defined for each of these groups. The role fact will have the same name as the group name. The reason this is useful is that bolt does not have to wait for puppet to collect facts on each target before switching on this 'role'. If I only wait for puppet to return a target's facts, then bolt is effectively blind for the first run. It cannot switch on particular target facts that it doesn't have. Since we're creating the bolt inventory and know relevant information about the targets, then I want this always available.
 
 ## Decision
 
-Therefore, I decided to add a `${facts['role']}` for each group where the 'role' value is equal to the group name.  In other words, given a group called `agent` then the `$facts.role = 'group'`.
+Therefore, I decided to add a `${facts['role']}` for each group where the 'role' value is equal to the group name. In other words, given a group called `agent` then the `$facts.role = 'group'`.
 
 ## Consequences