Hello everyone,
At yesterday's meeting we considered additional fixes for inclusion into
the Bexar point release we have to do to care about the missing files
and translations in the Bexar release tarball.
We ended up targeting 3 additional fixes, see complete list here:
Hi y'all
Like they say The devil is in the details. I'm at the stage where the parent
zones will talk to the child zones and there are some interesting
implementation issues:
Problem 1. I'd like to pass the incoming HTTP Request object along to the
Scheduler so I don't have to remarshall the
On Feb 16, 2011, at 10:26 AM, Sandy Walsh wrote:
But this introduces a problem. Consider this use-case:
a. I issue a create-instance via the top-level API in zone-A
b. the request is relayed down to zone-C
c. the instance is created some time later
Q1. How does the user learn what the
Not sure about StartingPage - it's not all that bad, and could easily
just be IE6, haven't ever looked at it in IE6 before.
As for the releasestatus page, I'd point my finger at the base
href=. at the top. That doesn't seem to be handled properly, stopping
all the css, js and image files from
Out of curiosity -- are we *really* concerned about IE6?
On Wed, Feb 16, 2011 at 10:54 AM, Colin Nicholson
colin.nichol...@iomart.com wrote:
Not sure about StartingPage - it's not all that bad, and could easily
just be IE6, haven't ever looked at it in IE6 before.
As for the releasestatus
On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:
Thanks for feedback Ed. Comments in [] below ...
Yeesh - that makes for ugly quoting. :) Let me try to reformat the
quoting.
Isn't the instance name usually supplied by the user/originator?
[Sorry, yes the instance name is
On Wed, Feb 16, 2011 at 12:16 PM, Ed Leafe e...@leafe.com wrote:
On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:
Isn't the instance name usually supplied by the user/originator?
[Sorry, yes the instance name is passed in on the request, but the instance
ID is what's needed (assuming
On 2/16/11 9:26 AM, Sandy Walsh wrote:
Hi y'all
Like they say The devil is in the details. I'm at the stage where
the parent zones will talk to the child zones and there are some
interesting implementation issues:
*Problem 1.* I'd like to pass the incoming HTTP Request object along
to the
Hi Sandy,
On Wed, Feb 16, 2011 at 06:19:52PM +, Sandy Walsh wrote:
Hmm. You wouldn't really need to re-marshall the request. Just
copy the needed headers url, and pass along the body as you received
it. Basically you are just
acting as a sort of http proxy.
On Wed, Feb 16, 2011 at 01:02:22PM -0500, Jay Pipes wrote:
[Sorry, yes the instance name is passed in on the request, but the
instance ID is what's needed (assuming of course instance ID is unique
across zones.)]
The ID is determined early in the process; well before the request
On Wed, Feb 16, 2011 at 4:25 PM, Eric Day e...@oddments.org wrote:
On Wed, Feb 16, 2011 at 03:59:10PM -0500, Jay Pipes wrote:
But, as I mentioned to Sandy on IRC, caching and performance should be
a secondary concern. The primary concern, right now, is just making
this all work. In other
2011/2/16 Jay Pipes jaypi...@gmail.com:
Lots of coding and bug fixing has been done in the past weeks. As a
result, we've got a big backlog of code reviews to do.
If you have some cycles, please do participate:
https://code.launchpad.net/nova/+activereviews
Nova-core members, remember,
On Wed, Feb 16, 2011 at 04:33:06PM -0500, Jay Pipes wrote:
While I would agree with this most of the time, there are some cases
where optimizing later just doesn't work. Or, optimizing means
rewriting everything you've done and replacing it with something
that will scale seamlessly. I've
The proposed compute API 1.1 has a specification for server actions (Sec. 4.4)
with the endpoint:
/servers/{id}/action
The actual action is specified as the body of the POST request, and the
implication is that the action is performed immediately, or as soon as possible.
I'd like us to
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
glen.campb...@rackspace.com wrote:
The proposed compute API 1.1 has a specification for server actions (Sec.
4.4) with the endpoint:
/servers/{id}/action
The actual action is specified as the body of the POST request, and the
implication is
I like this idea, but I would suggest going with a unix timestamp in GMT
instead of /2011/xx/xx/etc.
Also, how would this effect error handling? It seems like you'd basically need
to have some sort of way to query all the server actions you've ever done
before with their HTTP responses.
On
2011/2/16 Ed Leafe e...@leafe.com:
This was one of the issues we discussed during the sprint planning. I believe
(check with cyn) that the consensus was to use a caching strategy akin to
DNS: e.g., if zone A got a request for instance ID=12345, it would check to
see if it had id 12345 in
2011/2/16 Eric Day e...@oddments.org:
This doesn't help the 'list all instances' search. This would be
very expensive when dealing with a large number of accounts and
instances. We need a more active caching policy, which ends up being
more of a replication subset than a cache.
Did we ever
Hey all,
It's come to my attention that a number of folks are not happy that
Nova's trunk branch (lp:nova) is, shall we say, less than stable. :)
First, before going into some suggestions on keeping trunk more
stable, I'd like to point out that trunk is, by nature, an actively
developed source
-Original Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Wednesday, February 16, 2011 5:09pm
To: Glen Campbell glen.campb...@rackspace.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
On Wed,
Not sure what the etiquette is for removing someone. Michael Gundlach is still
listed but is no longer participating.
pvo
From: Joshua McKenty j...@piston.ccmailto:j...@piston.cc
Date: Wed, 16 Feb 2011 16:51:56 -0800
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc:
Just for summary, the advantages of having the streaming inside a domU are:
1. You move the network receive and the image decompression / decryption
(if you're using that) off dom0's CPU and onto the domU's. Dom0 CPU is a
scarce resource, even in the new release of XenServer with 4 CPUs
I'm actually not too worried about option B. We've been using this method
in production for a while and haven't ran into too many problems. We've
heavily tested four streams (builds) at a time with 2 VCPUs in dom0 and it
works pretty well. We did see major starvation issues with dom0 when we
23 matches
Mail list logo
