nent that would receive and make use
of this request.
Toan
- Original Message -
From: "Mike Spreitzer"
To: "OpenStack Development Mailing List (not for usage questions)"
Sent: Wednesday, October 30, 2013 6:34:51 PM
Subject: Re: [openstack-dev] [nova][scheduler]
On Wed, Oct 30, 2013 at 12:18:13AM -0400, Mike Spreitzer wrote:
> David koo wrote on 10/29/2013 05:19:24 AM:
>
> > Would it be possible to provide an alternate link to the doc? The
> > GFW blocks google docs :(.
>
> For those of you behind the GFW, here is the main doc and some it references:
Man
On 29 October 2013 20:18, Mike Spreitzer wrote:
> John Garbutt wrote on 10/29/2013 07:29:19 AM:
>> ...
>
>> 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 ce
Alex Glikson wrote on 10/30/2013 02:26:08 AM:
> Mike Spreitzer wrote on 30/10/2013 06:11:04 AM:
> > Date: 30/10/2013 06:12 AM
> >
> > Alex also wrote:
> > ``I wonder whether it is possible to find an approach that takes
> > into account cross-resource placement considerations (VM-to-VM
> >
ons)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs -
Updated document with an example request payload
Andrew Laski mailto:andrew.la...@rackspace.com>>
wrote on 29/10/2013 11:14:03 PM:
> [...]
> Havi
Mike Spreitzer wrote on 30/10/2013 06:11:04 AM:
> Date: 30/10/2013 06:12 AM
>
> Alex also wrote:
> ``I wonder whether it is possible to find an approach that takes
> into account cross-resource placement considerations (VM-to-VM
> communicating over the application network, or VM-to-volume
>
Following is my reaction to the last few hours of discussion.
Russell Bryant wrote "Nova calling heat to orchestrate Nova seems
fundamentally wrong". I am not totally happy about this either, but would
you be OK with Nova orchestrating Nova? To me, that seems worse ---
duplicating functionali
OpenStack Development Mailing List (not for usage questions)"
,
Date: 29/10/2013 11:46 PM
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and
APIs - Updated document with an example request payload
Thanks Alex, Mike, Andrew,
penstack-dev] [nova][scheduler] Instance Group Model
and APIs - Updated document with an example request payload
Thanks Alex, Mike, Andrew, Russel for your comments. This ongoing API
discussion started in our scheduler meetings, as a first step to tackle in
the Smarter resource placement id
On 10/29/13, 2:26 PM, "Chris Friesen" wrote:
>On 10/29/2013 03:14 PM, Andrew Laski wrote:
>
>>
> > Nova has placement concerns that extend
>> to finding a capable hypervisor for the VM that someone would like to
>> boot, and then just slightly beyond. If there are higher level
>> decisions to b
Thanks Alex, Mike, Andrew, Russel for your comments. This ongoing API
discussion started in our scheduler meetings, as a first step to tackle in the
Smarter resource placement ideas - See the doc for reference -
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edi
Andrew Laski wrote on 29/10/2013 11:14:03 PM:
> [...]
> Having Nova call into Heat is backwards IMO. If there are specific
> pieces of information that Nova can expose, or API capabilities to help
> with orchestration/placement that Heat or some other service would like
> to use then let's loo
On 10/29/2013 03:14 PM, Andrew Laski wrote:
Having Nova call into Heat is backwards IMO.
Agreed.
If there are specific
pieces of information that Nova can expose, or API capabilities to help
with orchestration/placement that Heat or some other service would like
to use then let's look at th
Thanks Khanh for your questions and Mike for adding your inputs. Some more
inline comments.
On 10/29/13, 1:23 PM, "Mike Spreitzer"
mailto:mspre...@us.ibm.com>> wrote:
Khanh-Toan Tran
mailto:khanh-toan.t...@cloudwatt.com>> wrote on
10/29/2013 09:10:00 AM:
> ...
> 1) Member of a group is recur
On 10/29/13 at 04:05pm, Mike Spreitzer wrote:
Alex Glikson wrote on 10/29/2013 03:37:41 AM:
1. I assume that the motivation for rack-level anti-affinity is to
survive a rack failure. Is this indeed the case?
This is a very interesting and important scenario, but I am curious
about your assumpt
On 10/29/2013 04:32 PM, Mike Spreitzer wrote:
> I should clarify my comment about invoking Heat to do the orchestration.
> I think we have a choice between designing a 1-stage API vs a 2-stage
> API. The 2-stage API goes like this: first the client defines the
> top-level group and everything ins
I should clarify my comment about invoking Heat to do the orchestration. I
think we have a choice between designing a 1-stage API vs a 2-stage API.
The 2-stage API goes like this: first the client defines the top-level
group and everything inside it, then the client makes more calls to create
t
John Garbutt wrote on 10/29/2013 07:29:19 AM:
> ...
> 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)
I think Yathi's
Khanh-Toan Tran wrote on 10/29/2013
09:10:00 AM:
> ...
> 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", "reques
Alex Glikson wrote on 10/29/2013 03:37:41 AM:
> 1. I assume that the motivation for rack-level anti-affinity is to
> survive a rack failure. Is this indeed the case?
> This is a very interesting and important scenario, but I am curious
> about your assumptions regarding all the other OpenStack
"Yathiraj Udupi (yudupi)" wrote on 10/29/2013 02:46:30
AM:
> 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 gr
butt"
To: "OpenStack Development Mailing List (not for usage questions)"
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, Yathir
On 29 October 2013 06:46, Yathiraj Udupi (yudupi) 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.
>
Hi Yathi,
>
> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
>
Would it be possible to provide an alternate link to the doc? The GFW blocks
google docs :(.
Thanks.
--
Koo
___
OpenStack-dev mailing list
OpenSt
Nice example.. I think this is certainly a step in the right direction.
However, I am a bit lost when trying to figure out how this kind of API
(which makes perfect sense at the conceptual level) can be implemented.
IMO, when we make the attempt to design the actual implementation that
would be
25 matches
Mail list logo
