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

resources updates not applied #63

Closed
treywelsh opened this issue Oct 8, 2020 · 9 comments
Closed

resources updates not applied #63

treywelsh opened this issue Oct 8, 2020 · 9 comments

Comments

@treywelsh
Copy link
Collaborator

treywelsh commented Oct 8, 2020

Resource updates are marked as applied in the plan even when not applied on the cloud provider.
We don't handle if a part could be updated or not there is no check, and there is no documentation.

Here's the quote from a team member on the problem:

For some resources modified post-spawned VM like `tags` or in context params like`START_SCRIPT[_BASE64]`, 
the ONE provider indicates that changes has been applied with success but in fact, nothing appeared in Sunstone.

It should inform the user that this resource is immutable, 
or do a force-replaces to apply it effectively (like AWS do with `user_data`) instead of silently fail.
```
@ilhaan
Copy link

ilhaan commented Oct 13, 2020

Seeing the same issue

@jaypif
Copy link
Collaborator

jaypif commented Oct 13, 2020

Hi,

Context update are not taken into account.
Tags update work but not context change. context change are only possible during VM instantiation. You need to destroy and recreate the resource to apply your changes.

@Yenya
Copy link
Contributor

Yenya commented Apr 26, 2021

@jaypif - in newer OpenNebula releases (about 5.4+ or so) the context can be updated any time, even when the VM is running. Destroy and recreate is no longer needed. That said, the context is provided in form of an IDE CD, which does not support hotplug in Linux. So the guest cannot be notifed about the context change. But as soon as it mounts the context CD (or reboots inside the same qemu process - no undeploy/deploy is needed), the new context becomes visible. So it would be nice to have the context changes from terraform resource propagated into the ONe state.

My use case is especially the SSH_PUBLIC_KEY context variable: I want to have it configured beforehand, so that I can configure the VM with Ansible as soon as it is created by Terraform, but I cannot overwrite /root/.ssh/authorized_keys in Ansible, because the modification would get destroyed by the contextualization scripts after the reboot (or undeploy/deploy cycle). So when I want to modify the SSH authorized keys for the existing VMs, I have to do it on the ONe context level, which - for VMs created by terraform means doing it on terraform level.

@Th0masL
Copy link
Contributor

Th0masL commented Jul 27, 2021

Hello,

I can confirm that the Context Update on running VMs now works from the OpenNebula UI, but this does not works from Terraform.

Sadly I don't code in Go so I doubt I will be able to implement a fix for this problem.

@MEGrimshaw
Copy link

@jaypif Is there any guidance on the turn around time around this issue?
Thanks!

@jaypif
Copy link
Collaborator

jaypif commented Jul 27, 2021

I cannot commit on an ETA as the maintenance of the provider is performed when we have some bandwidth to do it.

I hope it will be possible to have some time to take a deep view on it in the coming weeks.

I let you know.

Thanks

@MEGrimshaw
Copy link

Thanks for the update @jaypif

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants