fastL4 type for Virtual server?

The coding looks valid (correct parameter names as well as correct coercing into arrays). What are you seeing happening? Is there an error returned or is a success status returned but the change isn't made. Also, have you tried to change the type within the GUI as well? Could be that something else has to change within the virtual before the type can change.

 

 

-Joe

It returns successfully, but near as I can tell, nothing happens on the device (not even after forcing a save of the configuration). I used to know how to turn on debugging of iControl on v4.x, but I don;t know how to do that for v9. If you let me know about that, I'd be happy to send you logs, or some such.

 

 

From looking at bigip.conf doing this through the GUI, it seems the only thing that changes is the addition of the 'fastL4' profile in the definition of the virtual server.

 

 

Michel

Any thought on debugging Joe?

Setting up debugging outlined in this post

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=1&postid=6472

 

Click here

 

 

 

Also, if you could turn on SOAP Tracing in your script

 

 

use SOAP::Lite + trace => qw(method debug);

 

 

 

And send back the full SOAP Request and Response I can rule out formatting issues with the request.

 

 

If the request is correct and the method is returning a success but configuration isn't changing, then this is likely a candidate for a customer support call...

 

 

-Joe

 

 

-Joe

Thanks. The forum post on debugging is the key for me. I'll play around with it tomorrow and I'm going to need to build a little test case (outside of my 'framework') but that shouldn't take long.

 

 

Now back to Lua.

rebooting does not help.

 

 

Any thoughts/suggestions are much appreciated.

Ok, found out a couple of things.

 

 

1) First. disable tracing when using this method. There is a bug in the output logic that is causing the server fault.

 

 

2) The code in the set_state maps FAST_L4, FAST_HTTP, and POOL to RESOURCE_TYPE_POOL. I'm not sure for the reason on this and I'll track down the dev that did the work to try to find out for you.

 

 

So, outside of a hotfix, this isn't going to work as all calls to/from the FAST_* types will map to POOL.

 

 

-Joe

Thanks for the follow up. Should I raise a bug report, or is this enough to get the ball rolling? Also, how would I track the progress?

 

 

Michel

 

If you need it fixed, then you should submit a service request to make sure it can get prioritized into a release that suits your needs.

 

 

-Joe

OK, a change (CR78649) was raised. A workaround was suggested by the engineer. He suggested to use 'add_profile' to force the issue on the virtual server. Unfortunately, this results in:

SOAP Error: SOAP-ENV:Server; Exception caught in LocalLB::VirtualServer::add_profile()
Exception: Common:perationFailed
        primary_error_code   : 17236117 (0x01070095)
        secondary_error_code : 0
        error_string         : 01070095:3: Virtual server TESTFastL4 lists incompatible profiles.

 

So, I wrote some code to delete the profile first, using 'remove_all_profiles'. Unfortunately, even though that call returned no errors, it did not remove any profiles that I could see. Using 'get_profile' I notice that the 'tcp' profile is defined and does not get removed by 'remove_all_profiles'. My workaround ended up being:

 

 

- call get_profile

 

- use output of get_profile and feed it to 'remove_profile'

 

- use add_profile to add 'fastL4'

 

 

After all that (and a 'save_configuration' for good measure) the virtual server now does show up with the fastL4 profile (and the tcp profile for that matter....). Perhaps someone can explain the issues observed?