A temporary workaround waiting fix for bug:
https://bugs.launchpad.net/nova/+bug/1112912
(https://review.openstack.org/#/c/21946/)
diff --git a/nova/virt/libvirt/vif.py b/nova/virt/libvirt/vif.py
index 5bf0dba..5fd041c 100644
--- a/nova/virt/libvirt/vif.py
+++ b/nova/virt/libvirt/vif.py
@@ -159,7
On 2013年11月27日 23:43, Jeremy Stanley wrote:
On 2013-11-27 11:18:46 +0800 (+0800), yongli he wrote:
[...]
if you post -1, you should post testing log somewhere for people
to debug it, so does third party testing can post testing log to
the infra log server?
Not at the moment--the "infra log serv
On 2013/28/11 06:41, Robert Collins wrote:
Certainly. Do we have Personas for those people? (And have we done any
validation of them?)
We have shorter paragraph to each. But not verified by any survey, so we
don't have very solid basis in this area right now and I believe we all
are trying to
Hello,
just few notes from me:
https://etherpad.openstack.org/p/tripleo-feature-map sounds like a great
idea, we should go through them one by one maybe on meeting.
We should agree on what is doable for I, without violating the Openstack
way in some very ugly way. So do we want to be Openstack
Hi Mark,
thanks for your insight, I mostly agree. Just few points below.
On 2013/27/11 21:54, Mark McLoughlin wrote:
Hi Jarda,
...
Yes, I buy this. And I think it's the point worth dwelling on.
It would be quite a bit of work to substantiate the point with hard data
- e.g. doing user testing
Hello Daisy,
the tables were deleted from Horizon, because of that confusion.
https://bugs.launchpad.net/horizon/+bug/1249279
We are going to clearly document each ceilometer meter first. Then this
information will appear again in Horizon.
E.g. the duration as stated in doc
http://docs.opens
On 2013/27/11 16:37, James Slagle wrote:
On Wed, Nov 27, 2013 at 8:39 AM, Jaromir Coufal wrote:
V0: basic slick installer - flexibility and control first
- enable user to auto-discover (or manual register) nodes
- let user decide, which node is going to be controller, which is going to
be comp
On Wed, Nov 27, 2013 at 05:29:35PM -0500, Sean Dague wrote:
> On 11/27/2013 01:32 PM, Rafał Jaworowski wrote:
> > On Mon, Nov 25, 2013 at 3:50 PM, Daniel P. Berrange
> > wrote:
> >> On Fri, Nov 22, 2013 at 10:46:19AM -0500, Russell Bryant wrote:
> >>> On 11/22/2013 10:43 AM, Rafał Jaworowski wrot
On Wed, Nov 27, 2013 at 07:34:15PM +, Daniel P. Berrange wrote:
> On Wed, Nov 27, 2013 at 06:43:42PM +, Edward Hope-Morley wrote:
> > On 27/11/13 18:20, Daniel P. Berrange wrote:
> > > On Wed, Nov 27, 2013 at 06:10:47PM +, Edward Hope-Morley wrote:
> > >> On 27/11/13 17:43, Daniel P. Be
On 26/11/13 10:57 -0600, Dolph Mathews wrote:
On Tue, Nov 26, 2013 at 2:47 AM, Flavio Percoco wrote:
As crazy as it sounds, have you guys considered migrating to
Nottingham's approach?
It only sounds crazy because I have no idea how to "migrate" an unversioned
endpoint :) Skimming thro
On 11/27/2013 06:46 PM, Alan Pevec wrote:
> 2013/11/27 Sean Dague :
>> The problem is you can't really support both iso8601 was dormant
>> for years, and the revived version isn't compatible with the old
>> version. So supporting both means basically forking iso8601 and
>> maintaining you own versi
On 27/11/13 23:37, Fox, Kevin M wrote:
Hmm... Yeah. when you tell heat client the url to a template file, you could
set a flag telling the heat client it is in a git repo. It could then
automatically look for repo information and set a stack metadata item pointing
back to it.
Or just store t
Hi all,
just a few thoughts (subjective opinions) regarding the whole debate:
* I think that having a manually picking images for machines approach
would make TripleO more usable in the beginning. I think it will take a
good deal of time to get our smart solution working with the admin
rather
Thanks for the input. I apologize for the delay.
1. A working patch is here - https://review.openstack.org/#/c/55146. Reviews
will be much appreciated.
2. Default setting has external_connectivity=False so tempest gate doesn't
check this. I wonder if we could somehow set the neutron gate to conf
Hi
I am configuring Havana on fedora 19. Observing the below errors in case of
neutron.
Please help me resolve this issue.
copied only few lines from the server.log, in case full log is
required, let me know.
/etc/neutron/plugins/ml2/ml2_conf.ini
type_drivers = vxlan,local
tenant_network_types =
On Wed, Nov 27, 2013 at 07:26:03PM +, Jeremy Stanley wrote:
> On 2013-11-27 19:18:12 + (+), Daniel P. Berrange wrote:
> [...]
> > It would be desirable if the gate logs included details of all software
> > package versions installed. eg so we can see what libvirt, qemu and
> > kernel ar
Can u post the contents of neutron.conf file too ?
Also, the complete neutron log..
Check the sqlalchemy version compatibility
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
From: Gopi Krishna B [mailto:gopi97...@gmail.com]
Sent: Thursday, November 28, 2013 5:32 PM
Hi Itsuro,
I've updated the wiki with some examples of cli workflow that illustrate
proposed API.
Please see the updated page:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance#API_change
Thanks,
Eugene.
On Thu, Nov 28, 2013 at 3:00 AM, Itsuro ODA wrote:
> Hi,
>
> I'd like to
On 11/28/2013 05:13 AM, Daniel P. Berrange wrote:
> NB, technically we should have separate CI running for each hypervisor
> that libvirt is able to talk to, so there'd likely want to be dedicated
> CI infrastructure for the libvirt+bhyve combination regardless, perhaps
> it would need less overal
Hi,
I am working on adding request-id to API response in Neutron.
After I checked what header is used in other projects
header name varies project by project.
It seems there is no consensus what header is recommended
and it is better to have some consensus.
nova: x-compute-request-id
cind
On 11/28/13 12:10 AM, "Robert Collins" wrote:
>On 25 November 2013 21:51, Sylvain Bauza wrote:
>> As said earlier, I also would love to join the team, triggering a few
>> blueprints or so.
>>
>> By the way, I'm currently reviewing the Scheduler code. Do you began to
>> design the API queries o
On 11/28/2013 09:50 AM, Gary Kotton wrote:
One option worth thinking about is to introduce a new scheduling driver to
nova - this driver will interface with the external scheduler. This will
let us define the scheduling API, model etc, without being in the current
confines of Nova. This will als
Le 28/11/2013 17:04, Chris Friesen a écrit :
On 11/28/2013 09:50 AM, Gary Kotton wrote:
One option worth thinking about is to introduce a new scheduling
driver to
nova - this driver will interface with the external scheduler. This will
let us define the scheduling API, model etc, without being
Hi folks,
according to our hacking rules all source files should contain the Apache
license header in the beginning
(http://docs.openstack.org/developer/hacking/#openstack-licensing).
There are special files that in most of the cases are empty, i.e., __init__.py.
I used to put license headers t
On 2013-11-28 06:46:27 -0500 (-0500), Yair Fried wrote:
[...]
> 4. Jeremy Stanley - "test check for no fewer than three addresses"
> -- Why?
If your tests try to communicate with addresses which are truly
outside your own network, and thus outside your sphere of control,
you don't want them failin
Good question, Roman. I'm also interested in this. Are there any
best-practices of header usage ? Should we place headers whereven it needs ?
2013/11/28 Roman Prykhodchenko
> Hi folks,
>
> according to our hacking rules all source files should contain the Apache
> license header in the beginnin
I have been doing so in the number of patches I pushed to reduce error
traces due to the communication between server and dhcp agent.
I wanted to take care of the l3 agent too, but one thing I noticed is
that I couldn't find a log for it (I mean on the artifacts that are
published at job's complet
On Nov 25, 2013 7:13 PM, "Doug Hellmann"
wrote:
>
>
>
>
> On Mon, Nov 25, 2013 at 3:56 PM, Devananda van der Veen <
devananda@gmail.com> wrote:
>>
>> Hi!
>>
>> Very good questions. I think most of them are directed towards the
Ceilometer team, but I have answered a few bits inline.
>>
>>
>> On
On Thu, Nov 28 2013, Roman Prykhodchenko wrote:
> The point of this email is _not_ to blame someone or to push my personal
> opinion to the folks who gave me the feedback. What I'm trying to do is to
> to bring more clarity to our hacking rules because, as I see, currently
> different folks interp
On 11/28/2013 01:01 PM, Julien Danjou wrote:
> On Thu, Nov 28 2013, Roman Prykhodchenko wrote:
>
>> The point of this email is _not_ to blame someone or to push my personal
>> opinion to the folks who gave me the feedback. What I'm trying to do is to
>> to bring more clarity to our hacking rules b
On 29 November 2013 04:50, Gary Kotton wrote:
> I am not really sure how we can have a client tree without even having
> discussed the API's and interfaces. From the initial round of emails the
> intention was to make use of the RPC mechanism to speak with the scheduler.
It still is. We have an
Sean, Julien,
Than really makes sense. I've seen cases when guys -1ed patches for not having
the header
in empty files referring to that "...all source files..." phrase. That's why I
think it's reasonable to
add your comments to the Hacking rules.
- Roman
On Nov 28, 2013, at 20:08 , Sean Dague
On Thu, Nov 28 2013, Sean Dague wrote:
> I'm totally in favor of going further and saying "empty files shouldn't
> have license headers, because their content of emptiness isn't
> copyrightable" [1]. That's just not how it's written today.
I went ahead and sent a first patch:
https://review.op
Perhaps it's because the l3 agent log it's now named q-vpn.log, if the vpn
service is enabled as well.
Salvatore
On 28 November 2013 18:50, Armando M. wrote:
> I have been doing so in the number of patches I pushed to reduce error
> traces due to the communication between server and dhcp age
On 11/28/13 8:12 PM, "Robert Collins" wrote:
>On 29 November 2013 04:50, Gary Kotton wrote:
>
>> I am not really sure how we can have a client tree without even having
>> discussed the API's and interfaces. From the initial round of emails the
>> intention was to make use of the RPC mechanism
On Wed, Nov 27, 2013 at 5:21 PM, Georgy Okrokvertskhov <
gokrokvertsk...@mirantis.com> wrote:
> Hi,
>
> I am working on the user-authentication BP implementation. I need to
> introduce a new configuration option for enable or disable keystone
> authentication for incoming request. I am looking for
On Thu, Nov 28, 2013 at 1:00 PM, Devananda van der Veen <
devananda@gmail.com> wrote:
>
> On Nov 25, 2013 7:13 PM, "Doug Hellmann"
> wrote:
> >
> >
> >
> >
> > On Mon, Nov 25, 2013 at 3:56 PM, Devananda van der Veen <
> devananda@gmail.com> wrote:
> >>
> >> Hi!
> >>
> >> Very good questio
On 29 November 2013 09:44, Gary Kotton wrote:
>
>
> The first stage is technical - move Nova scheduling code from A to be.
> What do we achieve - not much - we actually complicate things - there is
> always churn in Nova and we will have duplicate code bases. In addition to
> this the only service
Hi Eugene,
Thank you for the response.
I have a comment.
I think 'provider' attribute should be added to loadbalance resource
and used rather than pool's 'provider' since I think using multiple
driver within a loadbalancer does not make sense.
What do you think ?
I'm looking forward to your code
Hi,
I can't find the 28th meeting log.
(Does not logs automatically generated ?)
Thanks.
--
Itsuro ODA
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
I'm now trying to deploy a hadoop cluster with heat, just wondering if
someone who has a heat template which can help me do the work.
Thanks,
Jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/ma
Hi All,
A quick question about simple "janitorial" tasks ...
I noticed that glance.api.v2.image_data.ImageDataController.upload has two
identical "except" clauses (circa line 98):
except exception.StorageFull as e:
msg = _("Image storage media is full: %s") % e
Hi,
I found it in /meeting/nuetron_lbaas.
(neutron -> nuetron)
On Fri, 29 Nov 2013 07:51:56 +0900
Itsuro ODA wrote:
> Hi,
>
> I can't find the 28th meeting log.
> (Does not logs automatically generated ?)
>
> Thanks.
> --
> Itsuro ODA
>
>
> ___
Hi Koo,
On Fri, Nov 29, 2013 at 9:15 AM, David koo wrote:
> Hi All,
>
> A quick question about simple "janitorial" tasks ...
>
> I noticed that glance.api.v2.image_data.ImageDataController.upload has two
> identical "except" clauses (circa line 98):
> except exception.StorageFull
eventlet.spawn_n is the same as eventlet.spawn, but it’s not possible
to know how the function terminated (i.e. no return value or exceptions)[1].
If an exception is raised in the function, spawn_n prints a stack trace.
The stack trace will not be written to the log file. It will be lost if we
rest
Hello Tracy,
some of the problem I faced, to execute different nova cli(s), i required
to restart nova service every-time.
Nova service needs to fully start/realize, before debugging can start.
import pydev; works as break-point for debugger, needs to add at all the
places.
For ex: in case one
I don't think we can implement a stateful firewall[1] now.
Once connection tracking capability[2] is added to the Linux OVS, we
could start to implement the ovs-firewall-driver blueprint.
[1] http://en.wikipedia.org/wiki/Stateful_firewall
[2]
http://wiki.xenproject.org/wiki/Xen_Development_Projec
https://bugs.launchpad.net/bugs/1256207
On Fri, Nov 29, 2013 at 1:08 PM, Zhi Yan Liu wrote:
> Hi Koo,
>
> On Fri, Nov 29, 2013 at 9:15 AM, David koo wrote:
>> Hi All,
>>
>> A quick question about simple "janitorial" tasks ...
>>
>> I noticed that glance.api.v2.image_data.ImageDataControl
Thank you for your reply.
I completely misunderstood.
>You're correct on request_id and task_id.
>What I'm planning is a string field that a user can pass in with the
request and it will be part of the task representation.
>That field will have no meaning to Nova, but a client like Heat could use
Hello,
Yes, libvirt's qemu driver works almost fine currently, except the fact
that it
needs a 'real' bridge driver, so all the networking configuration like
filtering rules, NAT, etc
could be done automatically, like for Linux now, instead of making user to
perform
all the configuration manually.
On Wed, Nov 27, 2013 at 7:32 PM, Rafał Jaworowski wrote:
> The maintenance aspect and testing coverage are valid points, on the
> other hand future changes would have to go a longer way for us: first
> upstream to libvirt, then downstream to the FreeBSD ports collection
> (+ perhaps some OpenStac
51 matches
Mail list logo
