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
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
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
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
11 matches
Mail list logo
