title: "Nov. 17 releases: `dependOn` Helm charts, new Elastic Cloud provider, functions support outputs, set the CLI's default organization"
date: 2021-11-17T08:00:00-07:00
draft: false
allow_long_title: true
meta_desc: The latest Pulumi updates include a new provider for Elastic Cloud, easier ways to create more complex infrastructure, better support for organizations, & more
It's been another exciting few weeks here at Pulumi! We've caught our breath from [Cloud Engineering Summit](/cloud-engineering-summit/) (don't forget to check out the talks if you haven't yet!) and we're back to adding new value and highly-requested fixes across the Pulumi Cloud Engineering Platform. Read on to learn about new providers, new enhancements to the core Pulumi experience, and more!
- [`dependsOn` can now await a fully-deployed Helm `Chart` resource](/blog/pulumi-release-notes-m64#dependson-can-now-await-a-fully-deployed-helm-chart-resource)
Pulumi's [`dependsOn` option](/docs/concepts/resources#dependson) enables you to write programs that deploy resources in a specific order. Previously, using this option with a Helm `Chart` resource could be confusing because Pulumi would consider the resource ready once it had registered the chart, even if Helm was still deploying some of the resources defined by the chart. Now, you can depend on a new `ready` attribute that will ensure that none of the dependent resources are deployed until the chart is deployed. For example, the code sample below creates an NGINX Ingress Controller and then creates a Kubernetes `ConfigMap` that depends on the controller being fully deployed.
This change impacts the older Helm [`Chart`](/registry/packages/kubernetes/api-docs/helm/v3/chart) resource. The new Helm [`Release`](/registry/packages/kubernetes/api-docs/helm/v3/release) resource always waits for the Helm chart to be fully deployed.
You can now provision Elastic Cloud resources like ElasticSearch using Pulumi! Visit the [`ElasticCloud (EC)` provider on Pulumi Registry](/registry/packages/ec) to get started. The example below shows how you can create an Elastic Cloud deployment in just a few lines of code:
Most Pulumi providers support [auto-naming for resources](/docs/concepts/resources#autonaming), which makes it easier to have multiple stacks of the same Pulumi program by avoiding naming conflicts, among other benefits. Now, our AWS Native provider joins the club with full auto-naming support.
[Learn more about AWS auto-naming in this GitHub issue](https://github.com/pulumi/pulumi-aws-native/issues/156)
### New resources in the AWS Native provider
We shipped new versions of the AWS Native provider (0.3.0 through 0.4.0) that added [38 new resources](https://github.com/pulumi/pulumi-aws-native/compare/v0.2.0...v0.4.0#diff-1ac835cc58d7899e9299c7570151c7b0d7732c78f1bd53fe25fd4189b72e168e) giving you access to resources like `AWS::EKS::Cluster`, `AWS::Lightsail::Database`, and several new resources in the `AWS::Redshift` namespace.
We shipped new versions of the Azure Native provider (1.43.0 through 1.45.0) that collectively added [4 new resources](https://github.com/pulumi/pulumi-azure-native/blob/master/CHANGELOG_OLD.md#1450-2021-11-05) giving you access to resources like Cognitive Services.
In this milestone, we shipped Pulumi version [3.17.0](https://github.com/pulumi/pulumi/releases/tag/v3.17.0). The full list of changes in this version is available in the [changelog](https://github.com/pulumi/pulumi/blob/master/CHANGELOG.md); read on to learn about some of the biggest changes.
When creating complex infrastructure, it's common to pass information about one resource to a function provided by another resource. Previously, doing this in Pulumi required you to use `apply` to get the information from the first resource and pass it into the function. Now, we've simplified the process so you can reference outputs directly from the function—no `apply` needed. To take advantage of these changes, make sure you've updated to the latest versions of Pulumi and the providers you're using.
### `--json` flag for `pulumi {update|destroy|preview|refresh}`
When automating or troubleshooting Pulumi operations, it can be helpful to see all of the details emitted by the Pulumi engine rather than the standard progress bar. Now, you can! Just add `--json` to your `pulumi {update|destroy|preview|refresh}` command.
[Learn more about the new `--json` flag in this GitHub issue](https://github.com/pulumi/pulumi/issues/2390)
### Python 3.6 support will be deprecated soon
Python 3.6 will be end-of-lifed ("EOLed") on [December 23, 2021](https://www.python.org/downloads/#:~:text=2016-12-23-,2021-12-23,-PEP%20494). Around that time, Pulumi will drop support for Python 3.6. If you're using Python 3.6, consider upgrading to a newer version of Python. The Pulumi CLI will display a message when it runs a Pulumi program using Python 3.6.
[Learn more about Python 3.6 deprecation in this GitHub issue](https://github.com/pulumi/pulumi/issues/8131)
## Pulumi Service & Pulumi.com
### Set the default organization for newly-created stacks
If you're using Pulumi as part of a team or company, rather than as part of a personal project, you likely want to ensure that any infrastructure you deploy is registered in your company's Pulumi organization, rather than in your personal Pulumi account. Previously, you needed to either create each stack inside the organization (`pulumi new -s <org>/<stackname>`) or transfer stacks into the organization once created. Now, you can set the default organization for Pulumi to use when creating new stacks: `pulumi org set-default <org>`. Watch the asciinema recording below to get a feel for how it works: