Comment 9 for bug 1674596

IMHO using some config option for skipping might be a good idea (default not skipping).

Looks like it is possible to create an ipv6 deployment where the WaitCondition would be able to work, but not with this test case, since the test creates an ipv4 vm and the heat API is ipv6 only,
The possible ipv6 variant(s) of the test are so different to the current one, and it would require a different template to work, so it would be a completely different case(s)..
This ipv6 deployment does not feels like to the today's best practice, but it is possible.

`OpenStack API network` Do you consider swift as part of this network ?

ATM I am unsure about what would be the best `future proof` skip condition and option,
because both cases just fails this testclass.

We do not really want to have too many options in the tempest.conf, and we also do not want to change them frequently (we have to depreciate them first..)

Do we want to go with some WaitCondition specific option, or with some generic property of the default tenant network(s) or the external network routeability ?

Is the design decision expected to stay at tomorrow ? Are you planning to add some NAT or route rule (as many of us does it on test systems) ?