Open paul-ri opened 10 months ago
Interesting bug, unfortunately the way connectors generate inventory means it will always try to load before we can apply a limit. But maybe we shouldn't be failing here at all and actually it should fail at connect time, since the VM config exists.
I'll need to do some testing with Vagrant for this.
Describe the bug
With only 1 Vagrant VM existing and up, and an inventory referring to multiple Vagrant VMs by name,
--limit
is not applied early enough and the Vagrant config of non-existing VMs tries to be fetched but failsI think the error starts from this line where the Vagrant connector tries to fetch a VM config before applying the limits
https://github.com/pyinfra-dev/pyinfra/blob/7540c41fa0284b8dd80dcbea24d3616414484d60/pyinfra/api/inventory.py#L101
My use case: well it's quite an edge case. I was trying something so replaced all our SSH targets with variations of
@vagrant/XXX
in order to be sure to not touch the real ones. I was trying to learn how--limit
worked. Using mock@ssh/foo
works fine as a workaround for me.To Reproduce
Start one Vagrant VM. Have an inventory referring to two VMs where one doesn't exist yet, then apply a limit.
calling pyinfra with
pyinfra inventory.py <some_operation> --limit prod_a
will fail due to pyinfra trying to get the config info on prod_b anywaysExpected behavior
I would expect for pyinfra to handle the
--limit
argument and not try to make a connection to VMs not mentioned in--limit
Meta
pyinfra --support
.How was pyinfra installed (source/pip)? Pip
Include pyinfra-debug.log (if one was created) empty
Consider including output with
-vv
and--debug
.