Open Stack

On Apr 25, 2014, at 2:25 PM, Chris Behrens <cbehrens at codestud.com> wrote:

> 
> On Apr 25, 2014, at 2:15 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
>> Hi Stackers,
>> 
>> When recently digging in to the new server group v3 API extension
>> introduced in Icehouse, I was struck with a bit of cognitive dissonance
>> that I can't seem to shake. While I understand and support the idea
>> behind the feature (affinity and anti-affinity scheduling hints), I
>> can't help but feel the implementation is half-baked and results in a
>> very awkward user experience.
> 
> I agree with all you said about this.
> 
>> Proposal
>> --------
>> 
>> I propose to scrap the server groups API entirely and replace it with a
>> simpler way to accomplish the same basic thing.
>> 
>> Create two new options to nova boot:
>> 
>> --near-tag <TAG>
>> and
>> --not-near-tag <TAG>
>> 
>> The first would tell the scheduler to place the new VM near other VMs
>> having a particular "tag". The latter would tell the scheduler to place
>> the new VM *not* near other VMs with a particular tag.
>> 
>> What is a "tag"? Well, currently, since the Compute API doesn't have a
>> concept of a single string tag, the tag could be a key=value pair that
>> would be matched against the server extra properties.
> 
> You can actually already achieve this behavior… although with a little more work. There’s the Affinty filter which allows you to specify a same_host/different_host scheduler hint where you explicitly specify the instance uuids you want…  (the extra work is having to know the instance uuids).

It was my understanding from previous discussions that having the concept of a group was necessary for future schediuling decisions, especially involving live migration. The uuids you need to be far from at launch time won’t necessarily be the ones you need to be far from when a migration is performed. Server groups handle this case, although Jay’s proposal of near/far from tag would also solve this as long as the near-to/far-from data was saved in the instance record. My only concern here is removing an api we just added, so a smoother transition would be preferable.

Vish

> 
> But yeah, I think this makes more sense to me.
> 
> - Chris
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140426/78bf218d/attachment.pgp>