DateTime, TimeSpan, and Size type inconsistency

[glenn_sizemore]

Whenever you return a size in the toolkit it should be in bytes. The reason for this is simple PowerShell includes some special constants to assist in calculating space.

I should be able to do the following...

$snap = Get-NaSnapshot -Name vol1 -SnapName nightly.0

$snap.Total/1gb

Unfortunately I cannot because the Get-NaSnapshot cmdlet returns Kb (Mind you it doesn't say this Anywhere). This forces me to do the following...

$snap = Get-NaSnapshot -Name vol1 -SnapName nightly.0

($snap.Total * 1kb)/1gb

Rinse and repeat for every single size returned by any cmdlet, and you quickly understand why this matters.

Alas the same can be said for DateTime, and TimeSpan. Nowhere, should I ever run across the epoch timestamp. It is meaningless in a PowerShell prompt... You should be returning either Datetime or TimeStamp objects depending on the instance.

Case in point, Get-NaTime... I understand the OnTAPI returns the epoc timestamps and some 'strings', but all we NEED is a date time object. PowerShell's Type formating engine will render the "strings" for you once you feed it a proper object. The output of this cmdlet should be two DateTime objects UTC, and Local.

Another example would be the AccessTime property on the SnapshotInfo object. Why are you forcing us to perform this conversion? This should be done before you return the object. ZAPI only supports three native types. This limitation causes some some strange output, but PowerShell has the whole .net library behind it. The more you return native object the easier it is for us to use you're data as is, and the more PowerShell will assist Both of us in digesting the data returned.

A final quick example would be the LagTime Property on the SnapmirrorStatusInfo, again should be a timespan object. The reason is simple PowerShell will give us both some really powerful metrics if you perform the conversion before returning

the object.  By forcing me to convert the integer into a meaningfull object you're needlessly increasing the complexity of the toolkit.

1.0.1 is a Solid build, and I hear 1.1 is even better, but I would urge you to make these transitions asap. Before you run into any legacy support issues... As NTAP customers become more familiar with PowerShell and the toolkit I asure you this will come up again.

~Glenn

[cknight]

Hi, Glenn.  Thanks for this feedback, as well as for your contributions with PoshOnTap.  You are, of course, correct on these points.  Fixing them will require maturing Ontapi beyond what it is today, an autogenerated passthrough layer that speeds cmdlet generation tremendously.  But we're committed to making the Toolkit as good as it can be, so I think we'll get there.

[glenn_sizemore]

If I understood that correctly, you are currently using some kind of meta language to auto generate the toolkit.  This presents a problem b/c the OnTAPI is NOT consistent(and I know just how inconsistent that joker is).

I truly hope we don't have to wait for the API to be corrected to implement simple modifications.  With SnapDrive, SMVI, SystemManager, etc, etc... I fear fixing the API may be a bridge to far.  In the meantime I guess I'll just extend the base objects to include what I need.

Thank you for the information,

~Glenn

[cknight]

glenn.sizemore wrote:
If I understood that correctly, you are currently using some kind of meta language to auto generate the toolkit.  This presents a problem b/c the OnTAPI is NOT consistent(and I know just how inconsistent that joker is).

No.  The Toolkit is coded the old-fashioned way.  ONTAPI is a layer above the ONTAP API that handles the XML parsing; it is built as part of the Toolkit and is subject to manual adjustment, so I can address these things without changes to ONTAP.  We considered autogenerating the entire Toolkit, but as you know all too well, that would not have provided a quality PowerShell experience.

[fjohn]

Hi Glenn,

Thank you for your feedback.  Finding inconsistencies and reporting them is, as you can guess, of the upmost importance.   Thank you for all your help and encouragement.

J