Unexpected result of Get-SFInitiator | Add-SFInitiatorToVolumeAccessGroup (1.5.1.1)

[scaleoutsean]

PS /home/sean/ > Get-SFInitiator                                                                                     

Alias              : sn1
InitiatorID        : 11
InitiatorName      : iqn.1994-05.com.redhat:1b14a7b3928
VolumeAccessGroups : {}
Attributes         : {}

Alias              : sn2
InitiatorID        : 12
InitiatorName      : iqn.1994-05.com.redhat:2b14a7b3928
VolumeAccessGroups : {}
Attributes         : {}

PS /home/sean/> Get-SFInitiator | Add-SFInitiatorToVolumeAccessGroup -VolumeAccessGroupID 1                         

This doesn't do what I thought it does.

PS /home/sean/> Get-SFInitiator                                                                                     

Alias              : sn1
InitiatorID        : 11
InitiatorName      : iqn.1994-05.com.redhat:1b14a7b3928
VolumeAccessGroups : {}
Attributes         : {}

Alias              : sn2
InitiatorID        : 12
InitiatorName      : iqn.1994-05.com.redhat:2b14a7b3928
VolumeAccessGroups : {}
Attributes         : {}

Alias              : 
InitiatorID        : 15
InitiatorName      : {"Alias" = "sn1", "InitiatorID" = 11, "InitiatorName" = "iqn.1994-05.com.redhat:1b14a7b3928"}
VolumeAccessGroups : {1}
Attributes         : {}

Alias              : 
InitiatorID        : 16
InitiatorName      : {"Alias" = "sn2", "InitiatorID" = 12, "InitiatorName" = "iqn.1994-05.com.redhat:2b14a7b3928"}
VolumeAccessGroups : {1}
Attributes         : {}

I'm wondering whether the second cmdlet shouldn't accept output from the first, since it can't handle it properly.

[ahaid]

Yep. That's a bug. I created SDK-957 to handle it. Hopefully we can fix it in 1.6.

[Salmanius]

This has been fixed in our upcoming 1.6 release.

[arjun960]

Closing the issue as the issue is already fixed and available in SDK 1.7 Release.