Making changes post iApp creation - tricky

Hello,

 

 

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.

 

 

Cheers,

 

-Brent

Brent

 

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 ?

 

 

thx

 

 

stucky

 

 

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.

 

 

thx

Brent

 

 

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 :

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/2032/aft/2163930/showtab/groupforums/Default.aspx

 

 

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

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/2032/aft/2163913/showtab/groupforums/Default.aspx

 

 

* 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.

 

 

Thanks

One more thing.

 

 

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

 

 

That would be great too.