Comment 1 for bug 1587929

abentley: about bug 1587929, here are my thoughts:
abentley: It is unfortunate that 2.0 requires more arguments than 1.x
abentley: This means that to use 2.0-style config, we either need to not-really-use 2.0 configs, or we need to supply more arguments.
abentley: We would need to supply more arguments to all our tests, which would mean changing basically every job.
abentley: So, it's a PITA, but we'll probably have to do it at some point.
abentley: We can cheat our way around it if we want.
abentley: We can get the cloud/region from a comment in the bootstrap config. My conversion from environments.yaml to 2.0 configs provided that.
abentley: So assuming that we have cloud/region one way or another, we then need to be able to test 1.x. So we need to generate SimpleEnvironment. We could write a factory method on JujuData that would generate an equivalent SimpleEnvironment.
balloons: effectively making everything 2.x, with 1.x supported via generation
abentley: Right.
abentley: The remaining issue is old-Azure and local provider.
abentley: These are not supported in 2.0, so putting them in a 2.0-style config is a little crazy. But I think it could work.
abentley: The other option is to keep environments.yaml around, only for local provider and old-Azure. That doesn't seem like a win, because we would not be able to kill our environments.yaml code.
balloons: would it then be something folks have to understand in order to actually test with 1.25? I don't really care about old-azure (should I?). but local provider seems pertinent
abentley: It would be more an issue that these are attractive nuisances.
abentley: You're running 2.0, you say "Sure, I'll try testing with non-arm-azure.yaml", and then it pukes all over the place.
balloons: is it possible to simply ignore environments.yaml if we have 2.0 style config?
abentley: What would it mean to have 2.0-style config?
abentley: For example, cloud-city right now has model-config/*. Does that count as "have 2.0 style config"?
balloons: I suppose the "right" answer is to use environments.yaml if it exists, otherwise require more args?
abentley: I don't know what's right there. I know that it's a pity to have to keep all our environments.yaml code. I know that we won't have fixed your bug if we keep environments.yaml. I know that having sometimes-mantatory arguments is a pain.
abentley: Having bogus 2.0 config-files is bad, but maybe better than those options. We could put them in a special directory.