You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently servers cache works based on a timestamp. Each update to the cache is keyed on a timestamp which is expected to be monotonically increasing because get_servers fetches the update with latest timestamp. This is not really an issue since update is always done from same node but can still cause problems when leap seconds creep in. See #1955 (comment). Also the update implementation doesn't take care of reentrancy. It should have a lock around it to avoid corruption.
The interface for this implementation is also very tied to Cassandra. It can be a lot simpler without dependency on certain kind implementation. It should just be a simple get and update (almost like a dict). The implementation for CASS will need to take care of multiple updates via timestamps or locks or ZK clock.
classIScalingGroupServersCache(Interface):
""" Cache of servers in scaling groups """tenant_id=Attribute("Rackspace Tenant ID of the owner of this group.")
group_id=Attribute("UUID of the scaling group - immutable.")
defget_servers(only_as_active):
""" Return cache of servers in a group. :param bool only_as_active: Should it return only otter active servers? :return: Effect of servers where servers is list of dict :rtype: Effect """defupdate_servers(servers):
""" Update the servers cache of the group :param list servers: List of server dicts with optional "_is_as_active" field with boolean value to represent if this server has become active from autoscale's perpective. This field will be popped before storing the blob :return: Effect of None """defdelete_servers():
""" Remove all servers of the group """
The text was updated successfully, but these errors were encountered:
Currently servers cache works based on a timestamp. Each update to the cache is keyed on a timestamp which is expected to be monotonically increasing because
get_servers
fetches the update with latest timestamp. This is not really an issue since update is always done from same node but can still cause problems when leap seconds creep in. See #1955 (comment). Also the update implementation doesn't take care of reentrancy. It should have a lock around it to avoid corruption.The interface for this implementation is also very tied to Cassandra. It can be a lot simpler without dependency on certain kind implementation. It should just be a simple get and update (almost like a dict). The implementation for CASS will need to take care of multiple updates via timestamps or locks or ZK clock.
The text was updated successfully, but these errors were encountered: