[GitHub] [cloudstack-primate] blueorangutan commented on pull request #343: Allow configuring IPv6 default guest network when deploying a new Zone
blueorangutan commented on pull request #343: URL: https://github.com/apache/cloudstack-primate/pull/343#issuecomment-631891797 Packaging result: :heavy_check_mark:centos :heavy_check_mark:debian :heavy_check_mark:archive. JID-1933 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] blueorangutan commented on pull request #343: Allow configuring IPv6 default guest network when deploying a new Zone
blueorangutan commented on pull request #343: URL: https://github.com/apache/cloudstack-primate/pull/343#issuecomment-631889772 @rhtyd a Jenkins job has been kicked to build primate packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on pull request #343: Allow configuring IPv6 default guest network when deploying a new Zone
rhtyd commented on pull request #343: URL: https://github.com/apache/cloudstack-primate/pull/343#issuecomment-631889603 Hi @GabrielBrascher - have you tested this by deploying a zone, does it pass/fail? Thanks. @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on issue #62: Custom Upload Action - Template, ISO, volume
rhtyd commented on issue #62: URL: https://github.com/apache/cloudstack-primate/issues/62#issuecomment-631831526 Read the docs @Android1968 http://docs.cloudstack.apache.org/en/latest/adminguide/systemvm.html#using-a-ssl-certificate-for-the-console-proxy This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] Android1968 commented on issue #62: Custom Upload Action - Template, ISO, volume
Android1968 commented on issue #62: URL: https://github.com/apache/cloudstack-primate/issues/62#issuecomment-631827422 > @Android1968 this feature requires SSL/TLS certificates to be setup in the env for SSVM. The screen shots are from legacy UI, if SSVM is SSL enabled it should work with Primate. Thanks fo the info @rhtyd,do you have any link on how to do this in 4.13 release of Cloudstack?i find it hard because the resources are so limited for this version,thanks again mate! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
@gregor - the legacy should be fine with UEFI (what I had run on some of my laptops); UEFI is not a problem, happens with 4.13 also, any VirtualBox OVA file will cause the issue ### To conclude the ISSUE, based on my few hour testing today: - happens when you deliberately use VirtualBox OVA template with vSphere (who and why would do that, is another topic..), in ACS 4.13.x and 4.14/master ...out of which...: - does NOT happen with vCenter 6.0 and 6.5 (confirmed by Daan/Bobby), proper OVF parsing takes place and an error message is generated in ACS logs - NOT tested: 6.7 / 6.7 U1xxx / 6.7 U2xxx (i.e. not tested with any variant < 6.7 U3) - issues happen with vCenter 6.7 U3 / U3a / U3b / U3f - these were explicitly tested by me and some vCenter services would crash (though still appearing as running) - the problem is solved by restarting (most?) services - namely "VMware afd Service" will trigger other services to restart (dependency) and after a while vCenter is UP again (I could not find which exact service (single one) might be the issue) - Worth mentioning this was observed on vCenter on Windows Server, not the VCSA appliance - seems FINE - NO ISSUES with vCenter 6.7 U3g (the latest 6.7 U3 variants at the moment - build 16046470 from 28.04.2020) and the VM deployment fails gracefully with a proper error message of not being able to create SPEC file based on the (bad) OVF. Since the issue is solved in the (current) latest vSphere 6.7 U3g variant, I will make sure to have the proper warning message on both 4.13.1 and 4.14.0.0 Release notes documentation (4.13 is when we started supporting vSphere 6.7 and the same issue present here) I'll proceed tomorrow with releasing 4.14 based on the voting done so far. Thanks On Wed, 20 May 2020 at 22:09, Marcus wrote: > I would say, if it is proven that this happens with existing released > CloudStack versions, with or without the UEFI feature, against a specific > VMware release with a specific broken template, then it becomes an > environment issue and shouldn't block the release. In this case it would > not matter if we tried to revert the feature, or if we did or did not > release 4.14, the users who would hit this would be hitting this now in > live environments, with the released versions of CloudStack. > > To be clear, I'm not 100% certain this is exactly what Bobby was saying, > but if this is the case then I think it should not block us. > > On Wed, May 20, 2020 at 1:00 AM Riepl, Gregor (SWISS TXT) < > gregor.ri...@swisstxt.ch> wrote: > > > Hi everyone > > > > Sorry for the late response, but I have a few concerns: > > > > > > * As Bobby stated, this bug seems to only occur with VMware 6.7+, and > > it sounds to me like they should take action on it. Does someone track > this > > with VMware? > > * Do I understand correctly that the issue only occurs when the image > > is set to UEFI mode, but the VM is configured as Legacy Boot in > CloudStack? > > How would this combination even work? I think CloudStack should either > > reject such a mismatch or autocorrect it. Or at least display a warning > to > > the user. > > * If the bug can break vCenter (if only temporarily), there should > > definitely some sort of safeguard around it, even if it isn't a proper > fix > > or workaround. > > > > Regards, > > Gregor > > > > From: Andrija Panic > > Sent: 19 May 2020 21:11 > > To: users > > Cc: dev@cloudstack.apache.org > > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 > > > > Hi all, > > > > In my humble opinion, we should release 4.14 as it is (considering we > have > > enough votes), but we'll further investigate the actual/behind-the-scene > > root-cause for the vSphere 6.7 harakiri (considering 6.0 and 6.5 are not > > affected) - this is possibly a VMware bug and we'll certainly try to > > address it. > > > > If I don't hear any more concerns or -1 votes until tomorrow morning CET > > time, I will proceed with concluding the voting process and crafting the > > release. > > > > Thanks, > > Andrija > > > > On Tue, 19 May 2020 at 19:23, Pavan Kumar Aravapalli < > > pavankuma...@accelerite.com> wrote: > > > > > Thank you Bobby and Daan for the update. However I have not encountered > > > such issue while doing dev test with Vmware 5.5 & 6.5. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Pavan Aravapalli. > > > > > > > > > > > > From: Daan Hoogland > > > Sent: 19 May 2020 20:56 > > > To: users > > > Cc: dev@cloudstack.apache.org > > > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 > > > > > > Thanks Bobby, > > > All, I've been closely working with Bobby and seen the same things. > Does > > > anybody see any issues releasing 4.14 based on this code? I can confirm > > > that it is not Pavernalli's UEFI PR and we should not create a new PR > to > > > revert it.
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
I would say, if it is proven that this happens with existing released CloudStack versions, with or without the UEFI feature, against a specific VMware release with a specific broken template, then it becomes an environment issue and shouldn't block the release. In this case it would not matter if we tried to revert the feature, or if we did or did not release 4.14, the users who would hit this would be hitting this now in live environments, with the released versions of CloudStack. To be clear, I'm not 100% certain this is exactly what Bobby was saying, but if this is the case then I think it should not block us. On Wed, May 20, 2020 at 1:00 AM Riepl, Gregor (SWISS TXT) < gregor.ri...@swisstxt.ch> wrote: > Hi everyone > > Sorry for the late response, but I have a few concerns: > > > * As Bobby stated, this bug seems to only occur with VMware 6.7+, and > it sounds to me like they should take action on it. Does someone track this > with VMware? > * Do I understand correctly that the issue only occurs when the image > is set to UEFI mode, but the VM is configured as Legacy Boot in CloudStack? > How would this combination even work? I think CloudStack should either > reject such a mismatch or autocorrect it. Or at least display a warning to > the user. > * If the bug can break vCenter (if only temporarily), there should > definitely some sort of safeguard around it, even if it isn't a proper fix > or workaround. > > Regards, > Gregor > > From: Andrija Panic > Sent: 19 May 2020 21:11 > To: users > Cc: dev@cloudstack.apache.org > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 > > Hi all, > > In my humble opinion, we should release 4.14 as it is (considering we have > enough votes), but we'll further investigate the actual/behind-the-scene > root-cause for the vSphere 6.7 harakiri (considering 6.0 and 6.5 are not > affected) - this is possibly a VMware bug and we'll certainly try to > address it. > > If I don't hear any more concerns or -1 votes until tomorrow morning CET > time, I will proceed with concluding the voting process and crafting the > release. > > Thanks, > Andrija > > On Tue, 19 May 2020 at 19:23, Pavan Kumar Aravapalli < > pavankuma...@accelerite.com> wrote: > > > Thank you Bobby and Daan for the update. However I have not encountered > > such issue while doing dev test with Vmware 5.5 & 6.5. > > > > > > > > > > > > Regards, > > > > Pavan Aravapalli. > > > > > > > > From: Daan Hoogland > > Sent: 19 May 2020 20:56 > > To: users > > Cc: dev@cloudstack.apache.org > > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 > > > > Thanks Bobby, > > All, I've been closely working with Bobby and seen the same things. Does > > anybody see any issues releasing 4.14 based on this code? I can confirm > > that it is not Pavernalli's UEFI PR and we should not create a new PR to > > revert it. > > thanks for all of your patience, > > > > (this is me giving a binding +1) > > > > > > On Tue, May 19, 2020 at 5:04 PM Boris Stoyanov < > > boris.stoya...@shapeblue.com> > > wrote: > > > > > Hi guys, > > > > > > I've done more testing around this and I can now confirm it has nothing > > to > > > do with cloudstack code. > > > > > > I've tested it with rc3, reverted UEFI PR and 4.13.1 (which does not > > > happen to have the feature at all). Also I've used a matrix of VMware > > > version of 6.0u2, 6.5u2 and 6.7u3. > > > > > > The bug is reproducible with all the cloudstack versions, and only > vmware > > > 6.7u3, I was not able to reproduce this with 6.5/6.0. All of my results > > > during testing show it must be related to that specific version of > > VMware. > > > > > > Therefore I'm reversing my '-1' and giving a +1 vote on the RC. I think > > it > > > needs to be included in release notes to refrain from that version for > > now > > > until further investigation is done. > > > > > > Thanks, > > > Bobby. > > > > > > On 19.05.20, 10:08, "Boris Stoyanov" > > > wrote: > > > > > > Indeed it is severe, but please note it's a corner case which was > > > unearthed almost by accident. It falls down to using a new feature of > > > selecting a boot protocol and the template must be corrupted. So with > > > already existing templates I would not expect to encounter it. > > > > > > As for recovery, we've managed to recover vCenter and Cloudstack > > after > > > reboots of the vCenter machine and the Cloudstack management service. > > > There's no exact points to recover for now, but restart seems to work. > > > By graceful failure I mean, cloudstack erroring out the deployment > > and > > > VM finished in ERROR state, meanwhile connection and operability with > > > vCenter cluster remains the same. > > > > > > We're currently exploring options to fix this, one could be to > > disable > > > the feature for VMWare and work to introduce more sustainable fix in > next > > > release. Other is to look for more guarding code when
[GitHub] [cloudstack-primate] vladimirpetrov opened a new issue #351: [BUG] Read-only admin: add/delete roles is allowed
vladimirpetrov opened a new issue #351: URL: https://github.com/apache/cloudstack-primate/issues/351 **Describe the bug** Even when logged in as read-only admin (with allowed only list* actions in the role), you're still able to add/delete roles. **To Reproduce** Steps to reproduce the behavior: 1. Login as read-only admin user (admin role with only list* actions allowed). 2. Go to Roles. Now you can create and delete roles even though you shouldn't be allowed. **Expected behavior** Read-only admin should not be allowed to add and delete roles. **Screenshots** None. **Desktop (please complete the following information):** - OS: Ubuntu 18.04 LTS - Browser: Chrome - Version: 83.0.4103.61 (Official Build) (64-bit) **Additional context** We have the same behavior in the old UI. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov opened a new issue #350: [BUG] Read-only admin: domain operations are allowed
vladimirpetrov opened a new issue #350: URL: https://github.com/apache/cloudstack-primate/issues/350 **Describe the bug** Even when logged in as read-only admin (with allowed only list* actions in the role), you're still able to **To Reproduce** Steps to reproduce the behavior: 1. Login as read-only admin user (admin role with only list* actions allowed). 2. Go to Domains. Now you can create and delete domains even though you shouldn't be allowed. The domain is removed from the list and there is a neverending 'in progress' circle in the notification box. **Expected behavior** Read-only admin should not be allowed to add and delete domains. **Screenshots**   **Desktop (please complete the following information):** - OS: Ubuntu 18.04 LTS - Browser: Chrome - Version: 83.0.4103.61 (Official Build) (64-bit) **Additional context** We have the same behavior in the old UI. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov closed issue #346: [BUG] Read-only admin: destroy volume icon is active
vladimirpetrov closed issue #346: URL: https://github.com/apache/cloudstack-primate/issues/346 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov commented on issue #346: [BUG] Read-only admin: destroy volume icon is active
vladimirpetrov commented on issue #346: URL: https://github.com/apache/cloudstack-primate/issues/346#issuecomment-631381229 I created an aggregated issue - #347 so I'm closing this one. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov opened a new issue #349: [BUG] Read-only admin: delete Kubernetes ISO icon is still working
vladimirpetrov opened a new issue #349: URL: https://github.com/apache/cloudstack-primate/issues/349 **Describe the bug** When logged in as read-only admin (with allowed only list* actions in the role), the delete Kubernetes ISO icon is active and working. **To Reproduce** Steps to reproduce the behavior: 1. Login as read-only admin user (admin role with only list* actions allowed). 2. Go to Images > Kubernetes ISOs, then click on a volume and press the 'Destroy' icon. There will be an error message in a pop-up notification but the volume is removed from the list. **Expected behavior** The 'Delete' icon should be hidden and the operation forbidden when the user has no rights for this operation. **Screenshots**  **Desktop (please complete the following information):** - OS: Ubuntu 18.04 LTS - Browser: Chrome - Version: 83.0.4103.61 (Official Build) (64-bit) **Additional context** Similar to #346 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] utchoang commented on pull request #320: Explore Test Automation
utchoang commented on pull request #320: URL: https://github.com/apache/cloudstack-primate/pull/320#issuecomment-63135 @rhtyd cc @svenvogel OK, I got it. I think some further adjustments are needed to complete it. I will notify after completion. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd closed issue #344: [BUG] Add secondary storage form passes zone name and not zoneid
rhtyd closed issue #344: URL: https://github.com/apache/cloudstack-primate/issues/344 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd merged pull request #345: Fix for secondary storage form - zone id
rhtyd merged pull request #345: URL: https://github.com/apache/cloudstack-primate/pull/345 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on issue #344: [BUG] Add secondary storage form passes zone name and not zoneid
rhtyd commented on issue #344: URL: https://github.com/apache/cloudstack-primate/issues/344#issuecomment-631354258 @vladimirpetrov please re-test against master and close. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on pull request #307: [FIX] VM Deployment Wizard Changes
rhtyd commented on pull request #307: URL: https://github.com/apache/cloudstack-primate/pull/307#issuecomment-631353570 Yes it's on my radar @svenvogel This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on pull request #320: Explore Test Automation
rhtyd commented on pull request #320: URL: https://github.com/apache/cloudstack-primate/pull/320#issuecomment-631353360 Let me know if you're going further or when this PR reaches a state to be merged? cc @svenvogel This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on pull request #320: Explore Test Automation
rhtyd commented on pull request #320: URL: https://github.com/apache/cloudstack-primate/pull/320#issuecomment-631352904 Great work @utchoang I think some coverage (80+%) is a good start! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] utchoang commented on pull request #320: Explore Test Automation
utchoang commented on pull request #320: URL: https://github.com/apache/cloudstack-primate/pull/320#issuecomment-631352212 * Views > AutogenView.vue - processing 91%  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov opened a new issue #348: [BUG] Wrong tooltips on 'Kubernetes ISOs > selected ISO' screen
vladimirpetrov opened a new issue #348: URL: https://github.com/apache/cloudstack-primate/issues/348 **Describe the bug** Both tooltips on Kubernetes ISOs > selected ISO are wrong. **To Reproduce** Steps to reproduce the behavior: 1. Go to 'Images > Kubernetes ISOs', then click on ISO and look at the action buttons' tooltips - both are 'Update Kubernetes Version', which is incorrect. **Expected behavior** Button should have proper tooltips, something like 'Edit' and 'Delete'. **Screenshots**   **Desktop (please complete the following information):** - OS: Ubuntu 18.04 LTS - Browser: Chrome - Version: 83.0.4103.61 (Official Build) (64-bit) **Additional context** None. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] svenvogel commented on pull request #307: [FIX] VM Deployment Wizard Changes
svenvogel commented on pull request #307: URL: https://github.com/apache/cloudstack-primate/pull/307#issuecomment-631324277 @rhtyd could you find some time to check this? :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on issue #62: Custom Upload Action - Template, ISO, volume
rhtyd commented on issue #62: URL: https://github.com/apache/cloudstack-primate/issues/62#issuecomment-631310762 @Android1968 this feature requires SSL/TLS certificates to be setup in the env for SSVM. The screen shots are from legacy UI, if SSVM is SSL enabled it should work with Primate. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] vladimirpetrov opened a new issue #347: [BUG] Read-only admin: Kubernetes ISOs can be enabled/disabled
vladimirpetrov opened a new issue #347: URL: https://github.com/apache/cloudstack-primate/issues/347 **Describe the bug** Even when logged in as read-only admin (with allowed only list* actions in the role), you're stil able to enable/disable a Kubernetes ISO. **To Reproduce** Steps to reproduce the behavior: 1. Login as read-only admin user (admin role with only list* actions allowed). 2. Go to Images > Kubernetes ISOs and click on some ISO. Click the 'Update' icon and change the enable/disable state. **Expected behavior** Read-only admin should not be allowed to change the ISO state. **Screenshots** None. **Desktop (please complete the following information):** - OS: Ubuntu 18.04 LTS - Browser: Chrome - Version: 83.0.4103.61 (Official Build) (64-bit) **Additional context** None. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] svenvogel commented on issue #62: Custom Upload Action - Template, ISO, volume
svenvogel commented on issue #62: URL: https://github.com/apache/cloudstack-primate/issues/62#issuecomment-63125 @rhtyd what do you think about this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
Hi everyone Sorry for the late response, but I have a few concerns: * As Bobby stated, this bug seems to only occur with VMware 6.7+, and it sounds to me like they should take action on it. Does someone track this with VMware? * Do I understand correctly that the issue only occurs when the image is set to UEFI mode, but the VM is configured as Legacy Boot in CloudStack? How would this combination even work? I think CloudStack should either reject such a mismatch or autocorrect it. Or at least display a warning to the user. * If the bug can break vCenter (if only temporarily), there should definitely some sort of safeguard around it, even if it isn't a proper fix or workaround. Regards, Gregor From: Andrija Panic Sent: 19 May 2020 21:11 To: users Cc: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 Hi all, In my humble opinion, we should release 4.14 as it is (considering we have enough votes), but we'll further investigate the actual/behind-the-scene root-cause for the vSphere 6.7 harakiri (considering 6.0 and 6.5 are not affected) - this is possibly a VMware bug and we'll certainly try to address it. If I don't hear any more concerns or -1 votes until tomorrow morning CET time, I will proceed with concluding the voting process and crafting the release. Thanks, Andrija On Tue, 19 May 2020 at 19:23, Pavan Kumar Aravapalli < pavankuma...@accelerite.com> wrote: > Thank you Bobby and Daan for the update. However I have not encountered > such issue while doing dev test with Vmware 5.5 & 6.5. > > > > > > Regards, > > Pavan Aravapalli. > > > > From: Daan Hoogland > Sent: 19 May 2020 20:56 > To: users > Cc: dev@cloudstack.apache.org > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3 > > Thanks Bobby, > All, I've been closely working with Bobby and seen the same things. Does > anybody see any issues releasing 4.14 based on this code? I can confirm > that it is not Pavernalli's UEFI PR and we should not create a new PR to > revert it. > thanks for all of your patience, > > (this is me giving a binding +1) > > > On Tue, May 19, 2020 at 5:04 PM Boris Stoyanov < > boris.stoya...@shapeblue.com> > wrote: > > > Hi guys, > > > > I've done more testing around this and I can now confirm it has nothing > to > > do with cloudstack code. > > > > I've tested it with rc3, reverted UEFI PR and 4.13.1 (which does not > > happen to have the feature at all). Also I've used a matrix of VMware > > version of 6.0u2, 6.5u2 and 6.7u3. > > > > The bug is reproducible with all the cloudstack versions, and only vmware > > 6.7u3, I was not able to reproduce this with 6.5/6.0. All of my results > > during testing show it must be related to that specific version of > VMware. > > > > Therefore I'm reversing my '-1' and giving a +1 vote on the RC. I think > it > > needs to be included in release notes to refrain from that version for > now > > until further investigation is done. > > > > Thanks, > > Bobby. > > > > On 19.05.20, 10:08, "Boris Stoyanov" > > wrote: > > > > Indeed it is severe, but please note it's a corner case which was > > unearthed almost by accident. It falls down to using a new feature of > > selecting a boot protocol and the template must be corrupted. So with > > already existing templates I would not expect to encounter it. > > > > As for recovery, we've managed to recover vCenter and Cloudstack > after > > reboots of the vCenter machine and the Cloudstack management service. > > There's no exact points to recover for now, but restart seems to work. > > By graceful failure I mean, cloudstack erroring out the deployment > and > > VM finished in ERROR state, meanwhile connection and operability with > > vCenter cluster remains the same. > > > > We're currently exploring options to fix this, one could be to > disable > > the feature for VMWare and work to introduce more sustainable fix in next > > release. Other is to look for more guarding code when installing a > > template, since VMware doesn’t actually allow you install that particular > > template but cloudstack does. We'll keep you posted. > > > > Thanks, > > Bobby. > > > > On 18.05.20, 23:01, "Marcus" wrote: > > > > The issue sounds severe enough that a release note probably won't > > suffice - > > unless there's a documented way to recover we'd never want to > > leave a > > system susceptible to being unrecoverable, even if it's rarely > > triggered. > > > > What's involved in "failing gracefully"? Is this a small fix, or > an > > overhaul? Perhaps the new feature could be disabled for VMware, > or > > disabled altogether until a fix is made in a patch release. > > > > Does it only affect new templates, or is there a risk that an > > existing > > template out in vSphere could suddenly cause problems? > > > > On Mon, May 18, 2020 at 12:49
