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
Salt-Cloud fails to create VMware Snapshot from orchestrator on second run. #50323
Comments
was this previously working on an older version? also ping @saltstack/team-cloud any ideas here? |
@Ch3LL I'm not sure I just implemented this on 2018.3.3. |
I'm having the same issue on second run of a salt-cloud vm creation. That is, if the second run is long enough for the VMware session to time out. Forgive me for poor formatting but system, salt-master info, and traceback below: Salt Version: Dependency Versions: System Versions: Exception occurred in runner cloud.create: Traceback (most recent call last):
NAME="CentOS Linux" CENTOS_MANTISBT_PROJECT="CentOS-8" |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
not stale |
Thank you for updating this issue. It is no longer marked as stale. |
as you point out with this error: |
I am still experiencing the same "The session is not authenticated" error when using salt.utils.vmware.get_service_instance to create instance object in custom proxy module. I am running v3002.2, but i tried to upgrade utils module to master branch, but problem is persistent. Proxy minion is returning data for several minutes/hours without a hitch and suddenly i get error and only way to fix it is restarting proxy minion. Then it works again, for some time. It's weird that software acquired by VMware doesn't provide tools to manage Vsphere/ESX properly. Salt Extension module for SaltStack is nice but its still in developement. Even when finished, the rest api is very limited in comparison to soap api, for example managing snapshots is not existent. |
Description of Issue/Question
I have an orchestration job that creates a VMware snapshot when called by a reactor. In many instances multiple events come in firing off multiple orchestration jobs to create VMware snapshots. The first time a flood of events come in the VMware snapshots are created without issues, but anytime a flood of events comes in after that snapshots fail to be created. The strange thing is if I call
salt-cloud
directly I can create the snapshots without issues, even when the orchestration job fails to create them. I can correct this by restarting thesalt-master
, after which I can create snapshots for the first flood of events, but sub-sequential events fail.IT looks like salt-cloud fails authentication after the first sent of received events. This is not a VMware permissions issue as the first orchestration jobs that run succeed, and if I restart
salt-master
it works for the first set of events.Setup
_reactor/test.sls
orch/test.sls
test/test.sls
Logs
Are sessions from a previous job not getting cleaned up correctly?
msg = "The object 'vim.view.ContainerView:session[52cc35f2-f7df-209b-fd4f-1574410b47ec]52ac5f07-30d7-6d44-ad51-95f635eb8686' has already been deleted or has not been completely created",
Versions Report
The text was updated successfully, but these errors were encountered: