Denominator 4.4 on the way. Hands welcome!

[Adrian Cole]

Hi, all.

I know.. it has been over a year!

Releasing 4.4 will include discoverydns, which I think has never been
released! Before that, I'm going to update denominator to feign 7.2.0,
which is in turn compatible with dagger 1.2.2. There are some issues
on the hopper, too. If anyone has some time to help with these, let me
know, else I'll have a look.

Many providers, including discoverydns, I no longer have credentials
to. If you can help test, or give me access, ping back. I might not
fix anything, but me having credentials significantly increases the
chance of fixes occurring :)

Once 4.4 is working, I plan to remove dagger from 5 and cut that.
Reason is that dagger 1 and 2 are incompatible, and I don't want to
further a mess by choosing one or the other. Better to just give
denominator a builder and call it a day.

Anyway, rough eta is w/in the next couple weeks.

See you later!
-Adrian

[Adrian Cole]

More work to do, but I thought I'd pass along the output of a test refactor.

https://github.com/Netflix/denominator/blob/master/designate/src/test/java/denominator/designate/DesignateResourceRecordSetApiMockTest.java

This is past "wave 1" which switches to assertj. Once all providers
have this style, I'll convert the tests to use junit. Then, I will
make classes like MockDesignateServer a test rule, avoiding
boilerplate.
-A

[Adrian Cole]

route53 test refactoring "wave 1" done. will do ultradns next.

https://github.com/Netflix/denominator/pull/286

[Adrian Cole]

I lied. I did wave 1 of discoverydns first.

https://github.com/Netflix/denominator/pull/287

[Adrian Cole]

OK all the providers are converted to new test assertions. Next step
is a doozy, which is to rewrite the base test classes from TestNG to
JUnit. I should have this done in a week. Once that's in, I'm
confident the test infrastructure is good for another year or so.

We can then start cleaning up any bugs etc and cut 4.4

-A

[Jeffrey Damick]

Just curious, why'd you decide to change to junit?

[Adrian Cole]

Sure a few reasons.

Most importantly, JUnit rules are easier to reason with and compose than TestNG annotations and subclasses. Ex. there are JUnit rules we can use to verify logging, exceptions, even System.err! Also, our mock and live tests would be less boilerplate or complicated as composable rules vs what we do now.

Secondly, JUnit's lifecycle is simpler. We have a lot of tests that need to be marked single threaded or similar because TestNG defaults to sharing test instances.

Finally, the assume feature is a nicer way of dealing with conditional tests than throwing skip exceptions.

In short, TestNG was > JUnit for us years ago. However, modern JUnit and especially rules (that other people write) makes what we do simpler.

Make sense?

-A

[Adrian Cole]

FYI, finishing up the test conversions.. nearly done. Apologies about
the delay. Unfortunately, this is one of those big bang things, as
changing the test framework breaks everything unless everything is
converged. ETA this week, for real.

In the mean time, I'm missing credentials for the following, so would
appreciate them, or someone to offer to run live tests.

ultradns
designate
discoverydns
dynect

-A

[Adrian Cole]

OK All test conversions are done, and another 1K lines are out of the project

https://github.com/Netflix/denominator/pull/298

Next up is to actually run the live tests and address any bugs or
features folks want in the next release. I'm done with massive
refactoring for a while.

-A