Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding support for diff and read #20

Closed
lukehoban opened this issue Dec 15, 2021 · 10 comments
Closed

Consider adding support for diff and read #20

lukehoban opened this issue Dec 15, 2021 · 10 comments
Assignees
Labels
kind/enhancement Improvements or new features resolution/fixed This issue was fixed

Comments

@lukehoban
Copy link
Contributor

These operations are supported in the Resource model, and could be delegated to commands to run on each operation. The use cases for these are not quite as rich as create and delete, but could open up additional new use cases.

@lukehoban
Copy link
Contributor Author

The curl example in #27 is an example that could in principle benefit from this. The color and description of a label can be updated without destroying and recreating the label, but there is no way to represent this today with the API. The only thing we can implement is that any chance requires replacing the label with a new one.

@elivaknink
Copy link

a use case where we need to use a command on update:
when we increase an EBS volume we want to extend the corresponding filesystem on the instance and we need to run some ssh command to do so - see this aws article - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

in this case, the change is considered as update in Pulumi, so if the command module would support update we can implement it by using it.

@ghostsquad
Copy link
Contributor

I think the way that go-task does this would work. The provide status field, that lets you specify any arbitrary commands to run in order to determine if a "task" should be rerun or not.

https://taskfile.dev/#/usage?id=using-programmatic-checks-to-indicate-a-task-is-up-to-date

The indicator isn't a diff, but rather just the exit code of the status commands that are run (if any of them exit with code 1, then the task is out-of-date and needs to rerun).

The Command provider could serialize state, and provide it to either stdin or as an argument to an diff command, which would be able to report whether or not the "resource" would needs to be updated or "recreated".

@jonthomp
Copy link

jonthomp commented Apr 4, 2022

I would like to see this for sending updates to configure external services via API or similar

@segator
Copy link

segator commented May 1, 2022

we defintelly need update and ideally diff.
I thinking to switch all my company TF projects to pulumi but this is a big stopper for me, also no support for dynamic provider in GO :(

@joeduffy
Copy link
Member

Another thing worth considering: recreateOnUpdate: true.

For idempotent commands, it would be really nice to trigger re-running the create when an update occurs. I've found myself wanting this many times during active development. Otherwise, you need to delete the command, run an update, add back the new command, rerun an update. This can make the inner development cycle a bit laborious.

@ossareh
Copy link

ossareh commented Feb 9, 2023

Edit: If you find yourself here note that the docs are out of date and update exists as an option 🎉


This would also be helpful in the k8s w/ helm case. I'd like to do something like:

const cluster = ...;
const chart = k8s.helm.v3.Release("installation" { ... });
const rollout = new local.Command("rollout", {
    // create not needed because it's the default behavior to start pods when creating the resources in the chart
    update: "kubectl -n namespace rollout deployment installation-foo",
    environment: {
        KUBECONFIG: cluster.kubeconfig,
    },
}, {
    dependsOn: [chart],
});

In my actual case the types of changes I tend to be making are in permissions assigned to the service account that the deployment specifies via annotations; these sometimes cause the annotation to change value, and sometimes are purely upstream changes in my cloud provider. k8s will only automatically trigger updates to the template spec for the pods in the deployment.

@AaronFriel AaronFriel added the kind/enhancement Improvements or new features label Mar 31, 2023
@gflarity
Copy link

gflarity commented Apr 4, 2023

I was bit surprised this wasn't already supported. As a Pulumi newbie, I was hoping/thinking pulumi-command was just a convenience replacement for a dynamic resource providers. Ie, the logic might be in shell scripts, but most of the functionality is available. For my use case I'm going to need to write my own dynamic resource provider that shells out, just so I can run updates. I'll probably even just have diff indicate that an update always needs to happen just to keep it as simple as possible.

@lukehoban lukehoban changed the title Consider adding support for diff, update and read Consider adding support for diff and read Jul 25, 2023
@thomas11 thomas11 added the resolution/fixed This issue was fixed label May 14, 2024
@thomas11
Copy link
Contributor

Since the discussion on this issue was all about Update, which is now implemented, I'll close this issue. Follow-up issues #433 and #432 are dedicated to discussing scenarios for Diff and Read.

@pulumi-bot pulumi-bot reopened this May 14, 2024
@pulumi-bot
Copy link
Contributor

Cannot close issue:

  • does not have an assignee

Please fix these problems and try again.

@thomas11 thomas11 self-assigned this May 14, 2024
@lukehoban lukehoban mentioned this issue May 18, 2024
12 tasks
thomas11 pushed a commit that referenced this issue Jul 15, 2024
The README points to #20
and says `Update` isn't implemented.

[Diff](#433) and
[Read](#432) are still
not done, but [Update is
implemented](https://github.com/pulumi/pulumi-command/blob/e7e39fd913708c3e5255d8399c87a736553fec43/sdk/python/pulumi_command/remote/command.py#L196)

The example code could be updated (hah!) to include an `update` (maybe
with Luke's `color`/`description` example), but this PR just removes
information that misled me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests