The filter API is an abomination and should be avoided on principle. This is a purely ideological objection to how dumb the language design is in this arena, not a functional issue. For more, see D6672 / D6680. The whole thing is a bad implementation of a bad idea and nothing good can come of its use.

The rest of the design here is a little bit backwards from the intended approach. For static hosts, Drydock should never handle the allocation itself. Instead, some side-channel mechanism should just create the hosts. For example:

phabricator/ $ ./bin/drydock create-resource --type host ...

The localhost blueprint fakes its way through this, but only because it was easier. If Drydock isn't truly allocating resources, they shouldn't go through its allocation pathways.

Similarly, leases generally should not contain specific details about a host (like port, credentials, hostname). They may contain general specifications, like platform (eventually, it will probably be possible to be highly specific, but in the broad case we shouldn't be).

We should probably wait for T4122 for credential management.

We should probably get rid of the path stuff soonish too.

If the interface is gathered based on the blueprint, and we're creating resources without an associated blueprint, how do we provide interfaces to consumers of the preallocated resource?

For the sake of IRC being a madhouse right now -- the manually created resources would still have the right blueprint. The command would probably look more like --type host --blueprint BlahBlah -- or maybe just --blueprint, since I think the blueprint implies a type -- than the junk I typed.