Subscribe

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

[ Edited ]

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

 

 

Re: new-sfvol ignoring -sfconnection parameter

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

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: new-sfvol ignoring -sfconnection parameter

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

Re: new-sfvol ignoring -sfconnection parameter

Perfect - thanks all!

 

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


Jonathan

Re: new-sfvol ignoring -sfconnection parameter

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.

 

 

Re: new-sfvol ignoring -sfconnection parameter | FIXED

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 Smiley Happy

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

Re: new-sfvol ignoring -sfconnection parameter | FIXED

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.