Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Questions and Answers

Loading... Loading...


I'm currently trying to decide how to best utilize iApps and I feel that making changes to objects later can be tricky. I wanted to start a discussion to see if I got this right.

The theory is that every object needed by an app would be created via the template wizard.
Then every subsequent change must only be made through the "reconfigure" button. The strict-updates checkbox enforces that.

Real live is quite different.

1. There are many objects that are silently created by the template like http-profiles, tcp-profiles etc..
Those cannot be edited in the template by nature. You would edit them just like you did before.
The strict update doesn't apply here since you're not changing the templates association with the profile but the profile itself.

2. The objects that you can create directly in the template such as http monitors can be edited in 2 ways.
The correct way is via the "reconfigure" button. The incorrect way is by unchecking "strict-updates", making the change old-school and then re-checking "strict-updates".

This is where it gets tricky since someone could make a change old-school style to a VIP and then someone else might overwrite it again by making another change new-school via the "reconfigure" button.

Using the template 100% is simply not an option at this point so I feel it makes most sense to keep the http template as basic as possible and then only use the old-school way to making updates by un-checking and re-checking the "strict-updates" box. I'm forced to do that for many objects anyway and this would at least avoid confusion.

Am I wrong ?

6 Answer(s):


It's definitely true of the iApp framework that if an iApp template creates objects that those objects can only be manipulated using the iApp framework (unless you disable strictness). However, that's somewhat contradictory to another goal of the iApp templates which is to ask as few questions as necessary - otherwise one ends up implementing the entirety of the UI elements corresponding to these objects all mashed together in an iApp - it's at least messy, and in some cases impossible if the iApp framework doesn't support what you want to do. So if we don't include enough options for you in the template, but we also don't let you change them by hand, then what do you do? I see what you're getting at.

Basically when we (F5) design templates, we take a good look at what the majority of customers will want to do and we expose those options in the templates. We are actually in the process of creating a second generation template for many of the current ones that we ship that do a better job of this as we have gotten good feedback about it, have reviewed support cases, and have reviewed customer configurations provided via iHealth. We might release some of those on DevCentral early prior to them shipping as part of TMOS. We also recognize that there is always going to be someone that needs to get at the options outside of what the iApp allows. To handle those situations, we allow for an advanced user to create a profile/pool/snat/etc outside of the iApp framework with arbitrary options configured, and then to reference those objects in the template in order to accomplish the desired configs. Some of that behavior is available already in our templates, and we're adding more of it to the ones that we're working on right now.

We generally discourage customers from disabling strictness on iApp services for the reasons that you list - it basically makes the situation unsupportable and the behavior unpredictable from template to template depending upon how it is written. Sometimes changes made outside of the iApp once strictness is disabled will make it through a reconfiguration of the iApp service - but sometimes it won't. It totally depends upon the iApp, but uncertainty like that is bad for stability and reliability.

If you find that the iApps don't expose enough options for them to suit your needs, then it might be that we need to add some options for you (or that you should do it yourself if that works for you). I hesitate to add that that you might not be a good fit for iApps due to your environment or how you need to use the product but it might be the case as well.

Thank you for your insight !
I understand that you try to fit the 80% of basic http apps but I find it a bit odd that you didn't include iRules f5.http f.e.
As we all know iRules are the meat of many loadbalancing scenarios and I refuse to believe that only very few customers use them.

The problem here is that if I use your template but I need iRules associated with the VIP I HAVE to go the "uncheck strict-checking" route.
Are you saying most of your customers don't need iRules with http VIPs ?

I know someone provided an enhancement on codeshare where you can add iRules in the template. I used it and it works wonderfully - except now I opened up pandora's box since I'd have to create a huge red warning box somewhere saying "DO NOT add iRules directly in the virtual server !!". Yet if someone asks me "How do I adda cookie for encryption to the http profile ?" I have to say "Do it like you've always done it by directly editing this profile". You see my dilemma ? Its hard to document stuff like this. Its much easier so say "Only do this this one way !!"
This is why I'm debating whether I should bother with the iRules-enhaced template.

There is another enhancement where someone added the ability to point to an SSL profile. It works too but my dilemma is the same.

So you are saying you guys have something new cooking ? I don't have time to customize templates too much especially if you guys are coming out with new ones.
What is the timeframe for these 2.0 templates ?



Not including an option for adding an iRule was an oversight on the original design. We are correcting that in the version that I mentioned before as well as a bunch of other things.

I expect we'll have something to post on DevCentral within a month or so - but just so you're aware, templates posted on DC aren't supported by F5 technical support. Once we have a chance to run this through our QA and testing though, it'll be integrated as part of a release or made available on our electronic software download site (at which time it'll have full support).
Understood but I'm happy to at least help you QA this thing so as soon as you have something decent - post it please.


Since there are still too many things missing in the template and you are close to providing a new version I figure it's not worth hacking away at the old one.
I'd like to take this opportunity to ask whether you guys might consider adding the following as well :

* The ability to NOT automatically set a caching profile. See my post here :

* The ability to create my own http header in the monitor without any questions about fqdn etc... see my post here :

* The ability to automatically name the cookie that is added by the persistence profile. The name would be "appname_persistence_cookie".

* The ability to add this same cookie to the list of Encrypt Cookies and add a random passphrase

Just some things I'd use.

One more thing.

* The ability to name my nodes rather than naming them after the IP.

That would be great too.

Your answer:

You must be logged in to reply. You can login here.