AltostratusHi all,
I'm experimenting with AS3 declarations for configuring LTM services on BIG-IP nodes and can't seem to find a way to directly define static server nodes (create ltm node ..) - the only way they get created is by configuring pool with static members.
Any ideas on what is the rationalle behind it?
thanks,
Vytautas
Hi vytbr2 - I see you're still waiting on an answer, so I've asked a colleague to give some help.
EmployeeHey vytbr2
Think of AS3 as a deployment in its entirety (all pools, all nodes and all virtual servers in 1 declaration) for that tenant. from AS3's perspective why would you have nodes that arent being used by pools or LTM Virtual IPs.
If you think about an AS3 Deployment as the End-State (finished deployment of all nodes, all pools, all virtuals). Hopefully it should help with your question of why its designed this way.
Does this make sense?
AltostratusHi Matt_Mabis
Thanks for your response, it makes some sense, but as a thought experiment - how about applying your argument on pools as well: why would I have pools which I'm not refering to on any of my VSes?
My first answer would be - I don't have them. I'm in control of all the pools I defined in the declaration, so I'm only defining the ones I need for my VSes. I fail to see how is that different for the nodes.
Another thing, that I believe is stemming from the indirect nature of node creation as per the current AS3 behaviour - some weird effects of modifying an already applied declaration (a brownfield deployment). I'm not sure whether this is just a bug or is in fact an intended "feature", but:
- If I'm creating a pool member and giving it a name (via pool->members->servers->name), which in turn creates a node, changing thath name in the subsequent declaration does not get pushed (the config is left intact). This is a violation of idempotency IMHO (e.g. it would be different if I applied it right away as my first declaration).
- Similarly, if I'm later modifying the IP address of the previously created pool member, the new node gets created with the new IP and the old one stays. That in fact results in an additional "trash" node being present, which I don't use anywhere anymore, which is ironically in direct contradiction to your argument 🙂
Let me know your thoughts,
Vytautas
EmployeeHey vytbr2
I agree with the same logic in Pool vs Node, i typically wouldnt have a spare pool floating around except in some test purposes where i need to validate my pool and pool members are working prior to migrating from a single pool to another, or testing out different pool load balancing methods and being able to switch back and forth after testing prior to pushing to full production. Thats the only real rationale i could think of to be honest of why a Pool could exist over a node.
when creating pools with pool members its extremly flexible in adding an object or changing and object, also you can use FQDN vs IP for Pool members (even tho it does create a node) i just see more flexibility and monitoring capabiltiies in a pool vs a node.
When creating a node its a fixed IP address and you cannot monitor specific ports on the nodes so i see more value in a pool and pool members.
I would have to try out the methods you suggested above, in theory you are correct it shouldnt leave any form of trash behind as the only thing that should exist is the exact configuration if it does then i would consider that a bug in code. Ill see if i can give it a run with some code and help identify out the issue if it exists in the latest stuff. What BIG-IP Versioin you using?
