+1
> On Nov 22, 2013, at 12:53 PM, Russell Bryant wrote:
>
> Greetings,
>
> I would like to propose adding Matt Riedemann to the nova-core review team.
>
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks. He writes good code. He's very engaged with the dev
+1
On Nov 26, 2013, at 11:32 AM, Russell Bryant wrote:
> Greetings,
>
> I would like to propose that we re-add Dan Prince to the nova-core
> review team.
>
> Dan Prince has been involved with Nova since early in OpenStack's
> history (Bexar timeframe). He was a member of the nova-core review
On Dec 9, 2013, at 2:58 PM, Sam Morrison wrote:
> Hi,
>
> 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.
>
> Eg. I kno
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. :)
- Chris
On Jan 24, 2014, at 5:30 PM, Devananda van der Veen
wrote:
>
Hi,
Interesting thread. I have been working on a side project that is a
gevent/eventlet replacement [1] 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
Hi Vish,
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 for.
On Jan 30, 2014, at 5:55 AM, Andrew Laski 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, allocations, and locality
> of
'x' groups maintaining 'y' platforms. This results in saving
time and saving money on people.
2) Creating a new cloud for a new 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 S
On Feb 5, 2014, at 3:38 AM, Vishvananda Ishaya wrote:
>
> On Feb 5, 2014, at 12:27 AM, Chris Behrens 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 tenant ID. If
On Feb 6, 2014, at 11:07 PM, Joshua Harlow wrote:
> +1
>
> 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
> openstack).
>
> The way I think about how it works is to think about what librarie
On Feb 7, 2014, at 8:21 AM, Jesse Noller 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 client
> tools I’ve not
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 wrote:
> Concurrency is hard, let's blame the tools!
>
> Any lib that we use in python is going
On Feb 7, 2014, at 2:59 PM, Victor Stinner 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.
> Dummy
> example: the iso8601 module used to parse time doesn't need to be aware of
>
+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 ther
On Jan 28, 2014, at 12:45 PM, Stefano Maffulli wrote:
> A few minutes ago we sent the first batch of invites to people who
> contributed to any of the official OpenStack programs[1] from 00:00 UTC
> on April 4, 2014 (Grizzly release day) until present.
Something tells me that this date is not c
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 pain
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
really nice.
> On Feb 26, 2014, at 5:15 PM, Christopher Yeoh wrote:
>
> On Wed, 26 Feb 2014 16:04:38 -0600
> Chr
On Mar 3, 2014, at 9:23 PM, Joe Gordon wrote:
> Hi All,
>
> 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
> we cannot remove any ext
On Mar 4, 2014, at 4:09 AM, Sean Dague 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
>> decisi
On Mar 4, 2014, at 11:14 AM, Sean Dague 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 single knob
On Apr 23, 2014, at 6:36 PM, Sam Morrison 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
> nova-conductor.
>
> Added more details to https://bugs.launchpad.net/nova/+bug/1308805
>
>
On Apr 24, 2014, at 6:10 AM, Sam Morrison 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. Can’t really f
On Apr 25, 2014, at 2:15 PM, Jay Pipes wrote:
> Hi Stackers,
>
> 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
> behind the feature
+1
> On Jun 13, 2014, at 3:40 PM, Michael Still wrote:
>
> Greetings,
>
> 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 has
> drive
On Mar 6, 2014, at 11:09 AM, Russell Bryant 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 should have a d
On Mar 16, 2014, at 7:58 PM, Michael Still wrote:
> Hi.
>
> 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:
>
> * create
On Mar 18, 2014, at 11:57 AM, Matt Riedemann 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 it. I think I have
> t
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 AP
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
conductor, etc.
On Mar 14, 2014, at 3:58 PM, Dan Smith wrote:
>> Just to answer this point, despite the review latency, please don't be
>> te
On Mar 24, 2014, at 12:31 PM, Tim Bell 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)
> before th
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
On Apr 9, 2014, at 12:50 PM, Dan Smith wrote:
>>> So I'm a soft -1 on dropping it from hacking.
>
> Me too.
>
>> from testtools import matchers
>> ...
>>
>> Or = matchers.Or
>> LessThan = matchers.LessThan
>> ...
>
> This is the right way to do it, IMHO, if you have something like
> matchers
On Apr 13, 2014, at 9:58 PM, Michael Still 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 to get the
> lo
+1
> On Apr 17, 2014, at 12:27 PM, Russell Haering
> wrote:
>
> Completely agree.
>
> 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 same tools as we us
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 nova
an
> throw stuff up on github and then say I need XYZ config to use it).
>
> To me non-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
On Apr 19, 2014, at 11:08 PM, Sam Morrison 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 wrote:
>
>> The problem here
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 t
Hey all,
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 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: You do not have
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
enough.
- Chris
> On Jun 24, 2014, at 5:17 PM, Joe Gordon wrote:
>
On Jul 7, 2014, at 11:11 AM, Angus Salkeld wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/07/14 05:30, Mark McLoughlin wrote:
>> Hey
>>
>> This is an attempt to summarize a really useful discussion that Victor,
>> Flavio and I have been having today. At the bottom are some
On Jul 14, 2014, at 10:44 AM, Matt Riedemann wrote:
> Today we only gate on exercises in devstack for cells testing coverage in the
> gate-devstack-dsvm-cells job.
>
> The cells tempest non-voting job was moving to the experimental queue here
> [1] since it doesn't work with a lot of the comp
+1
On Jul 30, 2014, at 2:02 PM, Michael Still wrote:
> Greetings,
>
> 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
> so long that the
Hi all,
I'd like to announce my candidacy for a seat on the OpenStack
Technical Committee.
- 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. Mo
I may have put that in the wrong spot. Oops.
> On Oct 18, 2013, at 11:11 PM, Akihiro Motoki wrote:
>
> Hi Thierry, John,
>
> In Havana release notes, Swift known issues section is talking about
> Nova Cells issue. Could you confirm?
> https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_I
Ah, I know what happened. This is corrected now.
- Chris
On Oct 19, 2013, at 12:27 AM, Chris Behrens wrote:
> I may have put that in the wrong spot. Oops.
>
>> On Oct 18, 2013, at 11:11 PM, Akihiro Motoki wrote:
>>
>> Hi Thierry, John,
>>
>> In Hava
On Oct 24, 2013, at 1:33 PM, Robert Collins wrote:
> -2 to 10 minute downtimes.
>
> +1 to doing the evolution gracefully. There is a spec for doing that
> from the H summit; someone just needs to implement it.
+1. IMO, we need to move to a model where code can understand multiple schemas
and
On Oct 25, 2013, at 3:46 AM, "Day, Phil" wrote:
> Hi Folks,
>
> 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 what seems t
For this example, I'd look at using parens on the left side to see if that
helps. I also, like Sean, really dislike the look of \.
> On Nov 13, 2013, at 5:08 PM, Robert Collins wrote:
>
>> On 14 November 2013 13:59, Sean Dague wrote:
>>
>> This is an area where we actually have consensus in
On Nov 13, 2013, at 6:55 PM, Robert Collins wrote:
> On 14 November 2013 15:28, Chris Behrens wrote:
>> For this example, I'd look at using parens on the left side to see if that
>> helps. I also, like Sean, really dislike the look of \.
>
> I disl
The original intent behind 'all_tenants=1' was whether or not to include all
instances for all tenants in the filtering process. Basically it means "Should
I operate as admin or not?". I still view it this way, and would prefer it
still mean this (although it might be more clear with a differ
On Jun 17, 2013, at 7:49 AM, Russell Bryant 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
>> periodically with data about capa
On Jun 21, 2013, at 9:16 AM, Armando Migliaccio 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.
>
> Were federated q
+1
On Jun 26, 2013, at 10:09 AM, Russell Bryant wrote:
> Greetings,
>
> 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
> contributing
On May 14, 2013, at 3:59 PM, Russell Bryant wrote:
> On 05/13/2013 11:04 AM, Jay Pipes wrote:
>> On 05/09/2013 04:29 PM, Chris Behrens wrote:
>>> Yes, I think this makes a lot of sense. At some point we need to come back
>>> around to bursting. One big thing we w
On Jul 11, 2013, at 8:28 AM, John Griffith wrote:
>
>
>
> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith wrote:
> > In the corner to my left, our current largest gate reset culprit
> > appears to be neutron bug #1194026 - weighing in with 62 rechecks
> > since June 24th (http://status.openstack.
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,
however. :)
I thought there was a sec group patch up for cells, but I've no
On Jul 13, 2013, at 8:28 AM, Sean Dague 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
> bouncing aro
Thanks. I think I'll blame lack of sleep :)
On Jul 14, 2013, at 8:16 AM, Sean Dague wrote:
> On 07/13/2013 09:27 PM, Chris Behrens wrote:
>>
>> On Jul 13, 2013, at 8:28 AM, Sean Dague wrote:
>>
>>> Like I said, as long as someone is going to work on it, I
, Andrew Laski wrote:
> I will also be working to help get cells passing tests. I just setup a
> blueprint on the Nova side for this,
> https://blueprints.launchpad.net/nova/+spec/cells-gating.
>
> On 07/13/13 at 05:00pm, Chris Behrens wrote:
>> I can make a commitment to help
'deleted' is used so that we can have proper unique constraints by setting it
to `id` on deletion. This was not the case until Grizzly, and before Grizzly I
would have agreed completely.
- Chris
On Aug 19, 2013, at 12:39 AM, Jay Pipes wrote:
> I'm throwing this up here to get some feedback o
the id value solved?
>
> -jay
>
> On 08/19/2013 03:56 AM, Chris Behrens wrote:
>> 'deleted' is used so that we can have proper unique constraints by setting
>> it to `id` on deletion. This was not the case until Grizzly, and before
>> Grizzly I would have ag
On Aug 20, 2013, at 12:51 PM, Ed Leafe wrote:
> On Aug 20, 2013, at 2:33 PM, Chris Behrens
> wrote:
>
>> 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 delet
On Aug 20, 2013, at 1:05 PM, Jay Pipes 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 cater to.
>
>
On Aug 20, 2013, at 3:29 PM, Vishvananda Ishaya 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 long ago. Of
66 matches
Mail list logo
