Not possible to use an existing S3 Bucket about ion

[fwang]

In v0.0.254, you can now subscribe to a pre-existing bucket like this - https://ion.sst.dev/docs/component/aws/bucket/#static-subscribe.

[thdxr]

i think the issue here is we expose a bucket.subscribe function

this doesn't actually have any dependency on sst.aws.Bucket besides needing the bucket name

we probably should consider creating a sst.aws.BucketSubscriber that accepts a bucket name and treating subscribe as an shortcut to that

that would solve your problem

i want to also restate that the cdk concept of "importing a resource" isn't applicable here - it's a weird artifact of their over use of OOP and not really related to importing anything

[thdxr]

using existing resources will work a bit differently in ion

we're still working on this feature but basically you will run something like sst import MyBucket <my-existing-resource> which will do a one time import into your state

from there everything will work as though sst created the resource in the first place

the issue you're running into though is unrelated i will look into it

[budmitr]

thanks for the reply @thdxr, it gets clearer how things will be later
however, potential issues with this approach are possible

a use case I have is to manage an infrastructure for several environments, where things have been already provisioned with terraform
with sst v2 one can use references to SSM parameters in that existing infra (or define .env variables) to read critical identifiers (e.g. a unique random bucket name) and can attach notifications to it

so if locally I can run sst import and have a state for environment dev, but then I'd like to automate the whole process and test the same thing in environment staging and ensuring that all works apply to production
so the only way I see it now is to use bash script that would iterate over hardcoded set of resources 😢

SST is great as it frees from having bash scripting, so anything that can be managed in a type-safe way in the typescript code would be fantastic
really hope this can happen some way other than CLI commands only

the pulumi native code is weirdly broken, but if that would work I believe there were no issue

[thdxr]

so assume you have an existing bucket provisioned by terraform

you cannot really have two tools that own the same bucket so it does not make sense to do something like the following

new sst.aws.Bucket("MyBucket", {
  importFrom: "existingbucket"
})

if you change properties on here should it change the underlying bucket? if so then the terraform deployment will see it it as drift and revert it

you basically have to pick which is the source of truth - if it's terraform then you have no need to use sst.aws.Bucket - you can just grab the existing one if you need to reference with aws.s3.getBucket and it's readonly

if you want to hand off ownership to sst then you do a one time sst import which will import the state of it into the state file - from then on it's no different than the bucket originally being created by sst

the one time imports are preferable because otherwise you'd need to have some map in your code of stage -> resource for every single stage you have and every single existing resource you have

[budmitr]

I see the point, @thdxr, you are totally right here.
Taking full control over resource is exactly what I would use import for.

But the use case is different, my apologies for the unclarity.
The situation that I try to achieve with ion is a replication of what already works with SSTv2

• terraform owns stable, data-critical resources (buckets, databases, network etc);
• SSTv2 owns unstable, volatile resources like lambda functions, roles, permissions, notifications.

This works great -- terraform is happy, no changes from SST affect the critical parts, and the whole SST stack (cdk-based) can be safely removed/redeployed without any danger to delete the data.
This also helped a lot to split the responsibilities in the team and reduce risks of data loss in production

This is what I am looking for in ion as well. It is not about taking full control over resource, where import would fit perfectly.
Instead, it is about owning only volatile resources such as lambdas, notifications, roles, and linking them to already existing resources (vpcs, buckets) declared elsewhere (can be done with SST2/SST-ion/pulumi/terraform, but in another repo).

Establishing a read-only reference to a resource, like a Bucket, without taking control over its lifecycle, is a great and battle-tested use case of SSTv2 that enables safe boundaries between volatile and stable parts of the infrastructure