new-sfvol ignoring -sfconnection parameter | Fixed in 1.4!

[Jonathan_Wheeler]

Hi All,

I have a really perculiar issue with the commandlet new-sfvolume and its SFconnection parameter. In short, it seems to ignoring that parameter.

As part of a much larger script, I have split out the SF authentication and connection handling into a dedicated function, with other assorted functions doing our SF queries & changes.

When connect-SFcluster is run within a function, the global $SFconnection/s variables are not set, due to variable scoping rules. This is standard/expected behaviour in powershell, so I capture the returned connection handle and return it for reuse by other commandlets/functions:

$SFConn = Connect-SFCluster -Credential $creds -Target $array -WarningAction SilentlyContinue -ErrorAction stop
return $SFConn[0]

Other commandlets work when I pass them the parameter (-sfconnection $sfconn), but new-sfvolume ignores it, and wholly relies on $global:sfconnection & $global:sfconnections.

Below I illustrate that get-sfaccount & get-sfvolume are taking the -sfconnection parameter succesfussly, with my $sfconn connection handle, but new-sfvolume won't (I have xxx'ed out sensitive data)

C:\Users\jw3admin> get-module -name SolidFire

ModuleType Version Name ExportedCommands 
---------- ------- ---- ---------------- 
Manifest 1.3.1.4 SolidFire {Add-SFDrive, Add-SFInitiatorToVolumeAccessGroup, Add-SFNode, Add-SFSnmpNetwork...} 


C:\Users\jw3admin> $sfconn


Target           : xxxx
Name             : xxxx
Port             : 
VersionApiName   : Fluorine
VersionApiNumber : 9
Node             : False
Uri              : https://xxxx/json-rpc/9.0
RequestCount     : 13
Credential       : System.Management.Automation.PSCredential
Limits           : {"AccountCountMax" = 5000, "AccountNameLengthMax" = 64, "AccountNameLengthMin" = 1, "BulkVolumeJobsPerNodeMax" = 8, "BulkVolumeJobsPerVolumeMax" = 2, "CloneJobsPerVolumeMax" = 2, "ClusterPairsCountMax" = 4, "InitiatorNameLengthMax" = 224, "InitiatorCountMax" = 
                   10000, "InitiatorsPerVolumeAccessGroupCountMax" = 64, "IscsiSessionsFromFibreChannelNodesMax" = 4096, "SecretLengthMax" = 16, "SecretLengthMin" = 12, "SnapshotNameLengthMax" = 64, "SnapshotsPerVolumeMax" = 32, "VolumeAccessGroupCountMax" = 1000, 
                   "VolumeAccessGroupLunMax" = 16383, "VolumeAccessGroupNameLengthMax" = 64, "VolumeAccessGroupNameLengthMin" = 1, "VolumeAccessGroupsPerInitiatorCountMax" = 1, "VolumeAccessGroupsPerVolumeCountMax" = 4, "InitiatorAliasLengthMax" = 224, "VolumeBurstIOPSMax" = 200000, 
                   "VolumeBurstIOPSMin" = 100, "VolumeCountMax" = 6000, "VolumeMaxIOPSMax" = 200000, "VolumeMaxIOPSMin" = 100, "VolumeMinIOPSMax" = 15000, "VolumeMinIOPSMin" = 50, "VolumeNameLengthMax" = 64, "VolumeNameLengthMin" = 1, "VolumeSizeMax" = 8000000491520, "VolumeSizeMin" 
                   = 1000000000, "VolumesPerAccountCountMax" = 2000, "VolumesPerGroupSnapshotMax" = 32, "VolumesPerVolumeAccessGroupCountMax" = 2000}
Timeout          : 
Element          : SolidFire.Element.Api.SolidFireElement


 C:\Users\jw3admin> Get-SFAccount
Get-SFAccount : There are no active connections. Call Connect-SFCluster before attempting any other commands.
At line:1 char:1
+ Get-SFAccount
+ ~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-SFAccount], ConnectionException
    + FullyQualifiedErrorId : SolidFire.Core.Exceptions.ConnectionException,SolidFire.Account.Get.GetSFAccount
 
(Fails as expected - there is no default / $global:sfconnection handle, but if I provide one, it works.)

 C:\Users\jw3admin> Get-SFAccount -SFConnection $SFConn

AccountID       : 2
Username        : xxxxxx
Status          : active
Volumes         : {2, 7, 8, 17}
InitiatorSecret : xxxxxxxx
TargetSecret    : xxxxxxx
Attributes      : {}

AccountID       : 3
Username        : xxxxxx
Status          : active
Volumes         : {5, 6, 9, 10...}
InitiatorSecret : xxxxxx
TargetSecret    : xxxxx
Attributes      : {}


(Works...)
(I'll keep that account variable, and call NEW-sfvolume using the same sfconniction handle. It fails:)

 C:\Users\jw3admin> $account = Get-SFAccount -SFConnection $SFConn



 C:\Users\jw3admin> New-SFVolume -Name 'test2' -Account $account[0] -TotalSize 8000 -GB -MinIOPS 1000 -MaxIOPS 2000 -BurstIOPS 3000 -Enable512e $true -SFConnection $SFConn
New-SFVolume : There are no active connections. Call Connect-SFCluster before attempting any other commands.
At line:1 char:1
+ New-SFVolume -Name 'test2' -Account $account[0] -TotalSize 8000 -GB -MinIOPS 100 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-SFVolume], ConnectionException
    + FullyQualifiedErrorId : SolidFire.Core.Exceptions.ConnectionException,SolidFire.Volume.New.NewSFVolume
 
(But GET-sfvolume works just fine...It's just new-sfvolume exibiting this behaviour)

 C:\Users\jw3admin> Get-SFVolume -SFConnection $SFConn


VolumeID           : 2
Name               : xxxx-02
AccountID          : 2
CreateTime         : 2017-02-03T01:47:43Z
Status             : active
Access             : readWrite
Enable512e         : True
Iqn                : iqn.2010-01.com.solidfire:bfxa.xxxx-01.2
ScsiEUIDeviceID    : 6266786100000002f47acc0100000000
ScsiNAADeviceID    : 6f47acc1000000006266786100000002
Qos                : {"MinIOPS" = 15000, "MaxIOPS" = 50000, "BurstIOPS" = 100000, "BurstTime" = 60}
VolumeAccessGroups : {1}
VolumePairs        : {}
DeleteTime         : 
PurgeTime          : 
SliceCount         : 1
TotalSize          : 8000000491520
BlockSize          : 4096
VirtualVolumeID    : 
Attributes         : {}

<snip - many more volumes follow>

I can successfully create volumes if I run connect-sfcluster in the global context, which it turn creates the two system variables $sfconnection & $sfconnections which new-sfvolume appears to require.

This looks to be a bug within new-sfvolume. Could a developer please check this out?

Using the global context and relying on default connection handles are both poor practices so I would really like te get this working properly within functions, so I can better scale our SF automation.

Thanks!

Jonathan

[mbeattie]

Hi Johnathan,

Thanks for raising the issue, i'd agree this looks like a bug. I've reached out to the solidfire team to look into it for you.

/Matt

[Sergey_O_NetApp]

This appears to be a bug which will be resolved in v1.4 due out in June. 

[Jonathan_Wheeler]

Perfect - thanks all!

I'll edit my post to report 'fixed' after the new version is released and I have confirmed the fix.

Jonathan

[elementx]

This works fine for me with  v1.4.0.30 (before I executed the connection and account command following your example).

New-SFVolume -Name 'test2' -Account $account[0] -TotalSize 8000 -GB -MinIOPS 1000 -MaxIOPS 2000 -BurstIOPS 3000 -Enable512e $true -SFConnection $SFConn[0]

But, I used $SFConn[0], not $SFConn like you. $SFConn still doesn't work for me.

On the one hand this works (with [0], using v1.4), but on the other it still doesn't seem to work right so I opened issue for v1.4.0.30.

[Jonathan_Wheeler]

Yep, I agree. The 1.4.0.98 toolkit has fixed this bug - thank you to those that made this happen. Did you say you're on 1.4.0.20? Was that a pre-release build?

Under 1.3 at least, connect-sfCluster commandlet actually returned an array, not just the single object you expect.

The first member was the expected connection handle object, the second was a way cool ASCII drawing, and I think the third was a message confirming connection. Perhaps your 1.4 is still the same - my connection wrapper was taking the first member and dropping the rest, returning the $sfconn I expected 🙂

1.4.0.98's connect-sfcluster seems to just return the connection handle now, which is good - that's what most people would expect I imagine.

Thanks,

Jonathan

[elementx · Accepted solution]

Yes I had a pre-release (RC or beta, I can't remember now) build. (I now installed the official GA release, thanks for reminder).

I still find it confusing that return $SFConn[0] and return $SFConn give identical output, so I created a new issue at https://github.com/solidfire/PowerShell/issues/24. We'll see what they say when they return to office after July 4.

Edit (Aug 17, 2017): it's a bug and will be fixed in next release