Cool that you went the extra mile with the manual test. :) Once fixed, I will also write a test to cover the scenario you described in the issue. It will make it future proof.
Thanks again, Bharat! Cheers, Wilder > On 05 Nov 2015, at 10:54, Bharat Kumar <bharat.ku...@citrix.com> wrote: > > Hi, > > Wilder has already reduced the priority to critical, I found it while > manually testing some of my changes. > I am not aware of a test which checks this. > > —Bharat. > > On 05-Nov-2015, at 3:03 pm, Remi Bergsma <rberg...@schubergphilis.com> wrote: > >> Hi Bharat, >> >> First of all: thanks for reporting the issue! >> >> Would it be possible to write a Marvin test for it, so we can test this >> automatically and prevent regression? Or did you find this by an existing >> Marvin test that I missed? >> >> Please downgrade to critical. We should fix this, and we will, but it >> shouldn’t block 4.6.0 IMHO. Talked to Rajani and she agrees. >> >> Regards, >> Remi >> >> >> >> On 05/11/15 10:29, "Bharat Kumar" <bharat.ku...@citrix.com> wrote: >> >>> Hi Wilder, >>> >>> If we think that it is ok to have the work around for now fix this later, >>> we can bring the priority down to critical. >>> >>> Thanks, >>> Bharat. >>> >>> On 05-Nov-2015, at 2:49 pm, Wilder Rodrigues >>> <wrodrig...@schubergphilis.com> wrote: >>> >>>> Hi Bharat, >>>> >>>> Please check if what you just mention will work. If it does, then the >>>> issue is not a blocker. >>>> >>>> Cheers, >>>> Wilder >>>> >>>> >>>>> On 05 Nov 2015, at 10:09, Bharat Kumar <bharat.ku...@citrix.com> wrote: >>>>> >>>>> I have’t checked, but form the code it looks like it will work if we >>>>> reissue the reset command after the slave becomes master. >>>>> >>>>> —Bharat. >>>>> >>>>> On 05-Nov-2015, at 12:59 pm, Erik Weber >>>>> <terbol...@gmail.com<mailto:terbol...@gmail.com>> wrote: >>>>> >>>>> On Thu, Nov 5, 2015 at 7:15 AM, Bharat Kumar >>>>> <bharat.ku...@citrix.com<mailto:bharat.ku...@citrix.com>> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> In my local setup i found this issue, The user VM password is not getting >>>>> saved in the backup router. >>>>> >>>>> we send the save password command to both the VRs in a rvr enabled >>>>> network, But the password gets saved only in the master VR. This happens >>>>> because the password server is not running in the backup. >>>>> Because of this if someone resets the password of a VM and starts it when >>>>> the backup becomes master. Then the password of the user VM will not >>>>> change, because the save password command was not successful. >>>>> >>>>> This breaks the password reset functionality, I have a raised a Blocker >>>>> issue CLOUDSTACK-9035< >>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-9035> to track this. >>>>> >>>>> >>>>> >>>>> Does it work if you re-issue the password reset call after the slave vr >>>>> has >>>>> been promoted to master? >>>>> If it does, then atleast you have a workaround for the issue. >>>>> >>>>> -- >>>>> Erik >>>>> >>>> >>> >
