ACC Group Definitions - replacment

So I am still waiting for paid support to get back to me on a status update.  I have not seen anyone logging into my boxes since I opened the ticket up 5/24/2011 and after they acknowledged receipt of all login information.
RLeibl are you still available to help resolve this issue?  It is causing me no end of problems because I have to update my groups for PCI compliance firewall rule-sets and this is preventing me from moving forward without having to manually go through and update 9 firewalls x 5 different sections in the firewall setup.

Hi

Some notes that may be interesting for all of you:

•  When replacing objects (originally this was 'claiming a previously deployed
  object), the ASG is _very_ strict. If the object doesn't match _exactly_ the
  object is not replaced.  This may yield some unexpected results.
  
  
  
  •  Some objects contain lists which contain other objects (roughly speaking). A
    network group contains a list of, well, the network objects.
    When claiming (replacing) such an object, it is critical that the list is in
    the exact same order in the object that is sent from the ACC and the object
    that should be replaced on the ASG.
    
  •  This is on purpose. Treating arrays as ordered is safer than treating them
    as unordered (think: packetfilter rules), and, the object claiming is supposed
    to re-claim objects that have previously been deployed, not objects that just
    happen to 'be there' and should now be controlled via ACC.
    
  
  
•  We found that this behaviour may be too strict in several cases.
  
  
  
•  There are objects that are changed on the ASG, e.g. DNS groups.
  
•  The ASG seems to disregard ordering in cases where ordering is not
  relevant. So when an object is undeployed and made into a local object, it
  seems as if it would be possible that the order of the members changes.
  

•  We changed the behaviour of the ASG (with ASG Beta V8.165) such that the
  order of lists is only relevant in some cases (in fact, we mark, for each
  list, if the list is supposed to be ordered, or not).
  

btw. sorry for being so late. It's crazy busy right now ...

No worries Robert, Astaro support was finally able to get back in touch with me yesterday.  Unfortunately when trying to reproduce the situation that I was able to reproduce multiple times when I first started adding to this thread, we couldn't reproduce the behavior.  I am going to continue to check with the new knowledge that you explained above.

I will continue to update this thread if I can reproduce the error I originally received when trying to deploy groups without success.
____________________
One thing I discovered along this way which may be of use to others:
It seems you cannot create a Network Host (either locally or via the ACC) if the IP address belonging to that network host definition  is assigned to an ASG interface  (v.7.510).

Example the ASG eth1 (internet) is IP 1.2.3.4.  You cannot create a network host object (ACC or locally) that is just this single IP.  

This really presents a challenge when are trying to create a network group white-list across an enterprise. The example I can most readily explain is the the network group we use to allow to access the ASG via Webmin and SSH.  We want to be able to access the Webmin interface for any of our ASG from any of the site networks behind the ASG's.  This should be able to be defined as a single group to be deployed across an enterprise.  Because of the behavior describe above, this is not easily done because the group will not deploy across any of the ASG's because the group contains every ASG's external public IP address.  I only saw one possible workaround of creating a separate network group for each and every ASG you are trying to manage in your enterprise.  It kind of defeats the purpose of using an ACC to control the ASG's if you end of having to manage a group for  every ASG instead of a single group.

I did come up with a workaround that is seeming to work but it is not ideal and I am not sure that it won't cause problems in the future.  The temporary workaround is to instead of creating a networ host object for each of the external IP's to be included in this Webmin white-list group, I created a network/network definition for each external interface of the enterprise ASG's.  Ex
Instead of Network/Host Object 1.2.3.4 I created a Network/Network object 1.2.3.4/32 This is working in some groups but unfortunately it doesn't work everywhere like in network Availability groups, so I still have to create both objects (network and host).

I don't understand why this alias to a physical address cannot be created on an ASG.  I can understand that on the ASG itself, use of the alias should be limited based on the need of use such as in a Multipath Routing setup should be specific to an interface and not a host object but I don't understand why there is an exclusion of the ability to have the alias to the IP address defined in the ASG along side the physical interface.  Is this something that corrected in v.8.0? 
Hope this helps others.