On Thu, Aug 7, 2014 at 11:20 PM, Russell Bryant rbry...@redhat.com 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
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
On Sun, Aug 10, 2014 at 2:33 AM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote:
[...]
We've seen several times that building and maintaining 3rd party
CI is a *lot* of work.
Building and maintaining *any* CI is a *lot* of work, not the
On Fri, Aug 8, 2014 at 7:06 PM, Thierry Carrez thie...@openstack.org wrote:
Michael Still wrote:
[...] I think an implied side effect of
the runway system is that nova-drivers would -2 blueprint reviews
which were not occupying a slot.
(If we start doing more -2's I think we will need
Hi,
this is just a friendly reminder that we are now 9 days away from
feature proposal freeze for nova. If you think your blueprint isn't
going to make it in time, then now would be a good time to let me know
so that we can defer it until Kilo. That will free up reviewer time
for other
This looks reasonable to me, with a slight concern that I don't know
what step five looks like... What if we can never reach a consensus on
an issue?
Michael
On Wed, Aug 13, 2014 at 12:56 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
(Terrible name for a policy, I know)
From the
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
attempt at that.
Nova expects a minimum level of sustained code reviews from cores. In
the past this has been generally held to be in the order of two
Actually, thinking on this more -- the lack of consensus is on the
attempt to re-add the patch, so I guess we'd handle that just like we
do for a contentious patch now.
Michael
On Wed, Aug 13, 2014 at 7:03 AM, Michael Still mi...@stillhq.com wrote:
This looks reasonable to me, with a slight
On Wed, Aug 13, 2014 at 11:36 AM, Russell Bryant rbry...@redhat.com wrote:
On Aug 12, 2014, at 5:10 PM, Michael Still mi...@stillhq.com wrote:
This looks reasonable to me, with a slight concern that I don't know
what step five looks like... What if we can never reach a consensus on
an issue
On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn egl...@redhat.com wrote:
It seems like this is exactly what the slots give us, though. The core review
team picks a number of slots indicating how much work they think they can
actually do (less than the available number of blueprints), and then
On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
I'm not questioning the value of f2f - I'm questioning the idea of
doing f2f meetings sooo many times a year. OpenStack is very much
the outlier here among open source projects - the vast majority of
projects get along very
On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/13/2014 01:09 PM, Dan Smith wrote:
Expecting cores to be at these sorts of things seems pretty reasonable
to me, given the usefulness (and gravity) of the discussions we've been
having so far. Companies with more
So, there's been a lot of email in the last few days and I feel I am
not keeping up.
Sylvain, can you summarise for me what the plan is here? Can we roll
forward or do we need to revert? Time is running out for Juno.
Thanks,
Michael
On Thu, Aug 14, 2014 at 3:40 AM, Sylvain Bauza
On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
Just wanted to quickly weigh in with my thoughts on this important topic. I
very much valued the face-to-face interaction that came from the mid-cycle
meetup in Beaverton (it was the only one I've ever been to).
That said,
On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote:
On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
Just wanted to quickly weigh in with my thoughts on this important
topic. I
On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith d...@danplanet.com wrote:
== Move Virt Drivers to use Objects (Juno Work) ==
I couldn't actually find any code out for review for this one apart
from https://review.openstack.org/#/c/94477/, is there more out there?
This was an umbrella one to cover
I have also been reminded that http://54.201.139.117/nova-bugs.html
tracks bugs with outstanding code reviews (click on ready for
review). There are 179 at the moment, so it sure would be cool to
land some bug fixes.
Thanks,
Michael
On Fri, Aug 15, 2014 at 5:57 AM, Michael Still mi
On Fri, Aug 15, 2014 at 7:28 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Aug 15, 2014 at 06:53:41AM +1000, Michael Still wrote:
On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith d...@danplanet.com wrote:
== Move Virt Drivers to use Objects (Juno Work) ==
I couldn't actually find any
Agreed. I think this should be in unless infra vetos it for load reasons.
Michael
On Sat, Aug 16, 2014 at 5:11 AM, Dan Smith d...@danplanet.com wrote:
Feature freeze is only a few weeks away (Sept 4). How about we just
leave it in experimental until after that big push? That seems pretty
My recollection is that this was a request from the oslo team, but it
was so long ago that I don't recall the details.
I think the change is low value, so should only be done when someone
is changing the logging in a file already (the log hinting for
example).
Michael
On Sun, Aug 17, 2014 at
.
Thanks,
Michael
On Tue, Aug 12, 2014 at 6:13 PM, Michael Still mi...@stillhq.com wrote:
Hi,
this is just a friendly reminder that we are now 9 days away from
feature proposal freeze for nova. If you think your blueprint isn't
going to make it in time, then now would be a good time to let me know
On Thu, Aug 21, 2014 at 1:17 AM, Tim Bell tim.b...@cern.ch wrote:
Michael has been posting very informative blogs on the summary of the
mid-cycle meetups for Nova. The one on the Nova Network to Neutron
migration was of particular interest to me as it raises a number of
potential impacts for
On Tue, Aug 26, 2014 at 7:59 PM, Tim Bell tim.b...@cern.ch wrote:
From: Michael Still [mailto:mi...@stillhq.com]
Sent: 25 August 2014 23:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network
Hi,
I'd like to start the summit planning process for Paris by asking for
people to brain storm a list of topics we might want to cover. We can
then prioritize that list and make sure that we address the most
important issues. This is a process that worked well for us at the
mid-cycle meetup.
To
For nova we haven't gotten around to doing this, but it shouldn't be a
big deal. I'll add it to the agenda for today's meeting.
Michael
On Thu, Aug 28, 2014 at 2:07 AM, Andreas Scheuring
scheu...@linux.vnet.ibm.com wrote:
Hi,
is it already possible to submit specs (nova neutron) for the K
On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote:
How to do we handle specs that have slipped through the cracks
and did not make it for Juno?
Rebase the proposal so it is under the 'kilo' directory
By which John means generally trying to avoid filling.
Michael
On Tue, Sep 2, 2014 at 10:52 AM, John Garbutt j...@johngarbutt.com wrote:
On 2 September 2014 15:27, Matthew Booth mbo...@redhat.com wrote:
We've been playing a game recently between oslo.vmware and the refactor
series where a
Hi,
I'll be on a long haul flight tonight from about 21:00 UTC. So... Once
feature freeze happens I'm not ignoring any freeze exceptions, it will
just take me a little while to get to them.
Michael
--
Rackspace Australia
___
OpenStack-dev mailing
Hi.
We're soon to hit feature freeze, as discussed in Thierry's recent
email. I'd like to outline the process for requesting a freeze
exception:
* your code must already be up for review
* your blueprint must have an approved spec
* you need three (3) sponsoring cores for an
On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov ndipa...@redhat.com wrote:
On 09/02/2014 08:16 PM, Michael Still wrote:
Hi.
We're soon to hit feature freeze, as discussed in Thierry's recent
email. I'd like to outline the process for requesting a freeze
exception:
* your code must
I'm good with this one too, so that makes three if Joe is ok with this.
@Josh -- can you please take a look at the TH failures?
Thanks,
Michael
On Wed, Sep 3, 2014 at 8:10 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 9/3/2014 5:08 PM, Andrey Kurilin wrote:
Hi All!
I'd like to
I'll be the third core here. Approved.
@John: can you please remove your -2 from this one?
Michael
On Thu, Sep 4, 2014 at 2:54 PM, Sean Dague s...@dague.net wrote:
On 09/04/2014 03:35 PM, Jay Pipes wrote:
On 09/04/2014 03:07 PM, Jiang, Yunhong wrote:
Hi,
I'd like to ask for a feature
These look good to me, I will be your third core. The middle one has
some comments from Jay, but it didn't look like a big deal
Approved.
@John: can you please remove your -2's on 104048, 74537, and 99974?
Michael
On Thu, Sep 4, 2014 at 12:14 PM, Jay Pipes jaypi...@gmail.com wrote:
On
On Thu, Sep 4, 2014 at 11:40 AM, Steve Gordon sgor...@redhat.com wrote:
Did you have a specific goal/date in mind for when you might start to
finalize this list? I am guessing at least after the dust settles on J-3 and
possibly even the first RCs but just curious.
Good question. Looking at
Approved.
Michael
On Thu, Sep 4, 2014 at 9:36 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Sep 3, 2014 at 11:30 PM, Michael Still mi...@stillhq.com wrote:
I'm good with this one too, so that makes three if Joe is ok with this.
I am ok with this, I hope the move to oslo.db
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core team bottleneck is thus to
follow this lead and split the nova virt drivers out into separate
projects and delegate their maintainence to
So, that's your three. This exception is approved.
Michael
On Thu, Sep 4, 2014 at 9:05 AM, Nikola Đipanov ndipa...@redhat.com wrote:
On 09/04/2014 03:46 PM, Daniel P. Berrange wrote:
On Thu, Sep 04, 2014 at 02:09:26PM +0100, Matthew Booth wrote:
I'd like to request a FFE for the remaining
Approved.
Michael
On Thu, Sep 4, 2014 at 8:11 AM, Ken'ichi Ohmichi ken1ohmi...@gmail.com wrote:
2014-09-04 20:34 GMT+09:00 Christopher Yeoh cbky...@gmail.com:
Hi,
I'd like to request a FFE for 4 changesets from the v2-on-v3-api
blueprint:
https://review.openstack.org/#/c/113814/
Approved.
Michael
On Thu, Sep 4, 2014 at 8:09 AM, Nikola Đipanov ndipa...@redhat.com wrote:
On 09/04/2014 02:42 PM, Sahid Orentino Ferdjaoui wrote:
Hello,
I would like to request a FFE for 4 changesets to complete the
blueprint serial-ports.
Topic on gerrit:
Approved.
Michael
On Fri, Sep 5, 2014 at 3:46 PM, Matt Dietz matt.di...@rackspace.com wrote:
Thirding sponsorship.
I didn¹t review as much as the other two, but I helped merge a couple of
the patches. Agreed with Jay otherwise; we¹re almost there, let¹s finish
it.
-Original
Approved.
Michael
On Fri, Sep 5, 2014 at 3:43 PM, Jay Pipes jaypi...@gmail.com wrote:
I am also happy to sponsor it. I've already reviewed the patches...
On 09/05/2014 04:34 PM, Joe Gordon wrote:
On Fri, Sep 5, 2014 at 9:11 AM, Mike Wilson geekinu...@gmail.com
Hi,
I've built this handy dandy list of granted FFEs, because searching
email to find out what is approved is horrible. It would be good if
people with approved FFEs could check their thing is listed here:
https://etherpad.openstack.org/p/juno-nova-approved-ffes
Michael
--
Rackspace
For better or for worse we have already merged about half of the
patches for this series, so I think stopping now because of concerns
about CI is pretty arbitrary. I do think Sean's point about scheduler
tests outside of tempest is valid though and I'd like to see it
reflected in the review
So, this one is looking for one more core. Any takers?
Michael
On Sat, Sep 6, 2014 at 2:20 AM, Day, Phil philip@hp.com wrote:
The corresponding Tempest change is also ready to roll (thanks to Ken'inci):
https://review.openstack.org/#/c/112474/1 so its kind of just a question of
On 09/05/2014 06:32 PM, Michael Still wrote:
So, this one is looking for one more core. Any takers?
Michael
On Sat, Sep 6, 2014 at 2:20 AM, Day, Phil philip@hp.com wrote:
The corresponding Tempest change is also ready to roll (thanks to
Ken'inci): https://review.openstack.org/#/c/112474
I will be the third here. Approved and added to the etherpad of doom.
Michael
On Fri, Sep 5, 2014 at 10:07 PM, Sean Dague s...@dague.net wrote:
On 09/05/2014 07:42 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 06:28:55AM +, Bohai (ricky) wrote:
Hi,
I'd like to ask for a feature
That's something I'll work on today.
Michael
On Sun, Sep 7, 2014 at 12:32 AM, Thierry Carrez thie...@openstack.org wrote:
Michael Still wrote:
I've built this handy dandy list of granted FFEs, because searching
email to find out what is approved is horrible. It would be good if
people
storage encryption is not on the list of granted FFEs
but I sent an email to John Garbutt yesterday listing
the 3 core sponsors for the FFE. Why was the FFE denied?
Dan
From: Michael Still mi...@stillhq.com
Sent: Friday, September 5, 2014 5:23 PM
outlining the FFE process was not
specific about how sponsors had to register their support, just that there
should be 3 core sponsors.
Dan
From: Michael Still mi...@stillhq.com
Sent: Saturday, September 6, 2014 4:50 PM
To: OpenStack Development Mailing
I didn't put two and two together and come up with three cores here.
Sorry for that. This FFE is approved.
Michael
On Fri, Sep 5, 2014 at 10:57 PM, Sean Dague s...@dague.net wrote:
On 09/04/2014 07:54 PM, Christopher Yeoh wrote:
On Thu, 4 Sep 2014 23:08:09 +0900
Ken'ichi Ohmichi
I haven't had a chance to read other people's posts, so I am sure
there is duplication here.
What would I have all of OpenStack working on if I was ruler of the
universe? Let's see...
1. Fixing our flakey gate: we're all annoyed by our code failing tests
with transient errors, but most people
Hi.
One of the last things blocking Ironic from graduating is deciding
whether or not we need a Nova API proxy for the old baremetal
extension to new fangled Ironic API. The TC has asked that we discuss
whether we think this functionality is actually necessary.
It should be noted that we're
On Wed, Sep 10, 2014 at 7:43 AM, Solly Ross sr...@redhat.com wrote:
With my admittedly limited knowledge of the whole Ironic process, the
question seems to me to be: If we don't implement a proxy, which people are
going to have a serious problem?
Do we have an data on which users/operators
Hi.
So feature freeze seems to be going quite well to me. We've already
landed 10 things which had requested exceptions.
However, there are still six things in flight, so I would like to
remind people to keep focussing on those please. The deadline for
these patches to be approved is Friday
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I think we're talking about a release
worth of work to get that right.
Just an observation from the last week or so...
The biggest problem nova faces at the moment isn't code review latency. Our
biggest problem is failing to fix our bugs so that the gate is reliable.
The number of rechecks we've done in the last week to try and land code is
truly startling.
I know
On Mon, Sep 15, 2014 at 7:42 PM, Daniel P. Berrange berra...@redhat.com wrote:
Unfortunately the reliability of the gate systems has the highest negative
impact on productivity right at the point in the dev cycle where we need
it to have the least impact too.
Agreed.
However, my instinct is
On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant rbry...@redhat.com wrote:
On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
Just an observation from the last week or so...
The biggest problem nova faces at the moment isn't code
for a bug day if we ran one?
Michael
On Tue, Sep 16, 2014 at 6:12 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant rbry...@redhat.com wrote:
On 09/15/2014 05:42 AM, Daniel P. Berrange wrote
Hi.
Is time to start identifying (and working on) release critical bugs in
nova before we ship RC1.
My initial position is that any critical bug is release critical.
There are currently critical bugs not targeted to rc1, but that should
change in the next day or so. If we're not interested in
I would like to do a python-novaclient release, but this requirements
commit hasn't yet turned into a requirements proposal for novaclient
(that I can find). Can someone poke that for me?
Michael
On Fri, Sep 19, 2014 at 12:04 AM, Doug Hellmann d...@doughellmann.com wrote:
All of the final
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
On Fri, Sep 19, 2014 at 11:13 PM, Sean Dague s...@dague.net 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
Thanks. That's now approved and we're waiting for the merge.
Michael
On Fri, Sep 19, 2014 at 7:30 PM, Andrey Kurilin akuri...@mirantis.com wrote:
Here you are!:)
https://review.openstack.org/#/c/122667
On Fri, Sep 19, 2014 at 9:02 AM, Michael Still mi...@stillhq.com 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 mi...@stillhq.com 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 akuri...@mirantis.com wrote
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
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 mi...@stillhq.com
To: OpenStack Development Mailing List openstack-dev
, 2014 at 09: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 documentation
for when we said we'd do that thing
On Tue, Sep 23, 2014 at 8:58 PM, Daniel P. Berrange berra...@redhat.com 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
for a long time, in favour of wanting
I don't have a problem with any of these requirements, but I'd like to
explore automating the checks. Would it be possible to write a unit
test that verified this for all migrations? Then we don't need to add
it to the checklist...
Michael
On Thu, Dec 19, 2013 at 4:27 AM, Matt Riedemann
On Fri, Dec 20, 2013 at 12:09 PM, Julien Danjou jul...@danjou.info wrote:
On Thu, Dec 19 2013, Sean Dague wrote:
So please look for recent passes before +Aing anything.
What about making that automatic?
Same question for patchset that stays that for a month, finally got
approved and fails
Hi.
So while turbo hipster is new, I've been reading every failure message
it produces to make sure its not too badly wrong. There were four
failures posted last night while I slept:
https://review.openstack.org/#/c/64521
This one is a TH bug. We shouldn't be
mrie...@linux.vnet.ibm.com wrote:
On 12/31/2013 3:58 PM, Michael Still wrote:
Hi.
So while turbo hipster is new, I've been reading every failure message
it produces to make sure its not too badly wrong. There were four
failures posted last night while I slept:
https://review.openstack.org
On Fri, Jan 3, 2014 at 9:24 AM, James E. Blair jebl...@openstack.org wrote:
However, there are _a lot_ of third-party test systems coming on-line,
and I'm not sure that expanding the recheck language to support ever
more complexity is a good idea. I can see how being able to say
recheck foo
On Fri, Jan 3, 2014 at 9:46 AM, Anita Kuno ante...@anteaya.info wrote:
I'd love to attend this chat, if possible. A number of the coming
on-line third-party test systems are motivated by neutron plugins. I'd
get a lot from hearing this discussion.
I've created a BoF on Monday night straight
On Fri, Jan 3, 2014 at 9:39 AM, Michael Still mi...@stillhq.com wrote:
On Fri, Jan 3, 2014 at 9:24 AM, James E. Blair jebl...@openstack.org wrote:
However, there are _a lot_ of third-party test systems coming on-line,
and I'm not sure that expanding the recheck language to support ever
more
apologise for this mis-vote.
Michael
On Wed, Jan 8, 2014 at 1:44 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 12/30/2013 6:21 AM, Michael Still wrote:
Hi.
The purpose of this email to is apologise for some incorrect -1 review
scores which turbo hipster sent out today. I think
Hi!
Sorry the slow response. I've been at a conference this week, so I'm a
bit behind. I apologise for that.
The root cause here is a failure to understand the relatively
undocumented git behaviour of zuul. We think we've now got a fix, and
will deploy it soon.
Michael
On Thu, Jan 9, 2014 at
On Wed, Jan 8, 2014 at 10:48 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
Another question. This patch [1] failed turbo-hipster after it was approved
but I don't know if that's a gating or just voting job, i.e. should someone
do 'reverify migrations' on that patch or just let it sit
On Wed, Jan 8, 2014 at 10:57 PM, Sean Dague s...@dague.net wrote:
[snip]
So instead of trying to fix the individual runs, because t-h runs pretty
fast, can you just fix it with bulk. It seems like the issue in a migration
taking a long time isn't a race in OpenStack, it's completely
You mention some concerns with processutils on that wiki page that I
was unaware of. I can't find bugs for them either. Do you have any
pointers to what is being referred to there?
Thanks,
Michael
On Wed, Jan 15, 2014 at 6:48 AM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
I've spent some
On Wed, Jan 15, 2014 at 8:28 AM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
The notes are from the summit discussion, and I didn't open the bugs. I'll
do that this week. Should I assign them to you?
If you assign them to me I will take a look at them.
Michael
--
Rackspace Australia
On Wed, Jan 15, 2014 at 9:27 AM, Ben Nemec openst...@nemebean.com wrote:
It would be nice to get lockutils graduated to solve some of the issues
mentioned in the oslo.db section, but I believe we do have an outstanding
question regarding its behavior without lock_path being set. I think Clint
On Thu, Jan 16, 2014 at 6:28 AM, John Griffith
john.griff...@solidfire.com wrote:
Hey Everyone,
A while back I started talking about this idea of requiring Cinder
driver contributors to run a super simple cert script (some info here:
[1]). Since then I've been playing with introduction of a
John -- I agree with you entirely here. My concern is more that I
think the CI tests need to run more frequently than weekly.
Michael
On Thu, Jan 16, 2014 at 9:30 AM, John Griffith
john.griff...@solidfire.com wrote:
On Wed, Jan 15, 2014 at 6:03 PM, Michael Still mi...@stillhq.com wrote:
On Thu
On Sat, Jan 25, 2014 at 5:32 AM, Tim Bell tim.b...@cern.ch wrote:
We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to
have MariaDB as the default MySQL-like DB.
Can someone summarise the status of the OpenStack in terms of
-What MySQL-flavor is/are
On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh cbky...@gmail.com wrote:
So if nova-network doesn't go away this has implications for the V3 API as
it currently doesn't support
nova-network. I'm not sure that we have time to add support for it in
icehouse now, but if nova-network is
not
:
Hi Michael,
On 02 Feb 2014, at 06:19 , Michael Still mi...@stillhq.com wrote:
I saw another case of the build succeeded message for a failure just
now... https://review.openstack.org/#/c/59101/ has a rebase failure
but was marked as successful.
Is this another case of hyper-v not being
On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard
matthew.gilli...@gmail.com wrote:
Hello everyone.
wrt these bugs: https://bugs.launchpad.net/nova/+bug/1276203
https://bugs.launchpad.net/nova/+bug/1272830 - I'd just like to make sure
that the approach I'm planning makes sense.
To
On Mon, Feb 10, 2014 at 9:10 AM, CARVER, PAUL pc2...@att.com wrote:
Kyle Mestery wrote:
So, in general I don't think this will fly because it's my understanding the
OpenStack servers only test fully open source code. Allowing a third party
vendor system to run on the OpenStack servers as part of
On Wed, Feb 12, 2014 at 12:40 PM, Devananda van der Veen
devananda@gmail.com wrote:
[snip]
Additionally, the TC has laid out some (draft) graduation requirements [2]
for projects that duplicate functionality in a pre-existing project -- that
means us, since we're supplanting the old Nova
Hi.
For the last day or so I've been chasing
https://bugs.launchpad.net/nova/+bug/1246201, and I think I've found
the problem... libvirt doesn't migrate devices of type cdrom, even if
they're virtual. If I change the type of the config drive to disk,
then block migration works just fine.
Does
On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange berra...@redhat.com wrote:
So I'd saying changing it to 'disk' is out of the question unless
we unconditionally use vfat as the filesystem instead of iso9660.
So, at the moment we conflate a flag about format (iso9660 or vfat)
with a flag
On Tue, Feb 18, 2014 at 3:14 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Tue, Feb 18, 2014 at 03:08:59AM -0700, Michael Still wrote:
On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange berra...@redhat.com
wrote:
So I'd saying changing it to 'disk' is out of the question unless
we
On Fri, Feb 28, 2014 at 6:34 AM, yunhong jiang
yunhong.ji...@linux.intel.com wrote:
Greeting,
I have some questions on the force_config_drive configuration options
and hope get some hints.
a) Why do we want this? Per my understanding, if the user want to use
the config drive,
I think we should also acknowledge that part of the problem here is
that whilst the Hyper-V CI ran on this patch (and failed), its not
very obvious when you look at gerrit. I would say the solution to that
is to turn voting on, but the Hyper-V CI fail rate is about twice that
of Jenkins at the
I think its also pretty unfair on the people who put a lot of work
into the v3 API. We're seriously going to delete their code after they
put a year into it?
To me OpenStack isn't just the users, its also the development
community. I think we do measurable harm to that development community
by
On Tue, Mar 4, 2014 at 4:32 AM, Russell Bryant rbry...@redhat.com wrote:
There has been quite a bit of discussion about the future of the v3 API
recently. There has been growing support for the idea that we should
change course and focus on evolving the existing v2 API instead of
putting out
On Tue, Mar 4, 2014 at 10:50 AM, Andrew Laski
andrew.la...@rackspace.com wrote:
Totally understand. But I would contend that it's because v3 is mostly
minor changes that we're even having this conversation.
In all fairness, that's because that's what we asked them to do when
we approved the
1 - 100 of 467 matches
Mail list logo
