Forum Discussion

Sam_Hall's avatar
Sam_Hall
Icon for Nimbostratus rankNimbostratus
Jul 29, 2013

Can iApps display a textarea parameter?

I've figured out how to create a hard coded iRule from within an iApp. Now I'm wondering is it possible to allow the user to manage the iRule directly from the iApp configuration screen. Otherwise, is there any way to avoid the need to disable strict updates to edit an iRule created via an iApp?

 

Another alternative I found was to create the iRule first and then allow the user to link the iRule to the virtual server managed by my iApp. This gives the desired result, the iRule is independant of the iApp so the contents are not reset if I reconfigure the iApp. It's just an extra step which should be able to be automated. When I create an iRule from within the iApp is there anyway to prevent it from being reconfigured?

 

3 Replies

  • Brent_Blood_768's avatar
    Brent_Blood_768
    Historic F5 Account
    Hi Sam,

     

     

    iApps (and specifically APL) don't have support for multiline text entry widgets. There is an existing enhancement request (BZ372904) covering adding this (and other widgets as well) however. Please contact F5 support and reference that BZ if you'd like to add some weight to the request. Most of the workarounds that I can think of are likely unworkable: things like adding a bunch of xxlarge string inputs where each one represents a line in an iRule and then glue them all together in the implementation.

     

     

    Do you actually need for the user to be able to paste in and potentially edit an entire iRule, or is your case that you have iRules that need customized in small ways for a given deployment? If that's the case, I recommend that you embed the iRule's source into the iApp's implementation, and then to ask questions in the presentation that gather the data to customize the iRule. Then in the implementation, use something like "string map" (or if you're running v11.4 use tmsh::expand_macro) to build the iRule programmatically. I can provide more details on this technique if it's interesting to you.

     

     

    Your current workaround of managing the iRules outside of the iApp and then referencing them from within it is a common pattern and one that we (f5) have used for many of the supported iApps to get around this situation. If you need to accept entire free-form iRules, it's probably the best solution available right now.

     

     

    Cheers,

     

    -Brent
  • Brent_Blood_768's avatar
    Brent_Blood_768
    Historic F5 Account
    I failed to answer all of your questions, sorry.

     

     

    Otherwise, is there any way to avoid the need to disable strict updates to edit an iRule created via an iApp?

     

     

    That depends on what version you're running. I forget when it was introduced (maybe v11.3?) but the "app-service" property of an object is now writable. When creating an object via tmsh::create, you can now manually set this property to "none" (you might need to create the object outside of your app's folder by prepending "/Common" to the name - or building that prefix dynamically using tmsh::pwd if you're using admin partitions) which will cause the object to not be owned by the iApp - and thus allowing external edits without disabling strictness. This has much of the same danger as disabling strictness, only it protects the rest of the service's objects. If you do this, be aware that the next time your iApp runs it'll still try to overwrite this object unless you carefully handle the situation in your code.

     

     

    When I create an iRule from within the iApp is there anyway to prevent it from being reconfigured?

     

     

    I think I understand your question: you want to have an iApp template create an iRule when the service is first created, but then to leave it alone on subsequent runs. Is that right?

     

     

    This is possible, but not very easily, and not without some hackery. It's not easy for an iApp implementation to detect if it's being submitted for the first time for a given service, or if the template has been re-entered and it's a resubmission. It's the 99+% case that a run through the implementation for a given iApp doesn't care whether it's creating new objects or overwriting old ones - the underlying framework handles doing "the right thing" generally. However, if you want to make an iApp only create objects on the first run for a service, you can manually inject a variable into the application service object (off the top of my head, something close to: "tmsh::modify sys app service ${tmsh::app_name}.app/${tmsh::app_name} variables add \{ first \{ value false \} \}"), and then look for that variable earlier in the implementation. If it's not there, it's the first run - otherwise it's a subsequent run and you should skip creating the iRule.
  • Thanks for your help, you understood exactly what I meant.

     

    I'm planning on moving a lot of sites off an Apache web server/reverse proxy and have developed a single iApp template which is flexible enough to cover the configuration of all of them (almost). The problem is that many of the virtual hosts have little custom rewriterules and proxypass directives. So I need the option of a flexible irule attached to each iApp created from the template (this way I only have to maintain one iApp template, I rather not have to fork it and then have to worry about how to maintain all the various copies of the iApp).