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:
https://bugs.launchpad.ne
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
Ewan Mellor wrote:
> Has someone changed Javascript or stylesheets on wiki.openstack.org
> recently? It’s broken in IE now, in a way that it wasn’t yesterday.
Note that the releasestatus page and the rest of the wiki don't have any
stylesheet in common, so that would rather point to a local issue
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 wh
It looks similarly awful for me in IE6. Trying to see what's wrong now
Colin
On 16/02/11 16:28, Thierry Carrez wrote:
> Ewan Mellor wrote:
>> Has someone changed Javascript or stylesheets on wiki.openstack.org
>> recently? It’s broken in IE now, in a way that it wasn’t yesterday.
> Note tha
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 at the top. That doesn't seem to be handled properly, stopping
all the css, js and image files from loading.
Coli
Thanks for feedback Ed. Comments in [] below ...
From: Ed Leafe [e...@leafe.com]
On Feb 16, 2011, at 10:26 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 r
Ah, IE had switched into Compatibility View. It's fine with that turned off.
Sorry for the noise.
Ewan.
> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Colin
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 releasesta
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
On Wed, Feb 16, 2011 at 12:16 PM, Ed Leafe 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 of co
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
Thanks Dragon!
Had another conversation with Jay on this as well. I think the caching with the
smart use of instance/customer naming will go a long way to helping the search.
More comments below ...
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sa
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
On Tue, Feb 15, 2011 at 01:18:46PM -0800, David Strauss wrote:
> Regardless of whether the system uses AMQP, I am a fan of AMQP's
> flexible routing model. Please don't build a service that lacks fanout
> and other non-1:1 distribution patterns. Non-1:1 routing is useful for
> web cache invalidatio
On Wed, Feb 16, 2011 at 2:17 PM, Eric Day wrote:
> 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.)]
>> >
>> >
Hi all,
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, it's you responsibility to do code revie
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 words, getting multiple zones up and running,
> each knowing about thei
On Wed, Feb 16, 2011 at 4:25 PM, Eric Day 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 words, getting m
2011/2/16 Jay Pipes :
> 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, it's you respo
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 seamles
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 cons
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
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 that the action is pe
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 :
> 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 its cache. If
2011/2/16 Sandy Walsh :
>> Hmmm... I am not sure about exposing internal structure to customers in this
>> way. Would you really want the more 'internal' zones exposed?
> To Jay's point, the "control panel" would hide all that switching.
I agree with this. It's an API, not a UI. Doing redirects o
Good points Soren, and this is why I was suggesting we not solve this
problem with a cache, but instead an eventually consistent replication
stream of the aggregate data.
-Eric
On Wed, Feb 16, 2011 at 11:12:50PM +0100, Soren Hansen wrote:
> 2011/2/16 Ed Leafe :
> > This was one of the issues we d
2011/2/16 Eric Day :
> 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 discuss a gossip
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"
Sent: Wednesday, February 16, 2011 5:09pm
To: "Glen Campbell"
Cc: "openstack@lists.launchpad.net"
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
wrote:
> The proposed compute A
On Wed, Feb 16, 2011 at 5:29 PM, Brian Waldon
wrote:
> -Original Message-
> From: "Jay Pipes"
> Sent: Wednesday, February 16, 2011 5:09pm
> To: "Glen Campbell"
> Cc: "openstack@lists.launchpad.net"
> Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
>
> On Wed, Feb 16,
Glen,
I definitely recognize the value in having scheduling capability. I wrote a
high level draft of a REST API for a generic scheduler to be used for batch job
processing. Scheduled events are discussed regularly by users of queue systems
that want certain things to happen on regular interval
On Feb 16, 2011, at 5:12 PM, Soren Hansen wrote:
> * Whenever I ask something for information and I get out-of-date,
> cached data back I feel like I'm back in 2003. And 2003 sucked, I
> might add.
The other side of that coin was the implementation of pub/sub.
New/deleted/changed instanc
On Wed, Feb 16, 2011 at 11:20:31PM +0100, Soren Hansen wrote:
> 2011/2/16 Sandy Walsh :
> >> Hmmm... I am not sure about exposing internal structure to customers in
> >> this
> >> way. Would you really want the more 'internal' zones exposed?
> > To Jay's point, the "control panel" would hide all
On Feb 16, 2011, at 5:11 PM, Michael Mayo wrote:
> I like this idea, but I would suggest going with a unix timestamp in GMT
> instead of /2011/xx/xx/etc.
Whether you use a timestamp or MM... format, *always* use GMT. We
all know how much fun it is when someone in Europe sends a requ
I like idea of scheduling actions overall. The idea of a generic scheduling
service also appeals to me a lot. The question is how do you generalize the
service. I'd love to see your write up.
-jOrGe W.
On Feb 16, 2011, at 4:35 PM, Adrian Otto wrote:
Glen,
I definitely recognize the value
Have we considered pruning and expanding the core team to help speed the
reviews along? There are some people who are no longer day-to-day active
in Nova and some that are that could help in this process.
On 2/16/11 3:54 PM, "Soren Hansen" wrote:
>2011/2/16 Jay Pipes :
>> Lots of coding and bug
Thanks for the feedback Soren.
I agree that caching can be error prone. When I first read your email I started
to panic that we were taking the wrong tack. But, the more I think about it,
it's probably not that bad.
For basic routing operations, I *think* the caching should be fine.
"Do you h
Not sure what the etiquette is for removing someone. Michael Gundlach is still
listed but is no longer participating.
pvo
From: Joshua McKenty mailto:j...@piston.cc>>
Date: Wed, 16 Feb 2011 16:51:56 -0800
To: Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: Soren Hansen mailto:so...@ubuntu.com
These are all great points Jay.
I'd like to re-echo the comment about unit tests. Obviously they aren't
the panacea, but they can protect against some of the dumber errors that
have made their way into trunk. One particular bug stopped one developer
on my team dead in his tracks, and it ended up b
Jay,
Thanks for throwing this out. How would we build this with Hudson? What
would a "standard deploy" of Nova even look like for integration tests?
We've also bounced the idea within our team of not allowing code commits
if the code to test ratio decreases but I'm not sure if that would work
for
One thing we saw in the list and experienced first hand is that your Hudson
server uses a pre-configured environment and ours pulls virtual env every time.
We had failures on trunk that yours missed because of new pip pulled versions.
A fresh run_tests.sh -f needs to work. It is the only guara
Paul Voccio wrote:
> Not sure what the etiquette is for removing someone. Michael Gundlach is
> still listed but is no longer participating.
There is no process proposed/decided for removing someone from a core team.
At this point people that are no longer involved day-to-day with the
project an
Hi Guys,
So The guys over at IRC convinced me that posting that to the mailing list
would be cooler to solve/discuss, so don't let me down :).
Basically i'm working on launching an instance via the openstack API, using
the Bexar release and the python-novatools (the novatools command), The
hyperv
45 matches
Mail list logo
