Hi Yathi, Thank you for yor example. I have some remarks concerning the JSON format:
1) Member of a group is recursive. A member can be group or an instance. In this case there are two different declaration formats for members, as with http-server-group-1 ("name, "policy", "edge") and Http-Server-1 ("name", "request_spec", "type"). Would it be better if group-typed member also have "type" field to better interpret the member? Like policy which has "type" field to declare that's a egde-typed policy or group-typed policy. 2) The "edge" is not clear to me. It seems to me that "edge" is just a place holder for the edge policy. Does it have some particular configuration like group members (e.g. group-typed member is described by its "member","edge" and "policy", while instance-typed member is described by its "request_spec") ? 3) Members & groups have policy declaration nested in them. Why is edge-policy is declared outside of edge's declaration? Anyway, good work. Toan ----- Original Message ----- From: "John Garbutt" <j...@johngarbutt.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Sent: Tuesday, October 29, 2013 12:29:19 PM Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload On 29 October 2013 06:46, Yathiraj Udupi (yudupi) <yud...@cisco.com> wrote: > The Instance Group API document is now updated with a simple example request > payload of a nested group, and some description of how the API > implementation should handle the registration of the components of a nested > instance group. > https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit > > Hope we will have a good API design session at the summit, and also continue > the discussion face-to-face over there. Its looking good, but I was thinking about a slightly different approach: * I would like to see instance groups be used to describe all scheduler hints (including, please run on cell X, or please run on hypervisor Y) * passing old scheduler hints to the API will just create a new instance group to persist the request * ensure live-migrate/migrate never lets you violate the rules in the user hints, at least don't allow it to happen by accident * I was expecting to see hard and soft constraints/hints, like: try keep in same switch, but make sure on separate servers * Would be nice to have admin defined global options, like: "ensure tenant does note have two servers on the same hypervisor" or soft * I expected to see the existing boot server command simply have the addition of a reference to a group, keeping the existing methods of specifying multiple instances * I aggree you can't change a group's spec once you have started some VMs in that group, but you could then simply launch more VMs keeping to the same policy * New task API (see summit session) should help with the reporting if the VM actually could be started or not, and the reason why it was not possible * augment the server details (and group?) with more location information saying where the scheduler actually put things, obfuscated on per tenant basis. So imagine nova, cinder, neutron exposing ordered (arbitrary tagged) location metadata like nova: (("host_id", "foo"), ("switch_group_id": "bar"), ("power_group": "bas")) * the above should help us define the "scope" of a constraint relative to either a nova, cinder or neutron resource. * Consider a constraint that includes constraints about groups, like must be separate to group X, in the scope of the switch, or something like that * Need more thought on constraints between volumes, servers and networks, I don't think edges are the right way to state that, I think it would be better as a cross group constraint, where the scope of the constraint is related to neutron. Anyways, just a few thoughts I was having. Does that fit in with what you were thinking? John _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev