Generate TargetAllocator CR from Collector CR
Description:
Generate a v1alpha2.TargetAllocator based on v1alpha1.Collector. The change doesn't have any effect, it simply adds the function and modifies the TargetAllocator CRD.
One noteworthy change that I'd like some feedback on is the addition of scrape configs to the TargetAllocator CRD. This is something we've missed, and which is necessary for the CR to have feature parity with the subresource. Unfortunately this makes things a bit messy, as it's necessary to parse the Collector configuration to get these values, but I don't think there's any alternative.
Currently missing from this PR:
- [x] more unit tests
- [x] rebase on #2532
- [x] rebase on #2564
Link to tracking Issue: #2516
Testing: Aside from unit tests, I also have another change which converts all TA manifest generation to use the TargetAllocator CR, and all E2E tests pass there.
I'm wondering if it wouldn't be better to first merge #2621, then add a v1alpha2 version of the embedded TA spec, take care of conversion, and then generating the CR will be much simpler. WDYT?
On the other hand, it's useful to have the CR in its desired from in main, and it's not like merging this PR will hurt either way. But I do think we should land #2621 first.
Agreed, i think this becomes simpler with #2621
I'd also like to merge #2623 first, then the conversion in this PR becomes trivial.
This is now ready for review. I've rebased my manifest generation changes on it, and everything works there as well.
I did some reconciliation tests and ended up switching to AnyConfig for the ScrapeConfigs field. I couldn't make it any nicer, so in the end there wasn't any reason to have two implementations of the same thing.