On Nov 3, 2015, at 11:46 PM, John Griffith
> wrote:
On Tue, Nov 3, 2015 at 4:57 PM, michael mccune
> wrote:
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
What if we add new API method that will
John,
> Our resources are not. We've also had specific requests to prevent
> > header bloat because it impacts the HTTP caching systems. Also, it's
> > pretty clear that headers are really not where you want to put volatile
> > information, which this is.
> Hmm, you do make a good point about
Sean,
This seems like a fundamental abuse of HTTP honestly. If you find
> yourself creating a ton of new headers, you are probably doing it wrong.
I totally agree on this. We shouldn't add a lot of HTTP headers. Imho why
not just return in body string with status (in my case).
> I think
Robert,
I don't have the exactly numbers, but during the real testing of real
deployments I saw the impact of polling resource, this is one of the reason
why we have to add quite big sleep() during polling in Rally to reduce
amount of GET requests and avoid DDoS of OpenStack..
In any case it
On 5 November 2015 at 13:06, Boris Pavlovic wrote:
> Robert,
>
> I don't have the exactly numbers, but during the real testing of real
> deployments I saw the impact of polling resource, this is one of the reason
> why we have to add quite big sleep() during polling in Rally to
On 5 November 2015 at 04:42, Sean Dague wrote:
> On 11/04/2015 10:13 AM, John Garbutt wrote:
> I think longer term we probably need a dedicated event service in
> OpenStack. A few of us actually had an informal conversation about this
> during the Nova notifications session to
On 11/04/2015 09:00 AM, Jay Pipes wrote:
> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
>> Hi stackers,
>>
>> Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
>> that works with OpenStack are working with resources (e.g. VM, Volumes,
>> Images, ..) in the next way:
>>
>>
On 4 November 2015 at 14:49, Jay Pipes wrote:
> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>
>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>>
>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally,
On 11/04/2015 09:32 AM, Sean Dague wrote:
On 11/04/2015 09:00 AM, Jay Pipes wrote:
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
that works with OpenStack are working with resources (e.g. VM, Volumes,
Images,
On 11/04/2015 09:49 AM, Jay Pipes wrote:
> On 11/04/2015 09:32 AM, Sean Dague wrote:
>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
that works
On 4 November 2015 at 15:00, Sean Dague wrote:
> On 11/04/2015 09:49 AM, Jay Pipes wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
> Hi stackers,
>
> Usually such
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
that works with OpenStack are working with resources (e.g. VM, Volumes,
Images, ..) in the next way:
>>> resource = api.resouce_do_some_stuff()
>>> while
On 11/04/2015 10:13 AM, John Garbutt wrote:
> On 4 November 2015 at 14:49, Jay Pipes wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>>
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
>
> Hi stackers,
>
apologies, if the below was mentioned at some point in this thread.
On 04/11/2015 10:42 AM, Sean Dague wrote:
This seems like a fundamental abuse of HTTP honestly. If you find
yourself creating a ton of new headers, you are probably doing it wrong.
if we want to explore the HTTP path, did we
On 11/03/2015 11:45 PM, John Griffith wrote:
On Tue, Nov 3, 2015 at 3:20 PM, Boris Pavlovic > wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool that
works with OpenStack are working with
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
that works with OpenStack are working with resources (e.g. VM, Volumes,
Images, ..) in the next way:
>>> resource = api.resouce_do_some_stuff()
>>> while api.resource_get(resource["uuid"]) != expected_status
>>>
On Nov 3, 2015 4:29 PM, "Clint Byrum" wrote:
>
> Excerpts from Boris Pavlovic's message of 2015-11-03 14:20:10 -0800:
> > Hi stackers,
> >
> > Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
> > that works with OpenStack are working with resources (e.g.
Clint, Morgan,
I totally agree that the pub/sub model is better approach.
However, there are 2 great things about polling:
1) it's simpler to use than pub/sub (especially in shell)
2) it has really simple implementation & we can get this in OpenStack in
few days/weeks
What about just supporting
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
What if we add new API method that will just resturn resource status by
UUID? Or even just extend get request with the new argument that returns
only status?
Thoughts?
not sure i understand the resource status by UUID, could you explain
that a
Excerpts from Boris Pavlovic's message of 2015-11-03 14:20:10 -0800:
> Hi stackers,
>
> Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
> that works with OpenStack are working with resources (e.g. VM, Volumes,
> Images, ..) in the next way:
>
> >>> resource =
On Tue, Nov 3, 2015 at 3:20 PM, Boris Pavlovic wrote:
> Hi stackers,
>
> Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
> that works with OpenStack are working with resources (e.g. VM, Volumes,
> Images, ..) in the next way:
>
> >>> resource =
On Tue, Nov 3, 2015 at 4:57 PM, michael mccune wrote:
> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
>
>> What if we add new API method that will just resturn resource status by
>> UUID? Or even just extend get request with the new argument that returns
>> only status?
>>
>>
John,
The main point here is to reduce amount of data that we request from DB and
that is process by API services and sent via network
and make SQL requests simpler (remove joins from SELECT).
So like if you fetch 10 bytes instead of 1000 bytes you will process 100
times less and it will scale
Excerpts from Boris Pavlovic's message of 2015-11-03 17:32:43 -0800:
> Clint, Morgan,
>
> I totally agree that the pub/sub model is better approach.
>
> However, there are 2 great things about polling:
> 1) it's simpler to use than pub/sub (especially in shell)
I envision something like this:
Excerpts from John Griffith's message of 2015-11-03 21:45:12 -0800:
> On Tue, Nov 3, 2015 at 3:20 PM, Boris Pavlovic wrote:
>
> > Hi stackers,
> >
> > Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
> > that works with OpenStack are working with
25 matches
Mail list logo