Hi Gary,
I understand your concern. I think CI is mandatory to ensure that code is not
broken. While unit tests provide great value, it may end up with the code that
does not work...
I am not sure how this code can be checked for validity without running the
neutron part.
Probably our CI job
Hi,
nova --os-tenant-name admin list --tenant c40ad5830e194f2296ad11a96cefc487
--all-tenants 1 - Works Fine and returns all the servers available where
c40ad5830e194f2296ad11a96cefc487 is the id of the demo tenant whereas
nova --os-tenant-name admin list --tenant demo --all-tenants 1 -
Hi,
Mellanox CI was also failing due to the same issue,
https://bugs.launchpad.net/neutron/+bug/1355780 (apparently duplicated bug for
https://bugs.launchpad.net/neutron/+bug/1353309)
We currently fixed the issue locally, by patching the server side RPC version
support to 1.3.
BR,
Irena
this spec has some thought on functionality to validate the tenant or user
that is consumed by nova, not sure whether it's what you want, FYI
https://review.openstack.org/#/c/92507/
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet:
Like the policy-group naming.
The policy-target is better than policy-point, but still feel there's some
little confusing, as the target is usually meaning what it's for, but not
what it's on.
Hence, the policy-endpoint might be more exact.
On Fri, Aug 8, 2014 at 11:43 PM, Jay Pipes
Hi,
If I understand correctly the only way that this work is with nova and neutron
running. My understanding would be to have the CI running with this as the
configuration. I just think that this should be a prerequisite similar to
having validations of virtualization drivers.
Does that make
I'm doing various small cleanup changes as I explore the neutron codebase.
Some of these cleanups are to fix actual bugs discovered in the code. Almost
all of them are tiny and obviously correct.
A recurring reviewer comment is that the change should have had an
accompanying bug report and
I'm not sure what the guideline is, but I would like to point out a good
reason to have the bug report even for obvious fixes.
When users encounters bugs, they go to launchpad to report them. They don't
first scan the commits of the master branch to see what was fixed. Having
the bug in launchpad
On Wed, Aug 13 2014, Osanai, Hisashi wrote:
On Tuesday, August 12, 2014 10:14 PM, Julien Danjou wrote:
The py33 gate shouldn't be activated for the stable/icehouse. I'm no
infra-config expert, but we should be able to patch it for that (hint?).
Thank you for the response.
Now we have two
Our initial goal is to just split the scheduler out into a separate project,
not make it a part of Nova compute. The functionality will be exactly the same
as the Nova scheduler (the vast majority of the code will be a copy of the Nova
scheduler code modulo some path name changes). When the
Generally, I agree with you. But it's a little tricky.
There are different types of SR-IOV NICs and what will work for some vendor may
be broken for another.
I think that both current SR-IOV networking flavors: Embedded switching (Intel,
Mellanox) and Cisco VM-FEX should be verified for relevant
One thing I'm not seeing shine through in this discussion of slots is
whether any notion of individual cores, or small subsets of the core
team with aligned interests, can champion blueprints that they have
a particular interest in.
I think that's because we've focussed in this
On 08/13/2014 04:05 AM, Michael Still wrote:
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
Hello,
I have currently setup the Scality CI not to report (mostly because it
isn't fully functionnal yet, as the machine it runs on turns out to be
undersized and thus the tests fails on some timeout), partly because
it's currently a nightly build. I have no way of testing multiple
patchsets at
On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote:
On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:
On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:
On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:
While forcing people to move to a newer version of
Hello.
I am writing a tempest scenario for keystone. In this scenario I create a
domain, project and a user with admin rights on the project. I then try to
instantiate a Manager so I can call keystone using the new user credentials:
creds =
Nikola Đipanov wrote:
While I agree with motivation for this - setting the expectations, I
fail to see how this is different to what the Swift guys seem to be
doing apart from more red tape.
It's not different imho. It's just that nova as significantly more
features being thrown at it, so the
Rochelle.RochelleGrober wrote:
[...]
So, with all that prologue, here is what I propose (and please consider
proposing your improvements/changes to it). I would like to see for Kilo:
- IRC meetings and mailing list meetings beginning with Juno release and
continuing through the summit
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 13/08/14 09:28, Angus Lees wrote:
I'm doing various small cleanup changes as I explore the neutron
codebase. Some of these cleanups are to fix actual bugs discovered
in the code. Almost all of them are tiny and obviously correct.
A
Hi Fuelers,
I'd like to clarify 5.0.2 state. This is not planned to be an official ISO
with 5.0.2, but rather it's going to be a set of packages and manifests,
which represent bugfixes on bugs reported to 5.0.2 milestone in LP [1].
5.0.2 is going to be cut in stable/5.0 at the same time as 5.1 is
Le 13/08/2014 03:48, Fei Long Wang a écrit :
Hi Adam,
Please refer this https://wiki.openstack.org/wiki/Blazar. Hope it's
helpful. Cheers.
On 13/08/14 12:54, Adam Lawson wrote:
Something was presented at a meeting recently which had me curious:
what sort of capacity planning
On Wednesday, August 13, 2014 5:03 PM, Julien Danjou wrote:
This is not a problem in tox.ini, this is a problem in the
infrastructure config. Removing py33 from the envlist in tox.ini isn't
going to fix anything unforunately.
Thank you for your quick response.
I may misunderstand this topic.
On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
I really like this idea, as Michael and others alluded to in above, we
are
attempting to set cycle goals for Kilo in Nova. but I think it is worth
doing
I've been working on this for OpenDaylight
https://github.com/dave-tucker/odl-neutron-drivers
This seems to work for me (tested Devstack w/ML2) but YMMV.
-- Dave
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 08/07/2014 12:56 PM, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez
thie...@openstack.org wrote:
We seem to be unable to address some key issues in the software
Hisashi Osanai, I have really strange feeling about this issue.
It happens only with py33 job for icehouse branch? Because actually happy
base is the same for the master code Jenkins jobs, so it looks like that
exec file issue should appear in master runs as well... Do I understand
everything
Le 12/08/2014 22:06, Sylvain Bauza a écrit :
Le 12/08/2014 18:54, Nikola Đipanov a écrit :
On 08/12/2014 04:49 PM, Sylvain Bauza wrote:
(sorry for reposting, missed 2 links...)
Hi Nikola,
Le 12/08/2014 12:21, Nikola Đipanov a écrit :
Hey Nova-istas,
While I was hacking on [1] I was
On Wed, Aug 13 2014, Osanai, Hisashi wrote:
One idea to solve this problem is:
If the py33 doesn't need to execute on stable/icehouse, just eliminate
the py33.
Yes, that IS the solution.
But modifying tox.ini is not going be a working implementation of that
solution.
This is not a problem
Hi,
this discussion came up recently regarding a nodepool issue.
The blueprint was recently revived and there is a proposed specification [1]
I tend to disagree with the way nova implements this feature today.
A configuration-wide flag indeed has the downside that this creates
different API
On Wed, Aug 13 2014, Dina Belova wrote:
Hisashi Osanai, I have really strange feeling about this issue.
It happens only with py33 job for icehouse branch? Because actually happy
base is the same for the master code Jenkins jobs, so it looks like that
exec file issue should appear in master
Julien, will do right now.
Thanks
Dina
On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou jul...@danjou.info wrote:
On Wed, Aug 13 2014, Osanai, Hisashi wrote:
One idea to solve this problem is:
If the py33 doesn't need to execute on stable/icehouse, just eliminate
the py33.
Yes, that IS
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez thie...@openstack.org
wrote:
We seem to be unable to address some key
Here it is: https://review.openstack.org/#/c/113842/
Thanks,
Dina
On Wed, Aug 13, 2014 at 2:40 PM, Dina Belova dbel...@mirantis.com wrote:
Julien, will do right now.
Thanks
Dina
On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou jul...@danjou.info wrote:
On Wed, Aug 13 2014, Osanai,
Hello,
Thank you Steve for your reply !
Yes I'm using the same manual you provided to create my image.
https://github.com/openstack/heat-templates/tree/master/hot/software-config/elements
In my network configuration, the tenant network is created in the same
subnet as OpenStack Management
Hi,
The important thing to understand is how to integrate with neutron through
stevedore/entrypoints:
https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34
Cedric
On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote:
I've been working on this
One thing to keep in mind is that the ML2 driver API does sometimes
change, requiring updates to drivers. Drivers that are in-tree get
updated along with the driver API change. Drivers that are out-of-tree
must be updated by the owner.
-Bob
On 8/13/14, 6:59 AM, ZZelle wrote:
Hi,
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
several periodic checks for havana are failing due to missing
libffi-devel or missing rpm/yum tools on bare-centos (sic!) node.
For example, see [1] (rpm/yum missing) and [2] (compile failure due to
missing libffi-devel).
AFAIK there is a
On Tue, 2014-08-05 at 18:03 +0200, Thierry Carrez wrote:
Hi everyone,
With the incredible growth of OpenStack, our development community is
facing complex challenges. How we handle those might determine the
ultimate success or failure of OpenStack.
With this cycle we hit new limits in our
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez
Matt,
On Mon, Aug 11, 2014 at 07:06:11PM -0400, Zane Bitter wrote:
On 11/08/14 16:21, Matthew Treinish wrote:
I'm sorry, but the fact that the
docs in the rally tree has a section for user testimonials [4] I feel
speaks a
lot about the intent of the project.
Yes, you are absolutely
On 12/08/14 01:06, Steve Baker wrote:
On 09/08/14 11:15, Zane Bitter wrote:
On 08/08/14 11:07, Tomas Sedovic wrote:
On 08/08/14 00:53, Zane Bitter wrote:
On 07/08/14 13:22, Tomas Sedovic wrote:
Hi all,
I have a ResourceGroup which wraps a custom resource defined in
another
template:
On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
That said, I entirely agree with you and wish efforts to stabilize would
take precedence over
Hi Nikola,
Thanks a lot for the input! May I kindly invite you to review the change
as well?
BR/Liyi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thu, 2014-08-07 at 09:30 -0400, Sean Dague wrote:
While I definitely think re-balancing our quality responsibilities back
into the projects will provide an overall better release, I think it's
going to take a long time before it lightens our load to the point where
we get more breathing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 13/08/14 14:07, Daniel P. Berrange wrote:
On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange
wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
That said,
On 08/12/2014 06:57 PM, Michael Still wrote:
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.
Note that we also have:
https://wiki.openstack.org/wiki/Nova/CoreTeam
so once
On 08/12/2014 10:05 PM, Michael Still wrote:
there are hundreds of proposed features for
Juno, nearly 100 of which have been accepted. However, we're kidding
ourselves if we think we can land 100 blueprints in a release cycle.
FWIW, I think this is actually huge improvement from previous
On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:
On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor mord...@inaugust.com wrote:
Yes.
Additionally, and I think we've been getting better at this in the 2 cycles
that we've had an all-elected TC, I think we need to learn how to
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn 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
blueprints
On 08/13/2014 05:57 AM, Daniel P. Berrange wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
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
On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
I really like this idea, as Michael and others alluded to in above, we
are
A big +1 to what daniel said,
If f2f events are becoming so important the only way to get things
done, IMHO we should really start to do some reflection on how our
community operates and start thinking about what we are doing wrong.
Expecting every company to send developers (core or
On Wed, Aug 13, 2014 at 7:55 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/13/2014 05:57 AM, Daniel P. Berrange wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of
On Tue, 2014-08-12 at 14:12 -0700, Joe Gordon wrote:
Here is the full nova proposal on Blueprint in Kilo: Runways and
Project Priorities
https://review.openstack.org/#/c/112733/
http://docs-draft.openstack.org/33/112733/4/check/gate-nova-docs/5f38603/doc/build/html/devref/runways.html
On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn 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
On Wed, Aug 13, 2014 at 09:11:26AM -0400, Russell Bryant wrote:
On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating
Daniel P. Berrange [mailto:berra...@redhat.com] wrote:
our dispersed contributor base. I think that we should be examining
what we can achieve with some kind of virtual online mid-cycle meetups
instead. Using technology like google hangouts or some similar live
collaboration technology, not
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
blueprints queue up to get a slot based on priorities and
On Wed, Aug 13, 2014 at 5:37 AM, Mark McLoughlin mar...@redhat.com
wrote:
On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:
On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor
mord...@inaugust.com wrote:
Yes.
Additionally, and I think we've been getting better at this in
We are very pleased at Objectif Libre to intoduce CloudKitty, an effort
to provide a fully OpenSource Rating-as-a-Service component in
OpenStack..
Following a first POC presented during the last summit in Atlanta to
some Ceilometer devs (thanks again Julien Danjou for your great support
!),
Excerpts from Thierry Carrez's message of 2014-08-13 02:54:58 -0700:
Rochelle.RochelleGrober wrote:
[...]
So, with all that prologue, here is what I propose (and please consider
proposing your improvements/changes to it). I would like to see for Kilo:
- IRC meetings and mailing list
On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com
wrote:
I really like this idea, as Michael and others alluded to in
above, we
are
attempting to set cycle goals for Kilo in Nova. but I think it is
Lee,
No problem about mixing up the Mike's, there's a bunch of us out there :-).
What are you are describing here is very much like a spec I wrote for
Nova[1] a couple months ago and then never got back to. At the time I
considered gearing the feature toward oslo.db and I can't remember exactly
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the weekly Neutron meeting would be a good
thing. This will allow for a much easier time for people in
Asia/Pacific timezones, as well as for people in Europe.
So, I'd like to propose we rotate the
Sorry for the short notice, but lets cancel today's parity meeting.
We're still circling the wagons around the migration story at this
point, so hopefully next week we'll have more to discuss there.
Thanks,
Kyle
___
OpenStack-dev mailing list
+1
PCM (Paul Michali)
MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
On Aug 13, 2014, at 10:05 AM, Kyle Mestery mest...@mestery.com wrote:
Per this week's Neutron
On 13 August 2014 06:01, Kyle Mestery mest...@mestery.com wrote:
On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange berra...@redhat.com
wrote:
This idea of fixed slots is not really very appealing to me. It sounds
like we're adding a significant amount of buerocratic overhead to our
On 2014-08-13 02:40:28 +0200 (+0200), Salvatore Orlando wrote:
[...]
Finally, I have noticed the old grammar is still being used by
other 3rd party CI. I do not have a list of them, but if you run a
3rd party CI, and this is completely new to you then probably you
should look at the syntax for
Huge +1
On 8/13/14, 5:19 PM, Paul Michali (pcm) p...@cisco.com wrote:
+1
PCM (Paul Michali)
MAIL Š..Š. p...@cisco.com
IRC ŠŠ..Š pcm_ (irc.freenode.com)
TW ŠŠŠ... @pmichali
GPG Key Š 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
On Aug 13, 2014, at 10:05
On 2014-08-13 02:40:28 +0200 (+0200), Salvatore Orlando wrote:
[...]
The problem has now been fixed, and once the account will be
re-enabled, rechecks should be issued with the command
vmware-recheck.
[...]
Oh, I meant to add that I've reenabled the account now. Thanks for
the rapid response
This is fantastic, thank you.
- Original Message -
+1
PCM (Paul Michali)
MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
On Aug 13, 2014, at 10:05
+1 and Like
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Wednesday, August 13, 2014 8:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev]
On 13/08/14 17:05, Kyle Mestery wrote:
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the weekly Neutron meeting would be a good
thing. This will allow for a much easier time for people in
Asia/Pacific timezones, as well as for people in Europe.
* we had replied to your email to rcbau, let me know if you didn't
receive that in-case there is something wrong with our emails
Rackspace Australia
Thanks for your reply. I do not seem to have received your reply to
my original message. Not sure what happened. I'll admit that it is
The meeting for today is canceled. Sorry for the short notice.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wed, 2014-08-13 at 10:26 +0100, Daniel P. Berrange wrote:
On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote:
On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:
On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:
On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon
Thanks very much Jeremy for getting us back up and running again. Without a
doubt, we will be triggering directly from the CI system itself next time the
need to do a mass recheck arises. The lesson was learned seconds after the
script was run!
Again, my sincere apologies for all the havoc
I am gonna add more color to this story by posting my replies on review [1]:
Hi Angus,
You touched on a number of points. Let me try to give you an answer to all
of them.
(I'll create a bug report too. I still haven't worked out which class of
changes need an accompanying bug report and which
like it! +1
Fawad Khaliq
On Wed, Aug 13, 2014 at 7:58 AM, mar...@redhat.com mandr...@redhat.com
wrote:
On 13/08/14 17:05, Kyle Mestery wrote:
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the weekly Neutron meeting would be a good
thing.
On Wed, Aug 13, 2014 at 04:24:57PM +0100, Mark McLoughlin wrote:
On Wed, 2014-08-13 at 10:26 +0100, Daniel P. Berrange wrote:
On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote:
On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:
On Wed, Jul 30, 2014, at 03:23 PM, Jeremy
__In review and merged this past week__
We're cleaning up the Architecture Design Guide continually and I got my
proof copy yesterday. The green cover is lovely as part of the set. The
interior PDF is made the master branch from today and you can get those
print copies rolling!
The landing page
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
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
Le 13/08/2014 12:21, Sylvain Bauza a écrit :
Le 12/08/2014 22:06, Sylvain Bauza a écrit :
Le 12/08/2014 18:54, Nikola Đipanov a écrit :
On 08/12/2014 04:49 PM, Sylvain Bauza wrote:
(sorry for reposting, missed 2 links...)
Hi Nikola,
Le 12/08/2014 12:21, Nikola Đipanov a écrit :
Hey
On Tue, 2014-07-29 at 14:04 +0200, Thierry Carrez wrote:
Ihar Hrachyshka a écrit :
On 29/07/14 12:15, Daniel P. Berrange wrote:
Looking at the current review backlog I think that we have to
seriously question whether our stable branch review process in
Nova is working to an acceptable
On Wed, Aug 13, 2014 at 09:01:59AM -0700, Maru Newby wrote:
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
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
My apologies, I managed to break the thread here. Please respond to the thread
with subject 'Re: [openstack-dev] [nova][core] Expectations of core reviewers'
in preference to this one.
Maru
On Aug 13, 2014, at 9:01 AM, Maru Newby ma...@redhat.com wrote:
On Aug 13, 2014, at 2:57 AM,
Hello Udi,
I don't see anything wrong in principle with your code.
This said, the main use case I had in mind when I wrote the auth providers
and credentials classes was to abstract authentication for all tests, so
that it is possible to configure and target identity api version to be used
for
On Wed, Aug 13, 2014 at 09:18:09AM -0700, Maru Newby wrote:
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make
I remember infra team objected to the nightly builds. They wanted reports on
every patch set in order to report to gerrit.
In the short-term, I suggest you test on every patch set, but limit the
resources. This will cause 'long delays' but jobs will eventually go through.
In the long-term,
If you limit yourself to only testing once jenkins has put a +1 on,
then you can down a bit... Not sure how to build that into Jay Pipe's
pipeline though
On 13 August 2014 10:30, Asselin, Ramy ramy.asse...@hp.com wrote:
I remember infra team objected to the nightly builds. They wanted reports on
On 08/12/2014 05:21 PM, Robert Collins wrote:
Just ran into a merge conflict with
https://review.openstack.org/#/c/105878/ which looks like this:
- name: nova_osapi
port: 8774
net_binds: *public_binds
- name: nova_metadata
On Aug 12, 2014, at 5:21 AM, Nikola Đipanov ndipa...@redhat.com wrote:
Hey Nova-istas,
While I was hacking on [1] I was considering how to approach the fact
that we now need to track one more thing (NUMA node utilization) in our
resources. I went with - I'll add it to compute nodes table
+1
- Original Message -
like it! +1
Fawad Khaliq
On Wed, Aug 13, 2014 at 7:58 AM, mar...@redhat.com mandr...@redhat.com
wrote:
On 13/08/14 17:05, Kyle Mestery wrote:
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the
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 well with much less f2f time and a far
smaller % of their
Huge +1
On Wed, Aug 13, 2014 at 11:05 PM, Kyle Mestery mest...@mestery.com wrote:
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the weekly Neutron meeting would be a good
thing. This will allow for a much easier time for people in
Asia/Pacific
Le 13/08/2014 18:40, Brian Elliott a écrit :
On Aug 12, 2014, at 5:21 AM, Nikola Đipanov ndipa...@redhat.com wrote:
Hey Nova-istas,
While I was hacking on [1] I was considering how to approach the fact
that we now need to track one more thing (NUMA node utilization) in our
resources. I went
On Wed, Aug 13, 2014 at 2:01 AM, Nikola Đipanov ndipa...@redhat.com wrote:
On 08/13/2014 04:05 AM, Michael Still wrote:
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
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 cores will have to send more or make
some hard decisions, but I don't want
1 - 100 of 193 matches
Mail list logo
