I think I understand the confusion here.

Rafael’s code was put into 4.11.1, but not into the initial release candidate 
(RC). In fact, the most recent version of 4.11 that has been released is 
4.11.1. Somehow Rafael’s code (which is an enhancement) was merged into 4.11 
during the RC process. This is why my automated tests did not find it. I ran 
them against 4.11.1 RC1 and his code was put in after the first RC.

It looks like we had a bit of a process issue during the RC process as only bug 
fixes should be going into the next RC.

In any event, this means the documentation (at least in this regard) should be 
fine for 4.11.1. Also, no 4.11.2 (or 4.11.3) has been publicly released. We 
seem to have been getting those confused with RCs in our e-mail chain here.

On 7/16/18, 1: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
                    
                
                
            
            
        
        
    
    

Reply via email to