@high-morning-17948 you can share your findings about the AWS Batch build 🙂

👋🏻 im susan a ux designer at Pulumi and i am looking for folks that have had a frustrating experience using our docs. id love to do a quick 15-minute zoom call to hear about your experience. ill use your information to help guide improvements to our docs. if ur interested add an emoji to this message and ill reach out in dm to schedule something. thank you!!

Where are the

pulumi.yaml

and

pulumi.<stack>.yaml

schema defined?

From https://www.pulumi.com/docs/intro/concepts/programming-model/#names

The name specified during resource creation is used in two key ways:

As a default prefix for the resource's physical name, assigned by the cloud provider.
To construct the Universal Resource Name (URN) used to track the resource across updates.

Note that the variable names you use for resource objects aren't used in any way for either logical or physical resource naming. The variable simply lets you refer to that resource elsewhere in your program.

So, the name is used to generate the resource's physical name, or it's not....?

Which one is it?

I'm guessing that's what's meant by this documentation is that the variable name used for the resource object doesn't necessarily correspond exactly to the name generated by the cloud provider (it's only used as the prefix).

But, "the variable names you use for resource objects aren't used in any way for the ... physical resource naming" is confusing, then.

My guess comes from earlier on the same page:

All resources have a required name argument, which must be unique across resources of the same kind in a stack. This logical name influences the physical name assigned by your infrastructure's cloud provider, although Pulumi auto-names resources by default, so they may differ.

Oh, I understand, now. The documentation says "the variable names you use for the resource aren't used for the physical/logical names". Of course.

Adding that information is only confusing, I think... But, if it really needs to be said, then I think you should refer to the variable name in the example given immediately above (

role

, in this case).

New problem with the docs..... 🙂

Addressing a note from https://www.pulumi.com/docs/intro/concepts/programming-model/#autonaming:

This random suffix is added for two reasons:
1. ....
....
...

2. It allows Pulumi to do zero-downtime resource updates. Certain updates require replacing resources, rather than updating them in place, due to the way cloud providers work. By default, Pulumi creates replacements first, then updates existing references to them, and finally deletes the old resources. If it weren't for auto-naming, Pulumi would need to do things in a very different order: namely, it would need to delete resources first, and create new instances afterwards, which is far more impactful and leads to downtime.

This isn't true.

Pulumi could avoid auto-naming and still have zero-downtime resource updates (where zero-downtime, I guess, here, means that a resource is never completely unavailable).

If you wanted to keep my name as exactly "mr. special name" and update the resource which requires a replacement, then Pulumi could implement the following N-step process: 1. Create a temporary resource ("mr. special name - temp") with the updated resource options 2. Point existing resources to "mr. special name - temp") 3. Destroy "mr. special name" 4. Create new "mr. special name" with updated resource options (identical to "mr. special name - temp" in configuration) 5. Point existing resources to "mr. special name" (the updated version, now) 6. Destroy "mr. special name - temp"

This has obvious disadvantages, but it's a similar pattern as what's already done with autonaming. So, it's just as possible to create new resources using "autonaming" as without "autonaming", at least as far as the second point of the documentation is concerned. The first point is valid and is sufficient to justify "autonaming".

I recommend removing the second point from the documentation unless my logic is wrong regarding the shuffling that Pulumi could perform to avoid autonaming.

Are there any docs for writing a provider plugin? Are the various language implementations hand-authored, or they are codegen'd from a master definition? (in Go? from Terraform?)

https://www.pulumi.com/docs/intro/concepts/programming-model/#inheriting-resource-providers

To support, this component resources accept a new 

providers

 option that other custom resources don’t have.

(I think the comma is meant to be after "this") I found this whole section hard to understand - it's not clear how the component then makes use of the providers that you pass in via ResourceOptions I found an example of passing

providers

here: https://github.com/pulumi/examples/blob/fab792ac043eae9cf74ddb1ee73fda33cd533eaa/azure-ts-aks-keda/keda.ts#L63 but could not see any obvious use of it in what I think is the matching resource: https://github.com/pulumi/pulumi-kubernetes/blob/master/sdk/nodejs/helm/v2/helm.ts is it something that happens implicitly?

ok I found this: https://www.pulumi.com/docs/intro/concepts/programming-model/#resource-providers

The resource provider for a custom resource is determined based on its package name. For example, the 

aws

 package will load a plugin named 

pulumi-resource-aws

, and the 

kubernetes

 package will load a plugin named 

pulumi-resource-kubernetes

. Each provider uses the configuration from its package to alter its behavior.

AFAICT "package name" means like

pulumi-kubernetes

i.e. https://github.com/pulumi/pulumi-kubernetes/ the parent of the

k8s.helm.v2.Chart

from

helm.ts

so I guess the standard package naming scheme changed since those docs? And... the point of all this is... a kind of dependency injection? so in the keda example we're injecting a specific instance of the kubernetes provider, rather than letting

Chart

use the one from https://github.com/pulumi/pulumi-kubernetes/blob/master/sdk/nodejs/provider.ts which it otherwise would?

Found a typo. "Kubernetes" is misspelled halfway the sentence:

The Pulumi Kubernetes Operator is an extension pattern that enables Kuberentes users to create a

Stack

as a first-class API resource, and use the

StackController

to drive the updates of the Stack until success.

https://www.pulumi.com/docs/guides/continuous-delivery/pulumi-kubernetes-operator/#overview

https://www.pulumi.com/blog/aws-lambda-container-support/ -> thanks for the article! Glad to see container support in Pulumi so soon! Just a note: Lambda now supports up to 10GB of memory rather than 3GB as stated in your article! https://aws.amazon.com/blogs/aws/new-for-aws-lambda-functions-with-up-to-10-gb-of-memory-and-6-vcpus/

@abundant-appointment-96790 Thanks for letting us know, Andy! We’ll get an update out soon.

The gihub documentation here https://www.pulumi.com/docs/reference/pkg/github/actionsorganizationsecret/ for the visibility attrribute, doesn't show any info. It should inform about the possible values: https://registry.terraform.io/providers/integrations/github/latest/docs/resources/actions_organization_secret#visiblity

The typescript example here is borked, I've had no luck trying to make it work. Not sure if it was 1.x functional and got auto-updated to 2.x. Is this room the right place to report or do I need to put in a github issue? https://www.pulumi.com/docs/reference/pkg/aws/acm/certificatevalidation/#dns-validation-with-route-53

Hey everyone, the flat list of examples in our examples repo (https://github.com/pulumi/examples) could use some organization, so we’d love to hear some ideas of how you’d like to see things laid out. By language then cloud provider (or the other way around)? By use case? Some other sort order? Feel free to provide your suggestions here or on https://github.com/pulumi/examples/issues/908. Thanks!

i think the docs are not parsing correctly some terraform docs. Specifically here: https://www.pulumi.com/docs/reference/pkg/aws/ecs/service/#ignoring-changes-to-desired-count the parsing of the

lifecycle {
    ignore_changes = [desired_count]
  }

from terraform, is not properly transalted to the

ignore_changes

in the

opts

also, the description for https://www.pulumi.com/docs/reference/pkg/aws/ecs/service/#wait_for_steady_state_python is empty in terraform docs it does have some info

Also, the arg "name" dosen't have the

*

indicating that is required