This message was deleted.

Hi @Thomas! I haven't used this yet, but I did notice this language in the PR:

This PR provides the ability of auto scaling the number of Kafka ingest tasks based on Lag metrics when supervisors are running.

Maybe the behavior you're reporting is expected? The other thing I noticed, under the Task Autoscaler Properties, is that it's still designated as experimental. I'm hoping that other people who have used this will chime in.

Sounds like a bug to me. I think the autoscaler config for a given supervisor should be a part of its persistent definition, it should only change if you change it. You can report the bug at https://github.com/apache/druid/issues and perhaps link the PR referenced above.

yeah, that isn't intentional, and seems strange. in i see a unit test specifically checking that the

autoScalerConfig

gets retained i wonder if there is something funny about your system? mixed versions, maybe? when you go to

/druid/indexer/v1/supervisor/<dataSource>

, while the autoscaler is configured, what do you see?

Hello, thanks for having a look. When I go to

/druid/indexer/v1/supervisor/<dataSource>

I can see my Supervisor spec with the autoScaler configuration

if that's there, then it means druid "understands" that you have an autoscaler set up — strange that it wouldn't be respected when you restart your OL

Nope, I’m using Packer + Ansible to create custom system images, so every box runs the same version

hmm. what are you using for a metadata store? Basically the way this works is your supervisor spec is stored in the

druid_supervisors

table of your metadata store, and your OL reads from that on startup. Generally I'd expect that if the API echoes back a given config, it's also stored that way in the metadata store, which means it'll be restored that way on next boot

I’m using a MySQL. Ok, so that’s definitely an issue since I can see autoScaler config in metadata store

good to hear!