Open Stack

I think server group is an important feature especially when working with
heat auto scaling group, there is already some discussion for this
http://markmail.org/message/jl5wlx3nr3g53ko5

The current server group feature does support add/delete a VM instance
to/from the server group but seems not able to manage existing VM
instances, but this can be enhanced.

The server group feature need two steps to create the VM instance:
1) Create a server group with policy
2) Create VMs for the server group

What Jay Pipes proposed is using resource tags directly:
1) Create VMs with a resource tag to specify the policy.

I think that those two directions are very similar, but what Jay Pipes
proposed does not specify the resource group and seems the resource group
was implicitly specified in resource tag.

Just some of my understanding. Thanks!



2014-04-27 1:25 GMT+08:00 Vishvananda Ishaya <vishvananda at gmail.com>:

>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140427/1c8ffda6/attachment.html>