Awesome, I'd be happy to discuss. The modules I pointed to at the separate github spot came in to being only over the last year or so. I didn't have a place to put them publicly until the f5networks github account came about.
Hopefully, in time, they will find their way into the upstream product and I can remove this side-band repository we currently have. I'm more interested in being part of ansible's workflow than maintaining a separate one.
I share your same concerns. To the best extent I can, the modules in that repo are idempotent. They do not have a corresponding check-mode, but I agree this is a needed addition. Finally, where I have been unsure about how to implement an interface, I have punted and looked at existing modules. That's why you see some of those parameters named the way they are. I've just used existing modules as references.
For example,
Also I've tried to add REST and SOAP interfaces if similar functionality exists in each. It helps test those interfaces on my end and future-proofs these modules in the (unlikely) event that one of the interfaces gets deprecated.
I'll send a PR to upstream for the bigip_command module. If there are any others you would like to see sooner rather than later, lemme know.
My initial work has been around more of the bootstrapping portions of the process as apparently that's not an entirely clear process. I've been cycling through virtual editions like its going out of style too, so to start with bootstrapping just seemed to fit (if your standing them up and tearing them down all day...why not automate it...)
Moving forward I'm honestly open to suggestion. If you think a specific set of functionality would best be encapsulated in a role or module, let's have that discussion and see what comes of it.
Feel free to ping me off list, or reach out on DevCentral or on github.
Thanks!
-tim