Open Stack

On Thu, 2014-05-01 at 20:49 +0800, Jay Lau wrote:
> Jay Pipes and all, I'm planning to merge this topic to
> http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999 after some discussion in this week's Gantt IRC meeting, hope it is OK.

I'll be there :)

Thanks!
-jay

> 
> 
> 2014-05-01 19:56 GMT+08:00 Day, Phil <philip.day at hp.com>:
>         > >
>         > > In the original API there was a way to remove members from
>         the group.
>         > > This didn't make it into the code that was submitted.
>         >
>         > Well, it didn't make it in because it was broken. If you add
>         an instance to a
>         > group after it's running, a migration may need to take place
>         in order to keep
>         > the semantics of the group. That means that for a while the
>         policy will be
>         > being violated, and if we can't migrate the instance
>         somewhere to satisfy the
>         > policy then we need to either drop it back out, or be in
>         violation. Either some
>         > additional states (such as being queued for inclusion in a
>         group, etc) may be
>         > required, or some additional footnotes on what it means to
>         be in a group
>         > might have to be made.
>         >
>         > It was for the above reasons, IIRC, that we decided to leave
>         that bit out since
>         > the semantics and consequences clearly hadn't been fully
>         thought-out.
>         > Obviously they can be addressed, but I fear the result will
>         be ... ugly. I think
>         > there's a definite possibility that leaving out those
>         dynamic functions will look
>         > more desirable than an actual implementation.
>         >
>         
>         If we look at a server group as a general contained or
>         servers, that may have an attribute that expresses scheduling
>         policy, then it doesn't seem to ugly to restrict the
>         conditions on which an add is allowed to only those that don't
>         break the (optional) policy.    Wouldn't even have to go to
>         the scheduler to work this out.
>         
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
> 
> 
> -- 
> Thanks,
> 
> 
> Jay
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev