SolidFire and HCI

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

 

 

1 ACCEPTED SOLUTION

elementx

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

View solution in original post

6 REPLIES 6

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

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

View solution in original post

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

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

Sergey_O_NetApp

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

Perfect - thanks all!

 

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


Jonathan

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public