Just wanted to drop a quick note to say that I decided to leave Rackspace to
pursue another opportunity. My last day was last Friday. I won’t have much time
for OpenStack, but I’m going to continue to hang out in the channels. Having
been involved in the project since day 1, I’m going
Thnx, everyone, for the nice comments. Replies to Dan below:
On Oct 22, 2014, at 10:52 AM, Dan Smith d...@danplanet.com wrote:
I won’t have much time for OpenStack, but I’m going to continue to
hang out in the channels.
Nope, sorry, veto.
I'm the only Core in this project, so I'm sorry:
On Jul 30, 2014, at 2:02 PM, Michael Still mi...@stillhq.com wrote:
I would like to nominate Jay Pipes for the nova-core team.
Jay has been involved with nova for a long time now. He's previously
been a nova core, as well as a glance core (and PTL). He's been around
On Jul 14, 2014, at 10:44 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
Today we only gate on exercises in devstack for cells testing coverage in the
The cells tempest non-voting job was moving to the experimental queue here
 since it doesn't work
On Jul 7, 2014, at 11:11 AM, Angus Salkeld angus.salk...@rackspace.com wrote:
-BEGIN PGP SIGNED MESSAGE-
On 03/07/14 05:30, Mark McLoughlin wrote:
This is an attempt to summarize a really useful discussion that Victor,
Flavio and I have been having today. At the
I don't think we should be flipping states for instances on a potentially
downed compute. We definitely should not set an instance to ERROR. I think a
time associated with the last power state check might be nice and be good
On Jun 24, 2014, at 5:17 PM, Joe Gordon
On Jun 13, 2014, at 3:40 PM, Michael Still mi...@stillhq.com wrote:
I would like to nominate Ken'ichi Ohmichi for the nova-core team.
Ken'ichi has been involved with nova for a long time now. His reviews
on API changes are excellent, and he's been part of the team that
On Apr 25, 2014, at 2:15 PM, Jay Pipes jaypi...@gmail.com wrote:
When recently digging in to the new server group v3 API extension
introduced in Icehouse, I was struck with a bit of cognitive dissonance
that I can't seem to shake. While I understand and support the idea
On Apr 23, 2014, at 6:36 PM, Sam Morrison sorri...@gmail.com wrote:
Yeah I’m not sure what’s going on, I removed my hacks and tried it using the
conductor rpcapi service and got what I think is a recursive call in
Added more details to
On Apr 24, 2014, at 6:10 AM, Sam Morrison sorri...@gmail.com wrote:
Hmm I may have but I’ve just done another test with everything set to
use_local=False except nova-conductor where use_local=True
I also reverted that change I put though as mentioned above and I still get
an infinite loop.
Fwiw, we've seen this with nova-scheduler as well. I think the default pool
size is too large in general. The problem that I've seen stems from the fact
that DB calls all block and you can easily get a stack of 64 workers all
waiting to do DB calls. And it happens to work out such that none of
On Apr 19, 2014, at 11:08 PM, Sam Morrison sorri...@gmail.com wrote:
Thanks for the info Chris, I’ve actually managed to get things working.
Haven’t tested everything fully but seems to be working pretty good.
On 19 Apr 2014, at 7:26 am, Chris Behrens cbehr...@codestud.com wrote
On Apr 17, 2014, at 12:27 PM, Russell Haering russellhaer...@gmail.com
We're spending too much time discussing features after they're implemented,
which makes contribution more difficult for everyone. Forcing an explicit
design+review process, using the
I’m going to try to not lose my cool here, but I’m extremely upset by this.
In December, oslo apparently removed the code for ‘use_tpool’ which allows you
to run DB calls in Threads because it was ‘eventlet specific’. I noticed this
when a review was posted to nova to add the option within
-standard patches that require XYZ config in openstack shouldn't be
part of the standard openstack, no matter the company. If patch A is in the
mainline kernel (or other mainline library), then sure it's fair game.
From: Chris Behrens cbehr...@codestud.com
Reply-To: OpenStack Development
On Apr 13, 2014, at 9:58 PM, Michael Still mi...@stillhq.com wrote:
First off, thanks for electing me as the Nova PTL for Juno. I find the
First off, congrats!
* a mid cycle meetup. I think the Icehouse meetup was a great success,
and I'd like to see us do this again in Juno. I'd also like
On Apr 9, 2014, at 12:50 PM, Dan Smith d...@danplanet.com wrote:
So I'm a soft -1 on dropping it from hacking.
from testtools import matchers
Or = matchers.Or
LessThan = matchers.LessThan
This is the right way to do it, IMHO, if you have something like
On Mar 24, 2014, at 12:31 PM, Tim Bell tim.b...@cern.ch wrote:
How does this interact with cells ? Can the cell API instances be upgraded
independently of the cells themselves ?
My ideal use case would be
- It would be possible to upgrade one of the cells (such as a QA environment)
Do you have some sort of network device like a firewall between your compute
and rabbit or you failed from one rabbit over to another? The only cases where
I've seen this happen is when the compute side OS doesn't detect a closed
connection for various reasons. I'm on my phone and didn't check
I'd like to get spawn broken up sooner rather than later, personally. It has
additional benefits of being able to do better orchestration of builds from
On Mar 14, 2014, at 3:58 PM, Dan Smith d...@danplanet.com wrote:
Just to answer this point, despite the review latency,
FWIW, I’m fine with any of the options posted. But I’m curious about the
precedence that reverting would create. It essentially sounds like if we
release a version with an API bug, the bug is no longer a bug in the API and
the bug becomes a bug in the documentation. The only way to ‘fix' the
On Mar 18, 2014, at 11:57 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
Not to detract from what you're saying, but this is 'meh' to me. My company
has some different kind of values thing every 6 months it seems and maybe
it's just me but I never really pay attention to any of
On Mar 16, 2014, at 7:58 PM, Michael Still mi...@stillhq.com wrote:
So I've written a blueprint for nova for Juno, and uploaded it to
nova-specs (https://review.openstack.org/#/c/80865/). That got me
thinking about what this process might look like, and this is what I
came up with:
On Mar 6, 2014, at 11:09 AM, Russell Bryant rbry...@redhat.com wrote:
I think a dedicated git repo for this makes sense.
openstack/nova-blueprints or something, or openstack/nova-proposals if
we want to be a bit less tied to launchpad terminology.
+1 to this whole idea.. and we definitely
On Mar 4, 2014, at 4:09 AM, Sean Dague s...@dague.net wrote:
On 03/04/2014 01:14 AM, Chris Behrens wrote:
I don’t think I have an answer, but I’m going to throw out some of my random
thoughts about extensions in general. They might influence a longer term
decision. But I’m also
On Mar 4, 2014, at 11:14 AM, Sean Dague s...@dague.net wrote:
I want to give the knobs to the users. If we thought it was important
enough to review and test in Nova, then we made a judgement call that
people should have access to it.
Oh, I see. But, I don’t agree, certainly not for every
On Mar 3, 2014, at 9:23 PM, Joe Gordon joe.gord...@gmail.com wrote:
here's a case worth exploring in a v2 only world ... what about some
extension we really think is dead and should go away? can we ever
remove it? In the past we have said backwards compatibility means no
This thread is many messages deep now and I’m busy with a conference this week,
but I wanted to carry over my opinion from the other “v3 API in Icehouse”
thread and add a little to it.
Bumping versions is painful. v2 is going to need to live for “a long time” to
create the least amount of
Again, just another quick response, but if we can find a way to merge v2 into
the current v3 code, so that we don't have dual maintenance, that would be
On Feb 26, 2014, at 5:15 PM, Christopher Yeoh cbky...@gmail.com wrote:
On Wed, 26 Feb 2014 16:04:38 -0600
+1. I'd like to leave it experimental as well. I think the task work is
important to the future of nova-api and I'd like to make sure we're not rushing
anything. We're going to need to live with old API versions for a long time, so
it's important that we get it right. I'm also not convinced
On Jan 28, 2014, at 12:45 PM, Stefano Maffulli stef...@openstack.org wrote:
A few minutes ago we sent the first batch of invites to people who
contributed to any of the official OpenStack programs from 00:00 UTC
on April 4, 2014 (Grizzly release day) until present.
Something tells me that
On Feb 7, 2014, at 8:21 AM, Jesse Noller jesse.nol...@rackspace.com wrote:
It seems that baking concurrency models into the individual clients /
services adds some opinionated choices that may not scale, or fit the needs
of a large-scale deployment. This is one of the things looking at the
I want to address some of Chuck’s post, but I think we should come up with a
list of requirements. Replies to Chuck inline, and then some requirements below:
On Feb 7, 2014, at 8:38 AM, Chuck Thier cth...@gmail.com wrote:
Concurrency is hard, let's blame the tools!
Any lib that we use in
On Feb 7, 2014, at 2:59 PM, Victor Stinner victor.stin...@enovance.com wrote:
I don't see why external libraries should be modified. Only the few libraries
sending HTTP queries and requests to the database should handle asyncio.
example: the iso8601 module used to parse time doesn't
On Feb 6, 2014, at 11:07 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
To give an example as to why eventlet implicit monkey patch the world isn't
especially great (although it's what we are currently using throughout
The way I think about how it works is to think
I’m jumping in slightly late on this, but I also have an interest in this. I’m
going to preface this by saying that I have not read this whole thread yet, so
I apologize if I repeat things, say anything that is addressed by previous
posts, or doesn’t jive with what you’re looking
On Jan 30, 2014, at 5:55 AM, Andrew Laski andrew.la...@rackspace.com wrote:
I'm of the opinion that the scheduler should use objects, for all the reasons
that Nova uses objects, but that they should not be Nova objects. Ultimately
what the scheduler needs is a concept of capacity,
organization takes seconds.
3) You can have a huge cost savings on hardware as it is all shared.
and so forth.
And yes, this exact same model is what Service Providers should want if they
intend to Resell/Co-brand, etc.
From: Chris Behrens
On Feb 5, 2014, at 3:38 AM, Vishvananda Ishaya vishvana...@gmail.com wrote:
On Feb 5, 2014, at 12:27 AM, Chris Behrens cbehr...@codestud.com wrote:
1) domain ‘a’ cannot see instances (or resources in general) in domain ‘b’.
It doesn’t matter if domain ‘a’ and domain ‘b’ share the same
Interesting thread. I have been working on a side project that is a
gevent/eventlet replacement  that focuses on thread-safety and performance.
This came about because of an outstanding bug we have with eventlet not being
Thread safe. (We cannot safely enable thread pooling for DB calls
I’d be interested in this. While I have not provided any contributions to
Ironic thus far, I’m beginning to look at it for some things. I am local to
the bay area, so Sunnyvale is a convenient location for me as well. :)
On Jan 24, 2014, at 5:30 PM, Devananda van der Veen
On Dec 9, 2013, at 2:58 PM, Sam Morrison sorri...@gmail.com wrote:
I’m trying to fix up some cells issues related to objects. Do all compute api
methods take objects now?
cells is still sending DB objects for most methods (except start and stop)
and I know there are more than that.
On Nov 26, 2013, at 11:32 AM, Russell Bryant rbry...@redhat.com wrote:
I would like to propose that we re-add Dan Prince to the nova-core
Dan Prince has been involved with Nova since early in OpenStack's
history (Bexar timeframe). He was a member of the
On Oct 25, 2013, at 3:46 AM, Day, Phil email@example.com wrote:
We're very occasionally seeing problems where a thread processing a create
hangs (and we've seen when taking to Cinder and Glance). Whilst those issues
need to be hunted down in their own rights, they do show up
I may have put that in the wrong spot. Oops.
On Oct 18, 2013, at 11:11 PM, Akihiro Motoki amot...@gmail.com wrote:
Hi Thierry, John,
In Havana release notes, Swift known issues section is talking about
Nova Cells issue. Could you confirm?
Ah, I know what happened. This is corrected now.
On Oct 19, 2013, at 12:27 AM, Chris Behrens cbehr...@codestud.com wrote:
I may have put that in the wrong spot. Oops.
On Oct 18, 2013, at 11:11 PM, Akihiro Motoki amot...@gmail.com wrote:
Hi Thierry, John,
In Havana release
I'd like to announce my candidacy for a seat on the OpenStack
- General background -
I have over 15 years of experience designing and building distributed
systems. I am currently a Principal Engineer at Rackspace, where
I have been for a little over 3 years now.
On Aug 20, 2013, at 12:51 PM, Ed Leafe e...@openstack.org wrote:
On Aug 20, 2013, at 2:33 PM, Chris Behrens cbehr...@codestud.com
For instances table, we want to make sure 'uuid' is unique. But we can't
put a unique constraint on that alone. If that instance gets deleted.. we
On Aug 20, 2013, at 1:05 PM, Jay Pipes jaypi...@gmail.com wrote:
I see the following use case:
1) Create something with a unique name within your tenant
2) Delete that
3) Create something with the same unique name immediately after
As a pointless and silly use case that we should not
On Aug 20, 2013, at 3:29 PM, Vishvananda Ishaya vishvana...@gmail.com wrote:
c) is going ot take a while. There are still quite a few places in nova,
for example, that depend on accessing deleted records.
Do you have a list of these places?
No. I believe Joe Gordon did an initial look
, Andrew Laski andrew.la...@rackspace.com wrote:
I will also be working to help get cells passing tests. I just setup a
blueprint on the Nova side for this,
On 07/13/13 at 05:00pm, Chris Behrens wrote:
I can make a commitment to help
I can make a commitment to help getting cells passing. Basically, I'd like to
do whatever I can to make sure we can have a useful gate on cells.
Unfortunately I'm going to be mostly offline for the next 10 days or so,
I thought there was a sec group patch up for cells, but I've
On Jul 13, 2013, at 8:28 AM, Sean Dague s...@dague.net wrote:
Like I said, as long as someone is going to work on it, I'm happy. :) I just
don't want this to be an enable the tests and hope magically fairies come to
fix them issue. That's what we did on full neutron tests, and it's been
On Jul 11, 2013, at 8:28 AM, John Griffith john.griff...@solidfire.com wrote:
On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith d...@danplanet.com wrote:
In the corner to my left, our current largest gate reset culprit
appears to be neutron bug #1194026 - weighing in with 62 rechecks
On Jun 26, 2013, at 10:09 AM, Russell Bryant rbry...@redhat.com wrote:
I would like to nominate John Garbutt for the nova-core team.
John has been involved with nova for a long time now. He's primarily
known for his great work on the xenapi driver. However, he has been
On Jun 21, 2013, at 9:16 AM, Armando Migliaccio amigliac...@vmware.com wrote:
In my view a cell should only know about the queue it's connected to, and let
the 'global' message queue to do its job of dispatching the messages to the
right recipient: that would solve the problem altogether.
On Jun 17, 2013, at 7:49 AM, Russell Bryant rbry...@redhat.com wrote:
On 06/16/2013 11:25 PM, Dugger, Donald D wrote:
Looking into the scheduler a bit there's an issue of duplicated effort that
is a little puzzling. The database table `compute_nodes' is being updated
Mail list logo