CRDs are our contract with the consumers of these event sources. They expose what users can do, contain a fairly comprehensive documentation, and provide validation of spec attributes.
Pod specs, on the other hand, require obscure environment variables to function, and we don't commit to keeping these environment variables stable. Environment variables, as well as any additional configuration inputs to receive-adapters, are meant to be populated by controllers and should be considered an implementation detail.
Besides, deploying the adapter Pod is in some cases (S3, SNS) not sufficient to get a fully functional event source, because controllers need to reconcile (set up) additional external AWS resources.
Power users are welcome to reverse engineer the input provided by controllers to receive-adapters if they want to run these as standalones.
CRDs are our contract with the consumers of these event sources. They expose what users can do, contain a fairly comprehensive documentation, and provide validation of spec attributes.
Pod specs, on the other hand, require obscure environment variables to function, and we don't commit to keeping these environment variables stable. Environment variables, as well as any additional configuration inputs to receive-adapters, are meant to be populated by controllers and should be considered an implementation detail.
Besides, deploying the adapter Pod is in some cases (S3, SNS) not sufficient to get a fully functional event source, because controllers need to reconcile (set up) additional external AWS resources.
Power users are welcome to reverse engineer the input provided by controllers to receive-adapters if they want to run these as standalones.