Hi Nathan, Thanks for spending the time to comment while you’re on vacation. I did have issue connecting the big-ip ve to iworkflow when the NTP was not set. After configuring both to sync to ntp pool, iworkflow can discover and connect to big-ip ve (connector seems to work fine) only the services/applications deployment don’t. Rebooting host and VMs did not help either. I’ll reach out to our F5 account team as well. Enjoy your holiday!
Hi el-homer,
I’m back from travels now and just wanted to check-in to see you’ve got everything working?
Regards,
Nathan
Hi Nathan, Welcome back. I have reached out to our F5 account team and shared the iHealth info of the iWorkflow and BIG-IP VE. might has to do with the allocated VM resources? anyhow no joy yet. Do you mind sharing your (F5) email where I can send the links to my qkview on iHealth as well?
Hi Nathan, i still didn’t understand if there will be an interaction between iWorkflow and BIG-IQ? At my company we have taken 2 licencies , one for iworkflow and the other for big-iq just for valuating the product. Can you explain by mean of a picture the interaction between those 2 components: big-iq and iworkflow. Can iworkflow be a standalone “device”, independent from big-iq?
Hi Nathan, i still didn’t understand if there will be an interaction between iWorkflow and BIG-IQ? At my company we have taken 2 licencies , one for iworkflow and the other for big-iq just for valuating the product. Can you explain by mean of a picture the interaction between those 2 components: big-iq and iworkflow. Can iworkflow be a standalone “device”, independent from big-iq?
Hi Ledio,
There is currently no interaction between iWorkflow and BIG-IQ. Yes iWorkflow is designed to function as a standalone controller, independent of BIG-IQ. Do you have sometime this week for a demo or discussion? Mark
Hi Ledio,
There is currently no interaction between iWorkflow and BIG-IQ. Yes iWorkflow is designed to function as a standalone controller, independent of BIG-IQ. Do you have sometime this week for a demo or discussion? Mark
This is more a question of what operational model would you prefer. 1) automation, or 2) manual operation via a device management tool/controller.
iWorkflow is a platform that presents a catalog of service templates which can be deployed via the iWorkflow Tenant web interface, or the iControlREST API. This is VERY useful for automation. Device/feature management is abstracted from the deployment system.
On the other hand, BIG-IQ is for device management and is focussed on managing devices, features and settings.
The right tool depends on the operating model you wish to adopt. Are you wanting to automate deployments, or manage devices?
iWorkflow is a platform that enables automation/orchestration workflows. BIG-IQ is for device management, by people.
That help?
This is more a question of what operational model would you prefer. 1) automation, or 2) manual operation via a device management tool/controller.
iWorkflow is a platform that presents a catalog of service templates which can be deployed via the iWorkflow Tenant web interface, or the iControlREST API. This is VERY useful for automation. Device/feature management is abstracted from the deployment system.
On the other hand, BIG-IQ is for device management and is focussed on managing devices, features and settings.
The right tool depends on the operating model you wish to adopt. Are you wanting to automate deployments, or manage devices?
iWorkflow is a platform that enables automation/orchestration workflows. BIG-IQ is for device management, by people.
That help?
@Jie;
The BIG-IQ name is to separate it’s function from BIG-IP. BIG-IP would be the engines running the apps, and BIG-IQ is your mission control. It’s what we always wanted Enterprise Manager to eventually turn into but because it was such a big departure from EM, both in platform and function, it was a logical marketing decision to segregate it.
BIG-IQ is very much the Enterprise Admin’s wish list of how to manage a large BIG-IP ecosystem. It’s RBAC allows separate teams to manage their slice of BIG-IP. Sec admins can monitor DDoS outbreaks and manage appropriate policies on the fly. It allows network admins their usual management duties from deploy/T&M/and monitoring. And it allows application owners a deeper dive into how their application is performing.
Current BIG-IQ management functions were very different from BIG-IQ “Cloud”. To separate out the products intended use further it became iWorkflow, more situated to the tasks it provides. This allows the iWorkflow and other F5 automation/orchestration teams the flexibility to add new features faster and stay current with new MANO trends. We’ll get more content out for BIG-IQ and iWorkflow focusing on where you would use them and problems they solve. I think coming at it from that angle will help people make product decisions on what’s most important in their environment.
Do check out Nathan’s Youtube channel and watch the 101 and 201 iWorkflow series. You’ll start to see where segregation of the products became a benefit for not only the users of the product but the developers of it too!
-Chase
@Jie;
The BIG-IQ name is to separate it’s function from BIG-IP. BIG-IP would be the engines running the apps, and BIG-IQ is your mission control. It’s what we always wanted Enterprise Manager to eventually turn into but because it was such a big departure from EM, both in platform and function, it was a logical marketing decision to segregate it.
BIG-IQ is very much the Enterprise Admin’s wish list of how to manage a large BIG-IP ecosystem. It’s RBAC allows separate teams to manage their slice of BIG-IP. Sec admins can monitor DDoS outbreaks and manage appropriate policies on the fly. It allows network admins their usual management duties from deploy/T&M/and monitoring. And it allows application owners a deeper dive into how their application is performing.
Current BIG-IQ management functions were very different from BIG-IQ “Cloud”. To separate out the products intended use further it became iWorkflow, more situated to the tasks it provides. This allows the iWorkflow and other F5 automation/orchestration teams the flexibility to add new features faster and stay current with new MANO trends. We’ll get more content out for BIG-IQ and iWorkflow focusing on where you would use them and problems they solve. I think coming at it from that angle will help people make product decisions on what’s most important in their environment.
Do check out Nathan’s Youtube channel and watch the 101 and 201 iWorkflow series. You’ll start to see where segregation of the products became a benefit for not only the users of the product but the developers of it too!
-Chase
hi Nathan,
Is possible to import a GTM(DNS) device inside iworkflow, in order to move the tree structure: (gtm<--ltm<--(vip;pool;nodo)) inside iworkflow? My intention is to have the association of vip,pool,node with gtm, becuase we have a gtm for every data-center.
I’m experiencing a very similar issue with BigIP 12.1.1 and an iWorfklow 2.1.0 eval. When I create a new L4-L7 service its status shows “Publication Service Unhealthy: unavailable” . Additionally the virtual server and pool don’t get created on the LTM. In my case, iWorkflow and LTM are both configured to use the same NTP servers. Any assistance would be appreciated. Thanks
Hi ,
I have a question: i created some virtual services using iworkflow so with some iapps. Now we need to upgrade our bigip devices. Usually we transfer the UCS file from old bigip to the new one. How does it work with services created with iapps, will i find the same services in the new bigip (discovering the device from iwrokflow) or i have to create all the services from scratch?
hi, which version of release of bigip is supported in iworkflow2.3 ? 13.x is supported?
Hi Nathan,
I installed iworkflow in my enviroment i added my bigip device into it and later i think that i can see and manage all configurations (vs,pools and nodes) on the bigip.But nothing is imported into iworkflow. I read the below article, it mentions role based access control. I suppose i can create different type of users and i can assign each users different resource from imported config.But as i see that iworkflow provide us only creating new services rapidly and easly.but it does not provide managing existing or manually configured services on bigip devices.
Hi Nathan, is there any solution using iworkflow to make some rest calls to bigip devices without using the admin credentials of bigip but maybe using any local user defined inside iworkflow(where we have imported the bigip device) and enabling some rest calls to this user ?