On Thu, Apr 24, 2014 at 4:47 AM, Randy Bias wrote:
> ... I’d like to recommend we move
> them into Stackforge as we did with the GCE APIs. That way these can become
> optional components installed by those who want to use them. The other
> advantage is that they can be iterated on out of band.
On Thu, Apr 24, 2014 at 7:39 AM, Joe Gordon wrote:
> So no one is seriously discussing moving EC2 out of nova right now. The
> issue is that the EC2 code and tempest tests aren't being maintained are
> slowly code rotting. The goal of this thread is to get some volunteers to
> work on EC2.
>
> "I
On Wed, Apr 23, 2014 at 11:34 PM, Russell Bryant wrote:
> John originally mentioned this on the review, but Phil and I both seem
> to agree.
>
> Most novaclient work can just be a work item of a nova blueprint. How
> about we just handle it that way?
For those cases where that's true I agree th
I'd like another term as Compute PTL, if you'll have me.
We live in interesting times. OpenStack has clearly gained a large
amount of mind share in the open cloud marketplace, with Nova being a
very commonly deployed component. Yet, we don't have a fantastic
container solution, which is our bigges
On Fri, Sep 19, 2014 at 11:13 PM, Sean Dague wrote:
> I've spent the better part of the last 2 weeks in the Nova bug tracker
> to try to turn it into something that doesn't cause people to run away
> screaming. I don't remember exactly where we started at open bug count 2
> weeks ago (it was north
Thanks. That's now approved and we're waiting for the merge.
Michael
On Fri, Sep 19, 2014 at 7:30 PM, Andrey Kurilin wrote:
> Here you are!:)
> https://review.openstack.org/#/c/122667
>
> On Fri, Sep 19, 2014 at 9:02 AM, Michael Still wrote:
>>
>> I would like
And the python-novaclient release has now been done.
Thanks,
Michael
On Sat, Sep 20, 2014 at 6:53 AM, Michael Still wrote:
> Thanks. That's now approved and we're waiting for the merge.
>
> Michael
>
> On Fri, Sep 19, 2014 at 7:30 PM, Andrey Kurilin wrote:
&g
Hi.
Today I encountered bug 1369627 [1] as I trolled the status of release
critical bugs, which appears to be fall out from the decision to
implement adding support for config drives stored in RBD. While I have
no problem with that being at thing we do, I'm concerned by the way it
was implemented
Hi.
I know we've been talking about deprecating nova.virt.disk.vfs.localfs
for a long time, in favour of wanting people to use libguestfs
instead. However, I can't immediately find any written documentation
for when we said we'd do that thing.
Additionally, this came to my attention because Ubunt
es LVM support, and leaves an unused file
> behind in the instance directory. Other than that, it's acceptable for a
> late-stage change, IMO.
>
> Best Regards,
> Solly
>
> - Original Message -
>> From: "Michael Still"
>> To: "OpenStack
:53:36AM +1000, Michael Still wrote:
>> Hi.
>>
>> I know we've been talking about deprecating nova.virt.disk.vfs.localfs
>> for a long time, in favour of wanting people to use libguestfs
>> instead. However, I can't immediately find any written docu
On Tue, Sep 23, 2014 at 8:58 PM, Daniel P. Berrange wrote:
> On Tue, Sep 23, 2014 at 02:27:52PM +0400, Roman Bogorodskiy wrote:
>> Michael Still wrote:
>>
>> > Hi.
>> >
>> > I know we've been talking about deprecating nova.virt.disk.vfs.localfs
&g
Hi,
so, I'd really like to see https://review.openstack.org/#/c/121663/
merged in rc1. That patch is approved right now.
However, it depends on https://review.openstack.org/#/c/119521/, which
is not approved. 119521 fixes a problem where we make five RPC calls
per call to get_network_info, which
We agreed a few nova team meetings ago that this would be done in
early October, so I expect it will happen sometime this week.
Cheers,
Michael
On Tue, Sep 30, 2014 at 10:09 AM, John Zhang
wrote:
> Hi,
>
> We wrote a spec (for fast booting a large number of VMs) but failed to catch
> up with Jun
It seems like a no-brainer to me to prioritise people who have been patient
with us.
How about we tag these re-proposals with a commit message tag people can
search for when they review? Perhaps "Previously-approved: Juno"?
Michael
On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon wrote:
>
>
> On M
I agree with Sean here.
The original idea was that these stable branches would be maintained by the
distros, and that is clearly not happening if you look at the code review
latency there. We need to sort that out before we even consider supporting
a release for more than the one year we currently
Thanks for doing this. My recollection is that we still need some features
landed in Neutron before this work can complete, but its possible I am
confused.
A public status update on that from the Neutron team would be good.
Michael
On Thu, Oct 2, 2014 at 6:18 AM, Clark Boylan wrote:
> Hello,
>
Logging like that is useful for admins, but I wonder if we should talk
about notifications as well. That would allow people to build systems which
warned the user as well that they are nearing quota.
Michael
On Tue, Oct 7, 2014 at 2:33 AM, Matt Riedemann
wrote:
> I'm floating this in case the i
I am pleased to announce that the specs process for nova in kilo is
now open. There are some tweaks to the previous process, so please
read this entire email before uploading your spec!
Blueprints approved in Juno
===
For specs approved in Juno, there is a fast track appro
On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon wrote:
> On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon wrote:
>>
>> Recently there has been a lot of discussion around the development growing
>> pains in nova. Instead of guessing about how bad some of the issues are, I
>> tried to answer a few questions
Hi.
I am pleased to announce details for the Kilo Compute mid-cycle
meetup, but first some background about how we got here.
Two companies actively involved in OpenStack came forward with offers
to host the Compute meetup. However, one of those companies has
gracefully decided to wait until the L
I think nova wins. We have:
./nova/virt/libvirt/driver.py:3736:1: C901
'LibvirtDriver._get_guest_config' is too complex (67)
Michael
On Fri, Oct 17, 2014 at 2:45 PM, Dolph Mathews wrote:
> I ran this tool on Keystone and liked the results - the two methods that
> ranked D should certainly be re
Hi,
I've just noticed that the DB Datasets CI (the artist formerly known
as turbo hipster) is failing for many patches. I'm looking into it
now.
Michael
--
Rackspace Australia
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://li
r your patience everyone.
Is it possible to add a verification step to nodepool so that it
doesn't mark a new image as ready unless it passes some basic sanity
checks?
Thanks,
Michael
On Sat, Oct 18, 2014 at 8:44 AM, Michael Still wrote:
> Hi,
>
> I've just noticed that the D
On Sat, Oct 18, 2014 at 11:02 AM, Jeremy Stanley wrote:
> On 2014-10-18 10:45:23 +1100 (+1100), Michael Still wrote:
> [...]
>> Is it possible to add a verification step to nodepool so that it
>> doesn't mark a new image as ready unless it passes some basic sanity
>
Thanks for this.
It would be interesting to see how much of this work you think is
achievable in Kilo. How long do you see this process taking? In line
with that, is it just you currently working on this? Would calling for
volunteers to help be meaningful?
Michael
On Tue, Oct 21, 2014 at 5:00 AM
Hello.
Its clear that the scheduler and resource tracker inside Nova are
areas where we need to innovate. There are a lot of proposals in this
space at the moment, and it can be hard to tell which ones are being
implemented and in which order.
I have therefore asked Jay Pipes to act as "designate
On Tuesday, October 21, 2014, Roman Bogorodskiy
wrote:
> On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon > wrote:
> > On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy <
> rbogorods...@mirantis.com > wrote:
>
[snip]
> >> High level overview of what needs to be done:
> >>
> >> - Nova
> >> *
Hey,
this is just a friendly reminder that we're skipping the meeting this
week as it is so close to the summit and many are travelling already.
We also wont have one the week of the summit for obvious reasons.
See you all in Paris!
Michael
--
Rackspace Australia
_
Hi,
I've just swapped the functional testing and object status sessions in
our track. This was done so that the QA team could attend the
functional testing session, which originally conflicted with their
sessions. Hopefully this doesn't create problems for anyone else, but
I figured an announcemen
Dear Americans... you're not really going to come to a meeting this
week are you? There's that thanks giving thing, right?
So... Should we cancel for this week?
Michael
--
Rackspace Australia
___
OpenStack-dev mailing list
OpenStack-dev@lists.opensta
It might be a good idea to add a comment to the RPC layer for the
snapshot call explaining why we haven't implemented a lock check. That
would reduce future confusion as well.
Cheers,
Michael
On Fri, Jun 20, 2014 at 5:06 AM, melanie witt wrote:
> On Jun 17, 2014, at 13:34, Andrew Laski wrote:
>
Hi, this came up in the weekly release sync with ttx, and I think its
worth documenting as clearly as possible.
Here is our proposed timeline for the rest of the Juno release. This
is important for people with spec proposals either out for review, or
intending to be sent for review soon.
(The num
t get much feedback
> from the cores - but I don't see the harm in letting specs be submitted to
> the K directory for early review / feedback during that period ?
>
> Phil
>
>> -Original Message-
>> From: Michael Still [mailto:mi...@stillhq.com]
>
e
>>
>> On 06/24/2014 07:35 AM, Michael Still wrote:
>> > Phil -- I really want people to focus their efforts on fixing bugs in
>> > that period was the main thing. The theory was if we encouraged people
>> > to work on specs for the next release, then they'd be
This sounds like something which should be reported as a bug. You do
that at https://bugs.launchpad.net/nova/+filebug
Cheers,
Michael
On Thu, Jun 26, 2014 at 1:43 AM, Agrawal, Ankit
wrote:
> Hi All,
>
>
>
> When I boot an instance from volume and the take snapshot of that instance
> it creates a
Hi. The meeting this week would be on the 3rd of July, which I assume
means that many people will be out of the office. Do people think its
worth running the meeting or shall we give this week a miss?
Thanks,
Michael
--
Rackspace Australia
___
OpenSta
Ok, let's skip the meeting this week so people can have a break.
Cheers,
Michael
On Tue, Jul 1, 2014 at 3:45 AM, melanie witt wrote:
> On Jun 29, 2014, at 17:01, Michael Still wrote:
>
>> Hi. The meeting this week would be on the 3rd of July, which I assume
>> means t
We were talking about doing something with google+ for Chris Yeoh, but
haven't really progressed the plan. Does someone want to pick up the
ball with that or shall I?
Michael
On Tue, Jul 1, 2014 at 11:50 PM, Dugger, Donald D
wrote:
> At minimum I can arrange for a phone bridge at the sprint (Int
On Thu, Jul 3, 2014 at 4:33 AM, Luke Gorrie wrote:
>
> On 30 June 2014 21:04, Kevin Benton wrote:
>>
>> As a maintainer of a small CI system that tends to get backed up during
>> milestone rush hours, it would be nice if we were allowed up to 12 hours.
>> However, as a developer this seems like t
I think you'd be better of requesting an exception for your spec than
splitting the scheduler immediately. These refactorings need to happen
anyways, and if your scheduler work diverges too far from nova then
we're going to have a painful time getting things back in sync later.
Michael
On Mon, Ju
Joe has a good answer, but you should also be aware of the hypervisor
support matrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix),
which hopefully comes some way to explaining what we expect of a nova
driver.
Cheers,
Michael
On Tue, Jul 8, 2014 at 9:11 AM, Joe Gordon wrote:
>
> On J
Adrian, is there any news on this? I want to start booking my ops
meetup travel, but I don't know if I should include this meetup or
not.
Thanks,
Michael
On Wed, Jul 2, 2014 at 8:12 AM, Russell Bryant wrote:
> On 07/01/2014 05:59 PM, Adrian Otto wrote:
>> Team,
>>
>> Please help us select dates
The associated bug says this is probably a qemu bug, so I think we
should rephrase that to "we need to start thinking about how to make
sure upstream changes don't break nova".
Michael
On Wed, Jul 9, 2014 at 7:50 AM, Joe Gordon wrote:
>
> On Thu, Jun 26, 2014 at 4:12 AM, Daniel P. Berrange
> wr
On Wed, Jul 9, 2014 at 8:21 AM, Sean Dague wrote:
> This is also why I find it unlikely to be a qemu bug, because that's not
> shared state between guests. If qemu just randomly wedges itself, that
> would be detectable much easier outside of the gate. And there have been
> attempts by danpb to s
Can we get our gate images tweaked to have more verbose libvirt
logging on in general? There's been a few times in the last year or so
when we've really needed it.
Michael
On Wed, Jul 9, 2014 at 6:01 PM, Daniel P. Berrange wrote:
> On Wed, Jul 09, 2014 at 08:58:02AM +1000, Michae
Sorry for the delay here. This email got lost in my inbox while I was
travelling.
This release is now tagged. Additionally, I have created a milestone
for this release in launchpad, which is the keystone process for
client releases. This means that users of launchpad can now see what
release a giv
>>> On 11/07/14 02:04, Michael Still wrote:
>>>>> Sorry for the delay here. This email got lost in my inbox while I was
>>>>> travelling.
>>>>>
>>>>> This release is now tagged. Additionally, I have created a milestone
>>>>>
You should probably add these details to the wiki page for the event
at https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint
Unfortunately my travel is booked already, so I wont be there for the Thursday.
Michael
On Sat, Jul 12, 2014 at 8:31 AM, Adrian Otto wrote:
> CORRECTION: This even
I can't see a way to add the hudson user to that group, I'm hoping
fungi might have come advice there.
Michael
On Tue, Jul 15, 2014 at 6:55 AM, melanie witt wrote:
> Hi Nova Bug Wranglers,
>
> There have been some issues where the gerrit hook script is unable to link a
> review to a launchpad b
Jeremy helped me with this on IRC, and the hudson bot is now a member
of that group.
Cheers,
Michael
On Tue, Jul 15, 2014 at 9:34 AM, Michael Still wrote:
> I can't see a way to add the hudson user to that group, I'm hoping
> fungi might have come advice there.
>
> Mich
Ok, I just released 2.18.1 to address this issue.
https://launchpad.net/python-novaclient/+milestone/2.18.1
Cheers,
Michael
On Sat, Jul 12, 2014 at 7:18 AM, Michael Still wrote:
> I can do another release once https://review.openstack.org/#/c/106447/ merges.
>
> Michael
>
> On Sa
Hi.
We've now hit our room capacity, so I have closed registrations for
the nova mid cycle meetup. Please reply to this thread if that's a
significant problem for someone.
Thanks,
Michael
--
Rackspace Australia
___
OpenStack-dev mailing list
OpenStac
The containers meetup is in a different room with different space
constraints, so containers focussed people should do whatever Adrian
is doing for registration.
Michael
On Wed, Jul 16, 2014 at 12:53 PM, Eric Windisch wrote:
>
>
>
> On Tue, Jul 15, 2014 at 6:42 PM, Rick Harris
> wrote:
>>
>> He
Hi.
I think its time to start getting more organized with an agenda for
the mid cycle meetup. When we first announced the meetup we created an
etherpad with a list of things we wanted to talk about during the
meetup. That list is here:
https://etherpad.openstack.org/p/juno-nova-mid-cycle-meet
On Thu, Jul 17, 2014 at 3:27 AM, Vishvananda Ishaya
wrote:
> On Jul 16, 2014, at 8:28 AM, Daniel P. Berrange wrote:>
>> On Wed, Jul 16, 2014 at 08:12:47AM -0700, Clark Boylan wrote:
>>
>>> I am worried that we would just regress to the current process because
>>> we have tried something similar t
Top posting to the original email because I want this to stand out...
I've added this to the agenda for the nova mid cycle meetup, I think
most of the contributors to this thread will be there. So, if we can
nail this down here then that's great, but if we think we'd be more
productive in person c
On Thu, Jul 17, 2014 at 12:20 AM, Eric Windisch wrote:
> On Tue, Jul 15, 2014 at 11:55 PM, Michael Still wrote:
>>
>> The containers meetup is in a different room with different space
>> constraints, so containers focussed people should do whatever Adrian
>>
That time is around 1am for me. I'm ok with that as long as someone on
the nova side can attend in my place.
Michael
On Thu, Jul 17, 2014 at 12:22 PM, Kyle Mestery wrote:
> As we're getting down to the wire in Juno, I'd like to propose we have
> a weekly meeting on the nova-network and neutron p
At our weekly nova meeting just now I promised that I'd send an email
here explaining our intentions with the spec freeze for juno.
The proposed process works like this, but is subject to change:
- you request a spec freeze exception on the openstack-dev mailing
list. Please do this in the next
Those who have replied to this thread are now registered.
Michael
On Wed, Jul 16, 2014 at 6:56 AM, Michael Still wrote:
> Hi.
>
> We've now hit our room capacity, so I have closed registrations for
> the nova mid cycle meetup. Please reply to this thread if that's a
>
I just want to check my understanding -- it seems to me that this
depends on a feature that's very new to libvirt (merged there 22 May
2014). Is that right?
http://libvirt.org/git/?p=libvirt.git;a=commit;h=d950494129513558a303387e26a2bab057012c5e
We've had some concerns about adding features to t
why I cc'ed the
main protagonists into my email on this thread.
Michael
On Mon, Jul 21, 2014 at 10:55 AM, Mike Perez wrote:
> On 10:21 Mon 21 Jul , Michael Still wrote:
>> I just want to check my understanding -- it seems to me that this
>> depends on a feature that'
I think this sounds risky to me... I'd rather we landed _something_ in
terms of an ironic driver in juno, rather than adding features to what
we have now. In fact, I thought Devananda had frozen the ironic nova
driver to make this easier?
Michael
On Tue, Jul 22, 2014 at 4:45 PM, Faizan Barmawer
Fair enough. Let's roll with that then.
Michael
On Tue, Jul 22, 2014 at 6:33 AM, Sean Dague wrote:
> On 07/21/2014 03:35 PM, Dan Smith wrote:
>>> We've already approved many other blueprints for Juno that involve features
>>> from new libvirt, so I don't think it is credible to reject this or an
2014 at 8:44 AM, Michael Still wrote:
> At our weekly nova meeting just now I promised that I'd send an email
> here explaining our intentions with the spec freeze for juno.
>
> The proposed process works like this, but is subject to change:
>
> - you request a spec freeze excepti
Ok, this one has two cores, so the exception is approved. The
exception is in the form of another week to get the spec merged, so
quick iterations are the key.
Cheers,
Michael
On Tue, Jul 22, 2014 at 1:55 PM, Kenichi Oomichi
wrote:
>
>> -Original Message-
>> From: John Garbutt [mailto:j.
36 PM, Michael Still wrote:
> Fair enough. Let's roll with that then.
>
> Michael
>
> On Tue, Jul 22, 2014 at 6:33 AM, Sean Dague wrote:
>> On 07/21/2014 03:35 PM, Dan Smith wrote:
>>>> We've already approved many other blueprints for Juno that involve featur
Ok, this one has two cores, so the exception is approved. The
exception is in the form of another week to get the spec merged, so
quick iterations are the key.
Cheers,
Michael
On Tue, Jul 22, 2014 at 2:02 AM, Kevin L. Mitchell
wrote:
> On Mon, 2014-07-21 at 10:55 +0100, John Garbutt wrote:
>> On
This spec freeze exception only has one core signed up. Are there any
other cores interested in working with Sylvain on this one?
Michael
On Mon, Jul 21, 2014 at 7:59 PM, John Garbutt wrote:
> On 18 July 2014 09:10, Sylvain Bauza wrote:
>> Hi team,
>>
>> I would like to put your attention on ht
Another core sponsor would be nice on this one. Any takers?
Michael
On Thu, Jul 24, 2014 at 4:14 AM, Daniel P. Berrange wrote:
> On Wed, Jul 23, 2014 at 06:08:52PM +, Day, Phil wrote:
>> Hi Folks,
>>
>> I'd like to propose the following as an exception to the spec freeze, on the
>> basis th
In that case this exception is approved. The exception is in the form
of another week to get the spec merged, so quick iterations are the
key.
Cheers,
Michael
On Wed, Jul 23, 2014 at 5:31 PM, Sylvain Bauza wrote:
> Le 23/07/2014 01:11, Michael Still a écrit :
>> This spec freeze excep
p for this if I drop the point of contention - which
> I'ev done
>
>
> Yes, I will sponsor this one as well. This is more a bug fix than a feature
> IMO and would be really nice to get into Juno.
>
>
>
>> -Original Message-
>> From: Michael Still [mailt
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 there are probably other types of core status I have
missed.
Please resp
On Thu, Jul 31, 2014 at 9:57 PM, Russell Bryant wrote:
> Further, I'd like to propose that we treat all of existing +1 reviews as
> +2 (once he's officially added to the team). Does anyone have a problem
> with doing that? I think some folks would have done that anyway, but I
> wanted to clarif
Jay has now been added to the nova-core group in gerrit.
Cheers,
Michael
On Thu, Jul 31, 2014 at 7:02 AM, 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 previousl
Maybe we should change how we wait?
I get that we don't want to sit around forever, but perhaps we should
specify a total maximum time to wait instead of a number of iterations
of a loop? Something like "15 minutes should be long enough for
anyone!". Eventlet sleeps are also pretty cheap, so havin
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote:
> We seem to be unable to address some key issues in the software we
> produce, and part of it is due to strategic contributors (and core
> reviewers) being overwhelmed just trying to stay afloat of what's
> happening. For such projects, is it
On Thu, Aug 7, 2014 at 10:05 AM, Stefano Maffulli wrote:
> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
>> - we rate limit the total number of blueprints under code review at
>> any one time to a fixed number of "slots". I secretly prefer the term
>>
On Thu, Aug 7, 2014 at 11:20 PM, Russell Bryant wrote:
> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
> slot selection would just be Nova drivers. I
>> think there is an assumption in the old system that everyone in Nova
>> core wants to prioritize the blueprints. I think t
It seems to me that the tension here is that there are groups who
would really like to use features in newer libvirts that we don't CI
on in the gate. Is it naive to think that a possible solution here is
to do the following:
- revert the libvirt version_cap flag
- instead implement a third part
On Fri, Sep 13, 2013 at 7:51 AM, Dolph Mathews wrote:
> ++ Data backups are a solved problem, and no DB admin should trust an
> application to perform its own backups.
I'm not completely sure I agree. Consider the case where a cloud with
active users undertakes an upgrade. The migrations run, an
Done.
Cheers,
Michael
On Mon, Sep 16, 2013 at 8:21 PM, Day, Phil wrote:
> Hi Folks,
>
>
>
> Could one more core look at the following simple bug fix please:
> https://review.openstack.org/#/c/46486/ - which allows the system clean up
> VMs from deleted instances.
>
>
>
>
>
> Its already got one
Before https://review.openstack.org/#/c/46867/ if file injection of a
mandatory file fails, nova just silently ignores the failure, which is
clearly wrong. However, that review now can't land because its
revealed another failure in the file injection code via tempest, which
is...
Should file injec
On Sat, Sep 21, 2013 at 6:24 AM, Dan Wendlandt wrote:
> On Fri, Sep 20, 2013 at 1:09 PM, Joe Gordon wrote:
>> On Fri, Sep 20, 2013 at 11:52 AM, Russell Bryant
>> wrote:
>>> On 09/20/2013 02:02 PM, Dan Wendlandt wrote:
> I couldn't agree more. In fact, the VMware team has been working hard to
>
On Sat, Sep 21, 2013 at 7:12 AM, Dan Wendlandt wrote:
> On Fri, Sep 20, 2013 at 2:05 PM, Michael Still wrote:
>> How are you doing this? Joshua Hesketh has been working on integrating
>> our internal DB CI tests into upstream zuul, so I wonder there are
>> synergies that
To confirm, we have a little bit over a day left for people to nominate, right?
On a personal note, I'm a little sad to see so many single candidate
elections. I guess it might indicate a strong consensus, but I worry
it encourages group think over time.
Michael
On Wed, Sep 25, 2013 at 6:08 AM,
On Thu, Sep 26, 2013 at 2:49 PM, Clint Byrum wrote:
> Excerpts from Joe Gordon's message of 2013-09-25 17:56:15 -0700:
>> Hi All,
>>
>> TL;DR: We will be automatically identifying your flaky tempest runs, so you
>> just have to confirm that you hit bug x, not identify which bug you hit.
>
> \o/
I
If you're coming to linux.conf.au 2014, would you be interested in a
couple of day meetup for OpenStack developers the week after the
conference? I'm trying to judge interest before I try and get it
booked.
The timing (early January) is nice because its basically mid cycle for
Icehouse, so its a n
On Thu, Oct 3, 2013 at 11:28 AM, Robert Collins
wrote:
> Sounds great, but please commit to it asap, I nearly bought my tickets
> this morning, and modifying them is expensive.
*shrug*
Its one of those things... I don't want to waste the time of a major
openstack deployment if not enough people
Greetings! I am currently a member of the TC, and I would like to
continue to serve.
I'm going to write this email backwards because I am aware it is quite
long. I have put what I hope to achieve on the TC at the top, but
provide background detail afterwards for those who want to dig deeper.
I am
To follow up on this, I've decided to give running a meetup a go. The
details are at http://sites.rcbops.com/lca2014_openstack/?p=38
Cheers,
Michael
On Thu, Oct 3, 2013 at 10:30 AM, Michael Still wrote:
> If you're coming to linux.conf.au 2014, would you be interested in a
&g
On Wed, Oct 16, 2013 at 2:08 PM, Clark Laughlin
wrote:
> Hello everyone,
>
> I'm trying to figure out how " heads='1'/>" makes it into the libvirt domain XML when creating a new
> instance. I see where much of the content of the XML is created by the
> libvirt driver under nova/nova/virt/libvir
On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum wrote:
> I suggest that we just put Copyright headers back in the source files.
> That will make Debian's licensecheck work fairly automatically. A single
> file that tries to do exactly what debian/copyright would do seems a bit
> odd.
The problem he
This is super cool. Thanks!
One piece of feedback -- would it be possible to get the results as
something other than a tarball? Downloading the entire tarball to read
one log is slightly annoying.
Thanks,
Michael
On Sat, Oct 19, 2013 at 9:29 AM, Sreeram Yerrapragada
wrote:
> We had some infrast
On Wed, Oct 23, 2013 at 6:48 AM, Mate Lakat wrote:
> Hi,
>
> We are looking at config drive use cases, and saw this in the official
> docs:
>
> Do not rely on the presence of the EC2 metadata present in the config
> drive (i.e., files under the ec2 directory), as this content may be
> remove
Hi.
Because I am a grumpy old man I have just -2'ed
https://review.openstack.org/#/c/39685/ and I wanted to explain my
rationale. Mostly I am hoping for a consensus to form -- if I am wrong
then I'll happy remove my vote from this patch.
This patch does the reasonably sensible thing of converting
On Fri, Oct 25, 2013 at 8:19 AM, Johannes Erdfelt wrote:
> On Fri, Oct 25, 2013, Michael Still wrote:
>> However, when I run it with medium sized (30 million instances)
>> databases, the change does cause a 10 minute downtime. I don't
>> personally think the change is
On Fri, Oct 25, 2013 at 9:07 AM, Boris Pavlovic wrote:
> Johannes,
>
> +1, purging should help here a lot.
Sure, but my point is more:
- pruning isn't done by the system automatically, so we have to
assume it never happens
- we need to have a clearer consensus about what we think the maximum
On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant wrote:
> I also would not use migrate. sqlalchemy-migrate is a dead upstream and
> we (OpenStack) have had to inherit it. For new projects, you should use
> alembic. That's actively developed and maintained. Other OpenStack
> projects are either
201 - 300 of 510 matches
Mail list logo
