No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

This surprises me. A lot of people reported getting “we are experiencing high remand” issues, but then their resources would not be created.

Are you creating the account in multiple regions? If so, are all of these regions actually provisioned, or just a subset of them?

<@UB39JFCKC> sorry for the late reply, apparently I had notifications silenced for this workspace for some reason…
We are only deploying to a single region. We tried a few different ones, but same result.
As to the question whether the region is actually provisioned, I think it is not. The account is created as a resource but a lot of the portal menu options are greyed out, and some parts of the resource blade seem to get errors loading.

Yeah, we see the same errors in our CI now. Looks like Cosmos DB is super restricted now.

Creating the Cosmos DB manually through the portal, however, seems to always work fine.

<@UB39JFCKC> since creating through the portal (and also by ARM deployment) work fine consistently, I can only conclude something needs to change on the Pulumi side. We are currently blocked by this, and we cannot use the workaround to import the resource into Pulumi after creating it manually; no matter how hard we try to match the inputs exactly to what the existing resource has, Pulumi complains that inputs don’t match existing resource properties (but does not state what differences it detects).

So you are going through this steps <https://www.pulumi.com/blog/adopting-existing-cloud-resources-into-pulumi/> ?

Yes, I went through those steps. <@UB39JFCKC>
Pulumi complains during the `import` command, at the points when it starts importing the Cosmos DB account resource. It will stay on “importing…” for a few secs, but soon fail with the error message stating that the properties of the existing resource don’t match the inputs.

Could you open an issue on pulumi-azure describing all of these so that we could track?

FWIW, you could work around this by embedding an ARM template into your Pulumi program for now, if that works

Possibly, I’ve done that for some other stuff.

You know what would be super useful <@UB39JFCKC>? If there was a `pulumi up --import` argument that, given the existence of a resource with the same name (at the cloud provider level), imports it into the state unconditionally, with whatever properties it has, *before* proceeding to do an `up` as usual.

That would work so beautifully in our situation where we always specify explicit resource names with the stack name embedded in them.

(Yes, I’ll open two issues, one for the Cosmos 503 issue, and one for the import issue)

yes, there are many import scenarios that we need to work through. yours sounds good to me