Timestamps do have the benefit of being simple to implement, but also have some flaws:
1. Relying on the standard system clock means they aren't monotonic, i.e. if the clock is adjusted backwards no updates may be accepted by nova-scheduler 2. If you have nova-api running on two different hosts it requires the hosts times to be synchronized or updates could be lost 3. Very unlikely with microsecond precision but two updates could have the same identifier. While more complex, and requiring a database change, an integer that is updated by nova-api in the database, and sent every time with the scheduler message would avoid the above problems. The use of the database would guarantee monotonic increase for every update, and also the durability of the value across nova-api restarts. Without durability some notification to nova-scheduler that it needs to reset its expected sequence number would be needed. It would probably make sense to make this sequence number larger in scope than just host aggregation changes so that it can be reused for other future scheduler messages. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1542491 Title: Scheduler update_aggregates race causes incorrect aggregate information To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1542491/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
