What would be the best practice for those who realize their work will not
make it in Juno? Is it enough to not submit code for review? Would it be
better to also request a change in milestone?
Thanks,
Mohammad
From: Kyle Mestery mest...@mestery.com
To: OpenStack Development Mailing
Hi,
I think we are debating some edge-case. An important part of the flavor
framework is the ability of me the operator to say failover from Octavia to an
F5. So as an operator I would ensure to only offer the features in that flavor
which both support. So in order to arrive at Brandon’s
Do u know if ceilometer is using six.wraps?
If so, that helper adds in the `__wrapped__` attribute to decorated
methods (which can be used to find the original decorated function).
If just plain functools are used (and python3.x isn't used) then it
will be pretty hard afaik to find the
On 11 August 2014 21:03, Dean Troyer dtro...@gmail.com wrote:
On Mon, Aug 11, 2014 at 5:34 PM, Duncan Thomas duncan.tho...@gmail.com
wrote:
Making an previously mandatory parameter optional, at least on the
command line, does break backward compatibility though, does it?
Everything that
This should give you what you need:
from pecan.core import state
state.controller
On 08/12/14 04:08 PM, Pendergrass, Eric wrote:
Hi, I'm trying to use the built in secure decorator in Pecan for access
control, and I'ld like to get the name of the method that is wrapped from
within the
If this plugin will be deprecated in Juno it means that the code will be
there for this release, I will expect to have the CI still running for
until the code is completely removed from the Neutron tree.
Anyway, Infra guys will have the last word here!
Edgar
On 8/11/14, 5:38 PM, Anita Kuno
Thanks Ryan, but for some reason the controller attribute is None:
(Pdb) from pecan.core import state
(Pdb) state.__dict__
{'hooks': [ceilometer.api.hooks.ConfigHook object at 0x31894d0,
ceilometer.api.hooks.DBHook object at 0x3189650,
ceilometer.api.hooks.PipelineHook object at 0x39871d0,
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 considering how to approach the fact
that we now need to track one more thing (NUMA node
If you know it won't make it, please let me know so I can remove your BP
from the LP milestone.
Thanks!
Kyle
On Tue, Aug 12, 2014 at 11:18 AM, Mohammad Banikazemi m...@us.ibm.com wrote:
What would be the best practice for those who realize their work will not
make it in Juno? Is it enough to
On Tue, Aug 12, 2014 at 10:30 AM, Yee, Guang guang@hp.com wrote:
Hi Kristy,
Have you try the [] or @ rule as mentioned here?
That still requires valid authentication though, just not any specific
authorization. I don't think we have a way to express truly public
resources in oslo.policy.
Can you share some code? What do you mean by, is there a way for the
decorator code to know it was called by MetersController.get_all
On 08/12/14 04:46 PM, Pendergrass, Eric wrote:
Thanks Ryan, but for some reason the controller attribute is None:
(Pdb) from pecan.core import state
(Pdb)
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez
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.
What... does that even mean?
Yeah,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/08/14 17:12, Henry Gessau wrote:
On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote:
as per [1], Cisco Nexus ML2 plugin requires a patched version of
ncclient from github. I wonder:
- - whether this information is still current;
Please
On Tue, Aug 12, 2014 at 03:56:44PM +0100, Mark McLoughlin wrote:
Hey
(Terrible name for a policy, I know)
From the version_cap saga here:
https://review.openstack.org/110754
I think we need a better understanding of how to approach situations
like this.
Here's my attempt at
On 2014-08-12 16:35:18 + (+), Edgar Magana wrote:
If this plugin will be deprecated in Juno it means that the code
will be there for this release, I will expect to have the CI still
running for until the code is completely removed from the Neutron
tree.
Anyway, Infra guys will have
On Aug 12, 2014, at 1:44 PM, Dolph Mathews dolph.math...@gmail.com wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon joe.gord...@gmail.com
And just when the patch was only missing a +A, another bug slipped in!
The nova patch to fix it is available at [1]
And while we're there, it won't be a bad idea to also push the neutron full
job, as non-voting, into the integrated gate [2]
Thanks in advance,
(especially to the nova and infra
On Tue, Aug 12, 2014 at 10:44 AM, Dolph Mathews dolph.math...@gmail.com wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote:
Slow review: by limiting the number of blueprints up we hope to focus our
efforts on fewer concurrent things
slow code turn around: when a
On Aug 12, 2014, at 11:08 AM, Doug Hellmann d...@doughellmann.com wrote:
On Aug 12, 2014, at 1:44 PM, Dolph Mathews dolph.math...@gmail.com wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery
It came to my attention today that I've only communicated this in Horizon
team meetings.
Due to the high number of blueprints already targeting Juno-3 and the
resource contention of reviewers, I have set the Horizon Feature Proposal
Deadline at August 14 (August 12 actually, but since I didn't
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 turnaround
On 8/12/2014 1:53 PM, Ihar Hrachyshka wrote:
On 12/08/14 17:12, Henry Gessau wrote:
On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote:
as per [1], Cisco Nexus ML2 plugin requires a patched version of
ncclient from github. I wonder:
- - whether this information is still current;
Please see:
Sure, here's the decorated method from v2.py:
class MetersController(rest.RestController):
Works on meters.
@pecan.expose()
def _lookup(self, meter_name, *remainder):
return MeterController(meter_name), remainder
@wsme_pecan.wsexpose([Meter],
On 8/12/2014 2:04 PM, Jeremy Stanley wrote:
On 2014-08-12 16:35:18 + (+), Edgar Magana wrote:
If this plugin will be deprecated in Juno it means that the code
will be there for this release, I will expect to have the CI still
running for until the code is completely removed from the
On 08/12/2014 04:13 AM, Michael Still 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
so that we can defer it until Kilo. That
Henry,
That makes a lot of sense to me.
If the code will be remove in Juno, then there is nothing else to discuss.
Thank you so much for providing detailed information and sorry for
bothering you with this issue.
Edgar
On 8/12/14, 11:49 AM, Henry Gessau ges...@cisco.com wrote:
On 8/12/2014
On Tue, Aug 12, 2014 at 1:08 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 12, 2014, at 1:44 PM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com
wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery
Hi Mark,
Going through the notes from our midcycle meeting (see
https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon) I noticed your
name next to the Service Port and IPAM:
Service Ports
* Owner: Mark
* Nova hacks
* Nova port that nova borrows but doesn't
From the perspective of Blue Box:
* Load balancing appliances will often (usually?) live outside the same
subnet as back-end member VMs.
* The network in which the load balancing appliances live will usually have
a default router (gateway)
* We don't anticipate the need for using extra_routes at
On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote:
On 08/11/2014 07:58 AM, Russell Bryant wrote:
On 08/11/2014 05:53 AM, Daniel P. Berrange wrote:
There is work to add support for this in devestack already which I
prefer since it makes it easy for developers to get an
Hi all,
I am not available to run the meeting tomorrow and was not able to identify
someone to step in, given this I think it makes sense to cancel for this week.
For next week I would like to trial the new alternate time we discussed, 1600
UTC on a Thursday, and assuming there is reasonable
Hi folks!
This is what I have for my tentative agenda for tomorrow's Octavia meeting.
Please e-mail me if you want anything else added to this list. (Also, I
will start putting these weekly agendas in the wiki in the near future.)
* Discuss future of Octavia in light of Neutron-incubator project
On 08/12/2014 01:16 PM, Edgar Magana wrote:
Henry,
That makes a lot of sense to me.
If the code will be remove in Juno, then there is nothing else to discuss.
Thank you so much for providing detailed information and sorry for
bothering you with this issue.
Edgar
I don't think it is a
On 08/12/2014 03:40 PM, Kashyap Chamarthy wrote:
On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote:
On 08/11/2014 07:58 AM, Russell Bryant wrote:
On 08/11/2014 05:53 AM, Daniel P. Berrange wrote:
There is work to add support for this in devestack already which I
prefer since it
Dan Smith wrote:
Looks reasonable to me.
+1
+1
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 considering how to approach the fact
that we now
On Tue, Aug 12, 2014 at 9:56 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
(Terrible name for a policy, I know)
From the version_cap saga here:
https://review.openstack.org/110754
I think we need a better understanding of how to approach situations
like this.
Here's my attempt at
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
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 libvirt is
doable on most environments, do we want to do that now?
On Tue, Aug 12, 2014 at 11:08 AM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 12, 2014, at 1:44 PM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com
wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery
On Wed, 2014-07-30 at 14:02 -0700, 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 there are
On 11/08/14 20:42, david ferahi wrote:
Hello,
I 'm trying to create a simple stack with heat (Icehouse release).
The template contains SoftwareConfig, SoftwareDeployment and a single
server resources.
The problem is that the SoftwareDeployment resource is always in
progress !
So first I'm
Kyle,
One Convergence third-party CI is failing due to
https://bugs.launchpad.net/neutron/+bug/1353309.
Let me know if we should turn off the CI logs until this is fixed or if we
need to fix anything on the CI end. I think one other third-party CI
(Mellanox) is failing due to the same issue.
Should subsequent patches be reverted as well that depended on the change
in question?
On Tue, Aug 12, 2014 at 7:56 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
(Terrible name for a policy, I know)
From the version_cap saga here:
https://review.openstack.org/110754
I think we
On 08/12/2014 03:23 PM, Hemanth Ravi wrote:
Kyle,
One Convergence third-party CI is failing due to
https://bugs.launchpad.net/neutron/+bug/1353309.
Let me know if we should turn off the CI logs until this is fixed or if we
need to fix anything on the CI end. I think one other third-party
Thanks Eric for the confirmation ;-)
2014-08-12 23:30 GMT+08:00 Eric Windisch ewindi...@docker.com:
On Tue, Aug 12, 2014 at 5:53 AM, Jay Lau jay.lau@gmail.com wrote:
I did not have the environment set up now, but by reviewing code, I think
that the logic should be as following:
1)
Yep, you're right, this doesn't seem to work. The issue is that security is
enforced at routing time (while the controller is still actually being
discovered). In order to do this sort of thing with the `check_permissions`,
we'd probably need to add a feature to pecan.
On 08/12/14 06:38 PM,
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
port: 8775
net_binds: *public_binds
hi,
As announced in the last neutron meeting [1], the Ryu plugin is
being deprecated. Juno is the last release to support Ryu plugin.
The Ryu team will be focusing on the ofagent going forward.
btw, i'll be mostly offline from Aug 16 to Aug 31.
sorry for inconvenience.
[1]
On 8/6/14, 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote:
Hi, folks!
Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails
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
On 12 August 2014 10:46, Robert Collins robe...@robertcollins.net wrote:
On 12 August 2014 07:24, Dan Prince dpri...@redhat.com wrote:
On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote:
Hi, so shortly after the HOT migration landed, we hit
https://bugs.launchpad.net/tripleo/+bug/1354305
On 13 August 2014 11:05, Robert Collins robe...@robertcollins.net wrote:
I've reproduced the problem with zane's fix for the validation error -
and it does indeed still break:
| stack_status_reason | StackValidationFailed: Property error :
NovaCompute6:
| | key_name
Eric,
If you can give us some more information about your end goal, independent of
the implementation, maybe we can propose an alternate technique to achieve the
same thing.
Doug
On Aug 12, 2014, at 6:21 PM, Ryan Petrello ryan.petre...@dreamhost.com wrote:
Yep, you're right, this doesn't
On Tue, Aug 12, 2014 at 12:23 AM, Mark McLoughlin mar...@redhat.com wrote:
On Mon, 2014-08-11 at 15:25 -0700, Joe Gordon wrote:
On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin mar...@redhat.com
wrote:
On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote:
On
I forked jaypipe’s repos working on extending it to support nodepool, log
server, etc.
Still WIP but generally working.
If you need help, ping me on IRC #openstack-cinder (asselin)
Ramy
From: Jesse Pretorius [mailto:jesse.pretor...@gmail.com]
Sent: Monday, August 11, 2014 11:33 PM
To:
Hi,
VMware minesweeper caused havoc today causing exhaustion of the upstream
node pool.
The account has been disabled so things are back to normal now.
The root cause of the issue was super easy once we realized we missed [1].
I would like to apologise to the whole community on behalf of the
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 choices:
(1) deter to activate the py33 gate
I am also highly interested. A very large adoption inhibitor has been the
ability to control cloud consumption with charge-back and/or cost center
billing support. Would love to talk about this.
*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Something was presented at a meeting recently which had me curious: what
sort of capacity planning tools/capabilities are being developed as an
Openstack program? It's another area where non-proprietary cloud control is
needed and would be another way to kick a peg away from the stool of cloud
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 8/12/2014 4:03 PM, Michael Still 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?
Michael
On Wed, Aug 13, 2014 at 12:56 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
(Terrible
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?
In an extreme case, the PTL has the authority to make the call.
In
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
Anita,
Yes, I'm the contact for One Convergence CI.
Thanks,
-hemanth
On Tue, Aug 12, 2014 at 3:12 PM, Anita Kuno ante...@anteaya.info wrote:
On 08/12/2014 03:23 PM, Hemanth Ravi wrote:
Kyle,
One Convergence third-party CI is failing due to
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
401 - 500 of 118978 matches
Mail list logo
