Re: [openstack-dev] Server groups specified by name
On 07/07/2014 02:29 PM, Joe Gordon wrote: On Jul 7, 2014 3:47 PM, Chris Friesen wrote: On 07/07/2014 12:35 PM, Day, Phil wrote: I’m thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy” – and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Sorry, forgot to put this in my previous message. I've been advocating the ability to use names instead of UUIDs for server groups pretty much since I saw them last year. I'd like to just enforce that server group names must be unique within a tenant, and then allow names to be used anywhere we currently have UUIDs (the way we currently do for instances). If there is ambiguity (like from admin doing an operation where there are multiple groups with the same name in different tenants) then we can have it fail with an appropriate error message. The question here is not just about server group names, but all names. Having one name be unique and not another (instance names), is a recipe for a poor user experience. Unless there is a strong reason why our current model is bad ( non unique names), I don't think this type of change is worth the impact on users. Maybe I'm misunderstanding Phil's suggestion, but the phrase '...group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy”...' sounds like he is *only* supporting specifying group by name for legacy policy. That is what I'm objecting against...I want to be able to specify a group by name for all scheduling policies. I'm perfectly happy to have a command fail with a server group name is ambiguous error if the name matches more than one group in the user's namespace. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Server groups specified by name
Hi Folks, I noticed a couple of changes that have just merged to allow the server group hints to be specified by name (some legacy behavior around automatically creating groups). https://review.openstack.org/#/c/83589/ https://review.openstack.org/#/c/86582/ But group names aren't constrained to be unique, and the method called to get the group instance_group_obj.InstanceGroup.get_by_name() will just return the first group I finds with that name (which could be either the legacy group or some new group, in which case the behavior is going to be different from the legacy behavior I think ? I'm thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn't legacy - and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Thoughts ? (Sorry I missed this on the reviews) Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Server groups specified by name
On 07/07/2014 02:35 PM, Day, Phil wrote: Hi Folks, I noticed a couple of changes that have just merged to allow the server group hints to be specified by name (some legacy behavior around automatically creating groups). https://review.openstack.org/#/c/83589/ https://review.openstack.org/#/c/86582/ But group names aren’t constrained to be unique, and the method called to get the group instance_group_obj.InstanceGroup.get_by_name() will just return the first group I finds with that name (which could be either the legacy group or some new group, in which case the behavior is going to be different from the legacy behavior I think ? I’m thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy” – and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Sounds like a reasonable set of improvements to me. Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Server groups specified by name
On 07/07/2014 12:35 PM, Day, Phil wrote: Hi Folks, I noticed a couple of changes that have just merged to allow the server group hints to be specified by name (some legacy behavior around automatically creating groups). https://review.openstack.org/#/c/83589/ https://review.openstack.org/#/c/86582/ But group names aren’t constrained to be unique, and the method called to get the group instance_group_obj.InstanceGroup.get_by_name() will just return the first group I finds with that name (which could be either the legacy group or some new group, in which case the behavior is going to be different from the legacy behavior I think ? I’m thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy” – and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Thoughts ? What about constraining the group names to be unique? (At least within a given tenant.) Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Server groups specified by name
On 07/07/2014 12:35 PM, Day, Phil wrote: Hi Folks, I noticed a couple of changes that have just merged to allow the server group hints to be specified by name (some legacy behavior around automatically creating groups). https://review.openstack.org/#/c/83589/ https://review.openstack.org/#/c/86582/ But group names aren’t constrained to be unique, and the method called to get the group instance_group_obj.InstanceGroup.get_by_name() will just return the first group I finds with that name (which could be either the legacy group or some new group, in which case the behavior is going to be different from the legacy behavior I think ? I’m thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy” – and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Sorry, forgot to put this in my previous message. I've been advocating the ability to use names instead of UUIDs for server groups pretty much since I saw them last year. I'd like to just enforce that server group names must be unique within a tenant, and then allow names to be used anywhere we currently have UUIDs (the way we currently do for instances). If there is ambiguity (like from admin doing an operation where there are multiple groups with the same name in different tenants) then we can have it fail with an appropriate error message. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Server groups specified by name
On Jul 7, 2014 3:47 PM, Chris Friesen chris.frie...@windriver.com wrote: On 07/07/2014 12:35 PM, Day, Phil wrote: Hi Folks, I noticed a couple of changes that have just merged to allow the server group hints to be specified by name (some legacy behavior around automatically creating groups). https://review.openstack.org/#/c/83589/ https://review.openstack.org/#/c/86582/ But group names aren’t constrained to be unique, and the method called to get the group instance_group_obj.InstanceGroup.get_by_name() will just return the first group I finds with that name (which could be either the legacy group or some new group, in which case the behavior is going to be different from the legacy behavior I think ? I’m thinking that there may need to be some additional logic here, so that group hints passed by name will fail if there is an existing group with a policy that isn’t “legacy” – and equally perhaps group creation needs to fail if a legacy groups exists with the same name ? Sorry, forgot to put this in my previous message. I've been advocating the ability to use names instead of UUIDs for server groups pretty much since I saw them last year. I'd like to just enforce that server group names must be unique within a tenant, and then allow names to be used anywhere we currently have UUIDs (the way we currently do for instances). If there is ambiguity (like from admin doing an operation where there are multiple groups with the same name in different tenants) then we can have it fail with an appropriate error message. The question here is not just about server group names, but all names. Having one name be unique and not another (instance names), is a recipe for a poor user experience. Unless there is a strong reason why our current model is bad ( non unique names), I don't think this type of change is worth the impact on users. Chris ___ 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
