reservation not working with certified command

[francoisbnc]

In a workflow with two certified commands: remove volume (if exists) and clone volume.

Reservation works fine, I can run multiple times the workflow.

Hovewer if I force data source acquisition from dfm 5.2, cache updated come YES only for clone volume. That means the next workflow failed because  remove volume is disabled.

Why remove volume cache is not updated, that break the reservation process. I miss something?

[shailaja]

Hi Francois,

Could you please look at this post and see if it helps in understanding this behavior:

http://community.netapp.com/t5/OnCommand-Storage-Management-Software-Discussions/WFA-issue-with-cache-updates/m-p/43293#M8897

Thanks,
Shailaja

[francoisbnc]

Hello Shailaja,

Oh sorry, I totally miss the post of anil, it's more clear now.

But to solved this behavior, if I need to have remove volume and clone volume in the same workflow, how can i proceed.

Thing is, I want to have a refresh workflow that work in all cases even volume clone doesn't exit. Example, when workflow is executed the first time.

Regards,

François

[francoisbnc]

Hello Shailaja,

I made some tests based on comments of anil and I remarqued that usage of remove volume and clone volume in separate workflows work fine. Even I acquire from DFM.

In this case that should be possible to make prioritization in reservation? depending on where commands are executed in workflow, from left to right and top to bottom.

François

[abhit]

Hi Francois:

"In this case that should be possible to make prioritization in reservation?"

Can you please elaborate the question.

Regards

Abhi

[francoisbnc]

Hello abhi,
In a workflow for example to recreate clean env from scratch. Delete volume and create volume are used, in this order. so in term of reservation, as create volume is executed after delete,a finder executed after must return that the volume exists. Even after cache updated from dfm or ovum.

Regards
Francois

[abhit]

Hi Francois:

It is supposed to work the way you have mentioned.

Regards

Abhi

[francoisbnc]

Hello Abhi,
Sorry I am lost. Anil said in previous post

"There are two conflicting reservations that are happening here. One reservation thinks "test_clone" volume does not exist(REMOVE VOLUME). The other reservation thinks "test_clone" volume exists and was newly created(CREATE CLONE)."
In my example we are exactly in the same conflicting situation after dfm acquire.
So what I have to do to have a refresh workflow that works in all situations.

Regards,
François

[ag]

Hi François,

I am afraid there is no straight workaround here.

There are two things you could do:

1. Manually remove the reservation for remove volume.

2. Use different volume names.

This is a very tricky situation and we have a lot of conflicting commands that can be put in a workflow.

[ag · Accepted solution]

We do have a bug filed for this and will work on it for the next release.

[francoisbnc]

Hello,

Is it fixed now in 3.0RC1?

Regards,

François

[ag]

Hi Franc,

It is not fixed in 3.0RC1.

Since it is a major fix, we are currently looking at the prospect of fixing it in future release.

Please let me know if you have any questions.

Thanks,

Anil

[rkiran]

Hi Franc,

As a workaround to the issue, you can try disabling the following in your workflow setup details (under Setup --> General tab):
1) Consider Reserved Elements and
2) Enable element existence validation

[francoisbnc]

Hi rkiran,

If I need map a LUN from a cloned volume, reservation is mandatory. So I can disable it.

François

[francoisbnc]

Hello,

I'am again faced to reservation problem with couple of vol clone and vol rename.

So i decided to totaly disable reservations, because they are not usable for me. It's a shame because that could be very helpfull.

When do you planned to have a look on that, I really need this problem fixed.

thanks

François

[abhit]

Hi Francois: 
Thanks for your mail. Sorry to hear that.
He had a look at it and fixing it was not trivial.

The fix will require some re-design and will hence take some time to fix this issue. 

We will prioritize it and try to find a solution.
We will get back when we have one. 
Regards
Abhi

[LUKASPRELOVSKY]

Hi,

what is the current status?

Br,

Lukas