uniformize getting hook through cached property in aws sensors

[vandonr-amz]

also caught some hooks that were created in the ctor.

[ferruzzi]

Some of these files you are passing region to the hook and others are not. Should we standardize that as well?

[vandonr-amz]

I mostly kept the existing behavior. I don't know what is a real use case for passing the region, maybe that depends on the operator/sensor ?

[Taragolis]

Somewhere in the past I have an idea to keep Sensors/Operators more consistent and provide all of supported parameters in Hook.
I think it safe to pass region_name because we set it to None by default in Operators/Sensors.

[Taragolis]

BTW , it is not related to this PR, but we have a 3 different hooks which is wraps around Glue.Client 🤦

• airflow.providers.amazon.aws.hooks.glue.GlueJobHook
• airflow.providers.amazon.aws.hooks.glue_catalog.GlueCatalogHook
• airflow.providers.amazon.aws.hooks.glue_crawler.GlueCrawlerHook

[ferruzzi]

BTW , it is not related to this PR, but we have a 3 different hooks which is wraps around Glue.Client facepalm

Yeah, there is also a BatchWaiterHook which is an oddball too. Some Day ™️

[Taragolis]

In one recent PR I mark Hooks as Thin and Thick wrapper, so we could easily find them in "Some Day"

❯ grep -rl 'thick wrapper' airflow/providers/amazon/aws/hooks
airflow/providers/amazon/aws/hooks/emr.py
airflow/providers/amazon/aws/hooks/dynamodb.py
airflow/providers/amazon/aws/hooks/batch_client.py
airflow/providers/amazon/aws/hooks/kinesis.py
airflow/providers/amazon/aws/hooks/glue.py
airflow/providers/amazon/aws/hooks/sagemaker.py
airflow/providers/amazon/aws/hooks/ec2.py
airflow/providers/amazon/aws/hooks/datasync.py
airflow/providers/amazon/aws/hooks/athena.py
airflow/providers/amazon/aws/hooks/s3.py
airflow/providers/amazon/aws/hooks/elasticache_replication_group.py

[ferruzzi]

Tack onto the "Some Day" list, converting as many hooks as possible to thin hooks, maybe with a Protocol class for IDE type hinting and completion. I didn't like the EcsProtocol and BatchProtocol classes at first, but they grew on me.

Anyway, we should maybe get a list of "easy but tedious suggestions" like this for new contributors to flip through, but we're getting way off track here 😛

[Taragolis]

I also like an idea @o-nikolas generate hooks for all supported services #28560 (comment)

[ferruzzi]

One discussion left about whether we should be passing region to every hook, but I think that can be sorted in another PR if we do it.

[vandonr-amz]

One discussion left about whether we should be passing region to every hook, but I think that can be sorted in another PR if we do it.

yes I'd rather keep this PR well rounded like this

[Taragolis]

One discussion left about whether we should be passing region to every hook, but I think that can be sorted in another PR if we do it.

I think ideally we should pass every generic hook's arguments from operator.
But let do it in another PR