Functions for working with iApps

[joel74]

I think it would be helpful to have New-, Get-, Set- and Remove- functions for iApps.

[elijahgagne]

I have done a lot of work on this because we primarily use iApps. It might take me a little bit to clean up what I have, but I'd be happy to work on this.

[joel74]

Thanks, Elijah. I'd be happy for the help. I'm guessing the lower-hanging fruit will be doing Get- and Remove-, and then moving on the New- and Set-, but I'm open to whatever. Let me know if I can help with reviewing and testing stuff in your fork. Cheers.

[elijahgagne]

I think have something worth sharing at https://github.com/elijahgagne/POSH-LTM-Rest/tree/issue116 implementing Get/New/Remove-Application. I wasn't sure what to do for Set-Application. In general I don't think you make changes to an iApp. You either change subitems in the Application (e.g. an iRule) or you change the template and then redeploy the iApp.

I would also like to add a function that redeploys iApps, but I'm not sure what to call it. Maybe, Update-ApplicationRedeploy? I don't like it, so please let me know if you have a better suggestion. Or maybe we decide it makes sense to have a Set-Application and make -Redeploy a switch on that function.

Here is a gist demoing usage
https://gist.github.com/elijahgagne/282d2171b9e8afd226f47c5264f2cbae

I will add that I tried this on a number of different iApp templates and ultimately decided I needed to make New-Application as generic as possible. For my use cases, I build wrappers around New-Application that supply most of the Tables/Lists/Variables so that my wrapper functions only need a few parameters filled out.

I should probably also mention that I'm working against LTM v11.6 and iApp templates are based on TCL. I hear that in either v12 or v13, BigIP has changed templates to be based on JavaScript. It sounds like my organization is thinking of upgrading to v13 sometime in the next six months (skipping v12). I have no idea if the REST api is different between v11/12/13 for applications.

I think I've made some potentially controversial decisions and I'm very open to suggestions on improvements. Please let me know what you think when you get a chance.

[joel74]

Thanks, Elijah. The main thing I've noticed so far is a dependence on a rootURL property in the F5session object, which is currently only used internally in the New-F5Session function. Seems like it might be generally beneficial to add that property to F5Session objects, though rootURL vs baseURL is probably a confusing distinction. Once that's there, I'm able to get existing iApps on v12.1. I'm working through the New-Application example, figuring out what needs to be customized for the example to work (i.e. iRules, VLANs, Access profiles, etc.)

Do you think it would make sense to distinguish between the iApp / application service, and the associate template and its settings specific to the application service? I.e have one function that either associates an application service with a template or no template, and another function that that modified the template settings for a specific application service?

[elijahgagne]

Sorry for the delay, I was expecting that Github would email me when there was an update. I do agree that rootURL/baseURL is a little confusing so I'm certainly open to doing something different there.

If I'm understanding your question correctly, perhaps there would be:

• Set-Application, which would set the application template and other standard settings such as enable/disable strict updates
• Update-Application, which would let you change values of the template components

If I've understood correctly, my personal preference would be to just have Set-Application and let it handle both types of updates. But I don't have strong feelings here.

[joel74]

I'm leaning towards a simple rename of the variable in New-F5Session from $RootURL to $DeviceURL (or something similar) and adding that property to the returned F5 session. Does $DeviceURL make sense?

Re: the application service / template question, I've reached out to someone at F5 for their assistance in how best to structure these functions. I feel (but I definitely could be wrong) that modifying an iApp template is a separate type of action from modifying an application service. The follow-up to this is whether changes in the 3 tabs - Properties, Reconfigure and Components - should all be handled in a single Set-Application setting, or split out into more than one function.

However, a broader overarching question is, is this module the right place for this? This was initially meant to be a module for working with F5's LTM, and now we're looking to expand beyond, to the SYS space as defined in the iControlREST docs. It's tempting to consider a new F5-SYS module, provided that the F5Session object could be shared between the two modules, and so put functionality for iApps, SSL certs, failover, HA, and anything else that falls under the SYS heading, in there.

[elijahgagne]

Going with DeviceURL works for me. I just made that change and pushed it. If you're open to it, I submitted a pull request to add in Get/New/Remove-Application. I'm happy to continue on this and create a Set-Application and/or Update-Application function, depending on the direction we reach a consensus on. I'll be interested to hear what advice F5 provides.

I issued the pull request before reading your last paragraph, so that request might have been premature. I can delete that if we want to consider a new F5-SYS module for the iApp functions. Personally, I would prefer one module, unless we want to implement more of the administrative functions of sys. I routinely create virtual servers, pool, irules, and iApps. So it seems natural to me that those would all be in one module. I don't generally use anything in sys besides iApps.

I haven't looked at this closely, but Big-IP does maintain a Python SDK at https://github.com/F5Networks/f5-common-python. It combines a lot of functionality into one Python module. But their target is to be a SDK.

[joel74]

So here's (roughly) what I asked my F5 contact: "What is the best way to structure and group new PowerShell functions for working with iApps? It seems to be a bit more complex than your standard New- / Get- / Set-iApp. The docs for iControlREST distinguish between iApp templates and iApp services. I'm thinking it makes sense to somehow follow this distinction. Is there guidance you can offer in terms of how best to structure the families of functions for working with iApps?"

And this was his response: "iApps took a turn for the robust/complex with iWorkflow which is what’s creating the different template vs. service ideas. iWorkflow 2.1 is the first version where you upload iApp templates directly instead of importing from a BIG-IP so that kinda infers you can create a template for easy application administration on BIG-IP and leave it at that, OR you can focus on creating a framework that caters to tenanted applications.

In the latter case, there’s a need for mapping variables to common element names so you don’t drive the admin nutty with what options they need to expose to the tenant. Check out Nathan Pearce’s iWorkflow 201 episode 4 on youtube for a better idea.

I THINK this is why they have the different naming context and I hope this is what you're referring to. I’ll check out what the nomenclature on GIT is to see what’s up."

So a bit more of a complex answer than I was hoping for. I've been thinking and experimenting a bit with maybe developing a root F5 PS module, and having F5-LTM and F5-SYS be nested modules. Ideally nothing would change with the F5-LTM module, though I can see the New-F5Session function getting deprecated at some point in place of a New-F5Session function in the root F5 module. I'm just leery of lumping functionality such as iApps and SSL certs into an LTM module when strictly speaking, they're in a different namespace.

[elijahgagne]

OK. I'll delete my PR for now. I'd be happy to work on iApp functions once a structure is decided on.

[vercellone]

My iApp knowledge is admittedly lacking, but I think this module IS the right place for this. My perspective is that F5-LTM refers to the physical device(s) not iControl. This is a PowerShell Module which wraps the devices' REST API. There is no reason for it to be constrained to a single iControl namespace. The DeviceUrl/BaseUrl ambiguity is easily addressed by simply delegating the /mgmt/tm/ltm or /mgmt/tm/sys portion of the url to each individual function. Make BaseUrl="https://$LTMName". Simple. Flexible.

As for Set-Application: If I understand the intent of the potential names you've mentioned I think a common Set-Application with distinct ParameterSetNames would suffice for the full template replacement vs. partial edits. And, a -Deploy switch seems reasonable for deploying the template immediately. But, that presumes you won't Deploy by default so you need a mechanism to explicitly deploy later. For that consider adding a .Deploy() ScriptMethod member to the object returned by Get-Application. I would even make the Set-Application function call .Deploy() when the -Deploy switch is $true rather than duplicate the code.

[joel74]

I'd be happy if we can come up with a solution where we don't have to shoehorn the F5-LTM module in as a nested app into a parent F5 module, but I also want to attempt to follow F5's structure. From the perspective of the device, at the top I see the BIG-IP. Within the BIG-IP are modules, such as LTM, GTM and APM. iControl's top-level namespace is TM (traffic manager), and underneath that are sections that correspond to the modules - LTM, GTM, APM, etc.

The functionality that the F5-LTM PS module has addressed so far has been almost completely in the /TM/LTM space, with one or two exceptions. I'm not completely opposed to trying to expand this PS module into other BIG-IP areas, but I want to make sure it's done as clearly as possible.

[elijahgagne]

Thanks. Is there any desire to make clear distinctions at the front-end (e.g. by using a prefix to the noun of the function) or just in the back-end (function code)? If it's just the latter, what do you think of Jason's suggestion of delegating the /mgmt/tm/ltm or /mgmt/tm/sys portion of the url to each function?

[joel74]

I'm not sure that I see the benefit in putting non-LTM functionality in the F5-LTM module, and then renaming functions to distinguish between LTM functionality and other (GTM, APM, SYS) functionality. Currently, as I mentioned, the majority of the functionality in the module is LTM-specific. That said, though, I do want to add functionality to manage iApps, certs and other things not in the LTM module/namespace. If F5-LTM became a nested module within a parent F5 module, and all that the parent F5 module did was to load F5-LTM and other nested modules, and pass the F5 session along, that might accomplish what I'm envisioning. The F5-LTM module could continue to be loaded stand-alone or as part of the F5 parent module.

In regards to Jason's proposed delegation solution, if we decided to stick with the existing module name, maybe we could have BaseURL be "https://$BIGIPName", and then create subfolders called \LTM, \GSM, \SYS, etc. to group functions by module under the \Public folder. Also, LTMName and LTMCredentials are kind of misnomers. Maybe we change them to aliases so we don't break existing implementations and call the params BIGIPName and BIGIPCredentials.

[elijahgagne]

I'm glad you don't want to rename functions. I like you're idea of creating sub-folders, that makes sense to me to logically group parts of the code based on namespaces.

The part that still hard for me to understand is thinking about the LTM as a namespace instead of a device. I've always looked at this module as the PowerShell tool to manage the LTM device. We have other BIGIP devices (e.g. GTMs) and I've never thought that code for them belonged in this module. But anything for managing the LTMs did. From my thinking, LTMName and LTMCredential makes perfect sense because that's the hostname and credential I use to manage everything on the LTM devices, regardless of which namespace it's in.

Regardless, though, I will respect your decision and direction if you see things differently.