Probably a lack of attention of the people writing the release note. It happens in manual processes.
On Mon, Jul 16, 2018 at 4:46 PM, Yiping Zhang <yzh...@marketo.com> wrote: > Why is it listed as fixed in 4.11.1.0 in the release note, If the code > only exist in 4.11.2? > > > > On 7/16/18, 12:43 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> > wrote: > > OK, as Rafael noted, looks like it’s in 4.11.2. My regression tests > were run against 4.11.1. I thought we only allowed bug fixes when going to > a new RC, but it appears we are not strictly enforcing that rule. > > On 7/16/18, 1:40 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> > wrote: > > When I ran my suite of tests on 4.11.1, I did not encounter this > issue. Also, looking at the code now, it appears this new code is first in > 4.12. > > On 7/16/18, 1:36 PM, "Yiping Zhang" <yzh...@marketo.com> wrote: > > > Is this code already in ACS 4.11.1.0? > > CLOUDSTACK-10240 is listed as fixed in 4.11.1.0, according to > release note here, http://docs.cloudstack.apache.org/projects/cloudstack- > release-notes/ja/master/fixed_issues.html, but in the JIRA ticket itself, > the "fixed version/s" field says 4.12. > > We are using XenServer clusters with shared NFS storages and I > am about to migrate to ACS 4.11.1.0 from 4.9.3.0. Since we move VM between > clusters a lot, this is going to be a blocker for us. Someone please > confirm. > > Thanks > > Yiping > > > On 7/14/18, 11:20 PM, "Tutkowski, Mike" < > mike.tutkow...@netapp.com> wrote: > > Hi, > > While running managed-storage regression tests tonight, I > noticed a problem that is not related to managed storage. > > CLOUDSTACK-10240 is a ticket asking that we allow the > migration of a virtual disk that’s on local storage to shared storage. In > the process of enabling this feature, the VirtualMachineManagerImpl. > getPoolListForVolumesForMigration method was re-written in a way that > completely breaks at least one use case: Migrating a VM across compute > clusters (at least supported in XenServer). If, say, a virtual disk resides > on shared storage in the source compute cluster, we must be able to copy > this virtual disk to shared storage in the destination compute cluster. > > As the code is currently written, this is no longer > possible. It also seems that the managed-storage logic has been dropped for > some reason in the new implementation. > > Rafael – It seems that you worked on this feature. Would > you be able to look into this and create a PR? > > Thanks, > Mike > > > > > > > > > -- Rafael Weingärtner
