Forum Discussion
Steven_Le_Roux_
Nimbostratus
NimbostratusTransaction issue w/ iControl v11
Hi,
I run into an issue while I'm trying two things in one transaction :
- set the template property for a given monitor
- assign a monitor on a pool created in the same transaction
Here is the process I would like to have :
1 - Start a transaction
2 - create a pool
3 - create a monitor template
4 - adjust the monitor template (recv and send strings)
5 - assign the created monitor to the created pool
6 - create a virtual address
7 - create a virtual server containing the created pool
8 - set snat automap to the created vs
9 - set vlan to the created vs
10 - submit the transaction
This issue is I have to run steps 4 and 5 out of the transaction so I have :
1 - Start a transaction
2 - create a pool
3 - create a monitor template
6 - create a virtual address
7 - create a virtual server containing the created pool
8 - set snat automap to the created vs
9 - set vlan to the created vs
10 - submit the transaction
4 - adjust the monitor template (recv and send strings)
5 - assign the created monitor to the created pool
If I don't invoke a transaction, this works w/o any problem, so I guess the transaction process, for these two methods, parse the saved configuration w/o taking care of the pending configurations.
Could you confirm the issue ? Do you have plan to include this in a single transaction ?
(I can provide some code implementation if needed)
Thx
hooleylistCirrostratus
Hi Steven,
In addition to posting here, I suggest opening a case with F5 Support to request this enhancement to transactions. I am not sure what you're seeing is expected. Maybe Joe can comment on that. But for the RFE, a support case will be the best option.
Aaron
Steven_Le_Roux_@hoolio : done. thx
I will forward here the final word on this case.- Yes, this is a known issue with transactions. In fact, we talked about it on the recent iControl Guru webcast we did.
The issue is due to the fact that some of the methods (such as the monitor methods) rely on the underlying objects to be created for internal validation to occur. In a transaction, when the calls are made, validation happens but the objects are not actually created until the commit happens. But, for the methods that have validation that looks for certain objects to physically exist, they will fail.
Again, this is a known issue and it is only present on a few methods, which you've found some of them.
First of all, I'd submit a support request to get it fixed.
Second, as a workaround for now, the best solution is to break your code up into 2 transactions where the monitors are created in a second transaction after the first completes.
-Joe - Steven_Le_Roux_Posted By Joe on 03/28/2012 08:35 AM
Yes, this is a known issue with transactions. In fact, we talked about it on the recent iControl Guru webcast we did.
Yes it was me who asked for this issue :)
The issue is due to the fact that some of the methods (such as the monitor methods) rely on the underlying objects to be created for internal validation to occur. In a transaction, when the calls are made, validation happens but the objects are not actually created until the commit happens. But, for the methods that have validation that looks for certain objects to physically exist, they will fail.
Again, this is a known issue and it is only present on a few methods, which you've found some of them.
First of all, I'd submit a support request to get it fixed.
Second, as a workaround for now, the best solution is to break your code up into 2 transactions where the monitors are created in a second transaction after the first completes.
-Joe
that's what I did until there is a proper solution.
