Commit graph

15 commits

Author SHA1 Message Date
Justin Van Patten
6b0a845cc1
Support publishing Python policy packs (#4644)
Adds support for publishing Python policy packs to the service, and downloading/using such policy packs when applied to stacks in an organization.
2020-05-22 15:01:15 -07:00
CyrusNajmabadi
66bd3f4aa8
Breaking changes due to Feature 2.0 work
* Make `async:true` the default for `invoke` calls (#3750)

* Switch away from native grpc impl. (#3728)

* Remove usage of the 'deasync' library from @pulumi/pulumi. (#3752)

* Only retry as long as we get unavailable back.  Anything else continues. (#3769)

* Handle all errors for now. (#3781)


* Do not assume --yes was present when using pulumi in non-interactive mode (#3793)

* Upgrade all paths for sdk and pkg to v2

* Backport C# invoke classes and other recent gen changes (#4288)

Adjust C# generation

* Replace IDeployment with a sealed class (#4318)

Replace IDeployment with a sealed class

* .NET: default to args subtype rather than Args.Empty (#4320)

* Adding system namespace for Dotnet code gen

This is required for using Obsolute attributes for deprecations

```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```

* Fix the nullability of config type properties in C# codegen (#4379)
2020-04-14 09:30:25 +01:00
evanboyle
48250176a1 Revert "move sdk/python/cmd/pulumi-language-python -> pkg/cmd/pulumi-language-python"
This reverts commit e2ee46fb23.
2020-03-18 17:11:56 -07:00
evanboyle
e2ee46fb23 move sdk/python/cmd/pulumi-language-python -> pkg/cmd/pulumi-language-python 2020-03-18 10:19:22 -07:00
Luke Hoban
95daaa8cec Fix broken test 2019-12-21 06:51:42 -08:00
Luke Hoban
265acaefe5
Fallback to looking for python when launching Python language host (#3692)
Fixes #3398.
2019-12-20 17:09:00 -08:00
Pat Gavlin
82204230e1
Improve tracing support. (#3238)
* Fix some tracing issues.

- Add endpoints for `startUpdate` and `postEngineEventsBatch` so that
  spans for these invocations have proper names
- Inject a tracing span when walking a plan so that resource operations
  are properly parented
- When handling gRPC calls, inject a tracing span into the call's
  metadata if no span is already present so that resource monitor and
  engine spans are properly parented
- Do not trace client gRPC invocations of the empty method so that these
  calls (which are used to determine server availability) do not muddy
  the trace. Note that I tried parenting these spans appropriately, but
  doing so broke the trace entirely.

With these changes, the only unparented span in a typical Pulumi
invocation is a single call to `getUser`. This span is unparented
because that call does not have a context available. Plumbing a context
into that particular call is surprisingly tricky, as it is often called
by other context-less functions.

* Make tracing support more flexible.

- Add support for writing trace data to a local file using Appdash
- Add support for viewing Appdash traces via the CLI
2019-09-16 14:16:43 -07:00
Sean Gillespie
03e70a188b
Flush stdout and stderr on abnormal lang shutdown (#2226)
The langhost shares its standard out and standard error with the
language executor that it is used (python/nodejs), so we must be sure to
flush our stdout and stderr before reporting a Run failure to the
engine.
2018-11-19 17:59:01 -05:00
Sean Gillespie
03dbf2754c
Launch Python programs with 'python3' by default (#2204)
'python' is not usually symlinked to 'python3' on most distros unless
you are already running in a virtual environment. Launching 'python3'
explicitly ensures that we will either launch the program successfully
or immediately fail, instead of launching the program with Python 2 and
failing with syntax errors at runtime.

This commit also emits an error message asking users to install Python
3.6 or later if we failed to find the 'python3' executable.
2018-11-19 17:54:24 -05:00
Matt Ellis
992b048dbf Adopt golangci-lint and address issues
We run the same suite of changes that we did on gometalinter. This
ended up catching a few new issues, some of which were addressed and
some of which were baselined.
2018-11-08 14:11:47 -08:00
Matt Ellis
d0485f11f6 Include Python and Go langhosts in Windows SDK
This change includes the Python and Golang language hosts in the Windows
SDK. As part of this change, I had to adjust how we launched the second
stage of the language host, since we can't depend on the shebang, so now
we invoke `python` passing the executor and then the arguments.

Fixes #1509
2018-06-15 11:12:33 -07:00
joeduffy
5967259795 Add license headers 2018-05-22 15:02:47 -07:00
CyrusNajmabadi
72e00810c4
Filter the logs we emit to glog so that we don't leak out secrets. (#1371) 2018-05-15 15:28:00 -07:00
Pat Gavlin
97ace29ab1
Begin tracing Pulumi API calls. (#1330)
These changes enable tracing of Pulumi API calls.

The span with which to associate an API call is passed via a
`context.Context` parameter. This required plumbing a
`context.Context` parameter through a rather large number of APIs,
especially in the backend.

In general, all API calls are associated with a new root span that
exists for essentially the entire lifetime of an invocation of the
Pulumi CLI. There were a few places where the plumbing got a bit hairier
than I was willing to address with these changes; I've used
`context.Background()` in these instances. API calls that receive this
context will create new root spans, but will still be traced.
2018-05-07 18:23:03 -07:00
joeduffy
74563afdc8 Get the empty Python program working
This change gets enough of the Python SDK up and running that the
empty Python program will work.  Mostly just scaffolding, but the
basic structure is now in place.  The primary remaining work is to
wire up resource creation to the gRPC interfaces.

In summary:

* The basic structure is as follows:

    - Everything goes into sdk/python/.

    - sdk/python/cmd/pulumi-langhost-python is a Go language host
      that simply knows how to spawn Python processes to run out
      entrypoint in response to requests by the engine.

    - sdk/python/cmd/pulumi-langhost-python-exec is a little Python
      shim that is invoked by the language host to run Python programs,
      and is responsible for setting up the minimal goo before we can
      do so (RPC connections and the like).

    - sdk/python/lib/ contains a Python Pip package suitable for PyPi.

    - In there, we have two packages: the root pulumi package that
      contains all of the basic Pulumi programming model abstractions,
      and pulumi.runtime, which contains the implementation of
      resource registration, RPC interfacing with the engine, and so on.

* Add logic in our test framework to conditionalize on the language
  type and react accordingly.  This will allow us to skip Yarn for
  Python projects and eventually run Pip if there's a requirements.txt.

* Created the basic project structure, including all of the usual
  Make targets for installing into the proper places.

* Building also runs Pylint and we are clean.

There are a few other minor things in here:

* Add an "empty" test for both Node.js and Python.  These pass.

* Fix an existing bug in plugin shutdown logic.  At some point, we
  started waiting for stderr/stdout to flush before shutting down
  the plugin; but if certain failures happen "early" during the
  plugin launch process, these channels will never get initialized
  and so waiting for them deadlocks.

* Recently we seem to have added logic to delete test temp
  directories  if a failure happened during initialization of said
  temp directories.  This is unfortunate, because you often need to
  look at the temp directory to see what failed.  We already clean
  them up elsewhere after the full test completes successfully, so
  I don't think we need to be doing this, and I've removed it.

Still many loose ends (config, resources, etc), but it's a start!
2018-02-23 19:33:02 -08:00