Element existence - does it apply to shares

[korns]

PROBLEM DESCRIPTION: cDOT 8.2, WFA 2.1GA, OCUM 6.0 => 1) have a workflow that creates a volume, a share and adds ACLs to the share. 2) have other workflows that allow 2A) removing and 2B) adding ACLs to that share. The 2A/2B workflows have a UserInput for the share name which is a select on cm_storage.cifs_share to present a choice of shares to add/remove ACLs to/from. The select returns a stale list of share names. I am trying to figure out just how stale the cifs_share list is (hours?, days).

QUESTIONS:

Q1 - It has been pointed out that the cifs_share listing will only be as current as the most recent OCUM polling interval to get list of shares AND when the last OCUM acquire is done. I find nothing in OCUM 6.0 to control polling intervals for any entities (I also don't even see shares in the OCUM 6.0 GUI). Is there anyplace in OCUM 6.0 to tune polling? Are there any known problems with the cm_storage.cifs_share polling/acquisition?

Q2 - With regard to the WFA Acquistion rate, is there anyway to have a WFA Workflow trigger/force an 'acquire now' against a data source?

Q3 - Do reservations and/or '[x] enable element existence validation' work to keep track of newly/recently created shares? ... is there any hope that a SELECT shareName FROM cm_storage.cifs_share might return shares from OCUM as well as reserved/new-existence shares? ( what I'm asking for is the ability to accurately present the shares on a vserver even if I JUST created the share seconds ago in another workflow)

Dave

[ag]

Hi Dave,

I am trying to get an answer for Q1.

Q2 - With regard to the WFA Acquistion rate, is there anyway to have a WFA Workflow trigger/force an 'acquire now' against a data source?

There is no existing command or way of doing this in WFA. But, before i figure out a way to do it, why is it required. When you force an 'acquire now' before executing a workflow, you have the most recent view of the objects of a filer (assuming ocum has acquired recently as well). Now, in case you create something as part of your workflow, 'reservations' will be set for the newly created objects. So, you do not have to acquire it from OCUM. WFA simulates the effect of having acquired from ocum. You can still have the most recent view of the filer

Q3 - Do reservations and/or '[x] enable element existence validation' work to keep track of newly/recently created shares? ... is there any hope that a SELECT shareName FROM cm_storage.cifs_share might return shares from OCUM as well as reserved/new-existence shares? ( what I'm asking for is the ability to accurately present the shares on a vserver even if I JUST created the share seconds ago in another workflow)

Yes you are right here. Element Existence validation does consider reserved entities.

To give you an example, suppose as a part of your workflow, you want to create a volume followed by the share. The newly created volume will be "RESERVED" in WFA cache. So when you try to run the create share command, your filter will consider that "RESERVATION" and you will be able to create the share. You don't have to do an acquire now between these two commands.

I hope i have answered some of your questions.

Will try and get an answer for Q1 soon.

-Anil

[korns]

Regarding Q2/Q3 ... I guess what I am finding is that reservations/existence doesn't work for shares. I have two workflows, both with reservations and existence validation enabled. After I run a workflow that creates a volume and share, when I run a subsequent workflow that lets the user select which share to edit ACLs on, the share created in the prior workflow does not show up in cm_storage.cifs_shares if used in a UserInput select.

Try it. If I create a volume and share, both named 'test50' and in a subsequent WF I do selects against: cm_storage.cifs_shares I DO NOT see test50 but if I I do a select against cm_storage.volumes I DO see test50.

So if I'm saying this right, I think the reservation/existence checking works for volumes but not shares.

PS: I'm trying to avoid uploading my example WFs but if that is needed to further explain let me know

[ag]

Hi dave,

Yes, i just found out that the reservations are missing for "create share" command.

A burt has already been raised to fix it

[mgoddard]

Hey Anil,

They are missing for a lot of commands. Do you know if they are all being fixed?

ie. Create Export Rule, Modify Volume, Modify LUN

Some of them also have some details that are wrong. The reservation for Create Volume will set a snapshot_policy_id of null if input snapshot_policy is empty, but will create a volume that actually references the "default" policy which is not null. (So the reservation should be searching a default policy, rather than setting it to null). I wondered why all my volumes had snapshots, then realized empty in WFA means default in OnTap not 'none' for snapshot policy.

Michael.

[ag]

Michael,

Some of it are fixed and some are being fixed.

For an exact list, please contact Abhi Thakur.

The create volume reservation you talk about, have you raised a burt for this? It definitely needs a fix

[rle]

Hi Dave,

For Q2, check out the workflow: "Create a new Volume in a Dataset and Wait for object discovery".  There you will see 2 commands "Refresh Monitors on Arrays" and "Wait For Monitor Refresh".

There doesn't seem to be any filters for Shares in cm_storage in WFA 2.1.

Regards,

    - Rick -

[mgoddard]

Hi Dave,

You are hitting the issue because some of the in-built commands do no have reservations. Create CIFS Share is one that does not have them.

I have created PS-Certified versions of the Export Create/Delete and CIFS Create/Delete CIFS ACL Create/Delete. They were intended for WFA 2.2, but I've packaged them up for WFA 2.1 so you can try them

Give them a go and let me know how they go. You may need to write your own filters for now, the discovery of ACL's is part of OnCommand 6.1 from what I understand which should be released shortly in combination with WFA 2.2 which is in RC1 stage.

It is a little heavy handed to re-discover every object, especially for large customers, because a reservation for an in-built command is missing IMHO.

Kind Regards,

Michael Goddard.

[abhit]

Please Open a Case through the NetApp Support Site (https://support.netapp.com) or by calling one of the

NetApp support numbers listed under Contact Tech Support.  Please refer to the Communities thread when

opening a case by adding a link to the thread. This will help us to get this issue rolled into a maintainance

release.

Regards

Abhi