fake-gcs-server currently supports only a single Pub/Sub notification configuration, which is more limited than the multiple notification configurations supported by Google Cloud Storage. This means users cannot model certain system architectures with fake-gcs-server, namely, those which use multiple notification configurations (e.g., upload events in different buckets sending messages to different Pub/Sub topics).
Ideally, fake-gcs-server would support specifying multiple notification configurations on the command line so that users can use it for integration testing in these more complex system architectures.
A notification configuration has a well-defined model and is always attached to a specific bucket. Since buckets may not exist before fake-gcs-server starts, I think the best solution to handle nonexistent buckets would be to treat the bucket as a filter such that the configuration is treated as if it doesn't exist if the bucket it's attached to doesn't exist.
fake-gcs-servercurrently supports only a single Pub/Sub notification configuration, which is more limited than the multiple notification configurations supported by Google Cloud Storage. This means users cannot model certain system architectures withfake-gcs-server, namely, those which use multiple notification configurations (e.g., upload events in different buckets sending messages to different Pub/Sub topics).Ideally,
fake-gcs-serverwould support specifying multiple notification configurations on the command line so that users can use it for integration testing in these more complex system architectures.A notification configuration has a well-defined model and is always attached to a specific bucket. Since buckets may not exist before
fake-gcs-serverstarts, I think the best solution to handle nonexistent buckets would be to treat the bucket as a filter such that the configuration is treated as if it doesn't exist if the bucket it's attached to doesn't exist.