Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

Hi, I'd rather not subclass dict directly. for various reasons adding extra attributes to normal python dict seems prone to errors since people will be expecting regular dicts, and on the other hand if we want to expand it in the future we might run into problems playing with dict methods (such

[openstack-dev] [openstack][neutron][jenkins]Merge failure in jenkins : gate-tempest-dsvm-neutron-full and

Hi, There are failure in jenkins that not related to the patch: https://review.openstack.org/#/c/89211/ The console log shows errors as below. Has anybody seen these error? Is it a known issue. Please advise what needs to be done? 2014-08-30 15:26:11.789

Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER

The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackag

Re: [openstack-dev] [nova] nova backup not working in stable/icehouse?

You are thinking of written-for-cloud applications. For those the state should not persist with the instance. There are a very large number of existing applications, not written to the cloud model, but which could be deployed in a cloud. Those applications are not all going to get re-written (as t

Re: [openstack-dev] [neutron][lbaas][octavia]

Only really have comments on two of your related points: [Susanne] To me Octavia is a driver so it is very hard to me to think of it as a standalone project. It needs the new Neutron LBaaS v2 to function which is why I think of them together. This of course can change since we can add whatever

[openstack-dev] [nova] libvirt version_cap, a postmortem

Hey The libvirt version_cap debacle continues to come up in conversation and one perception of the whole thing appears to be: A controversial patch was "ninjaed" by three Red Hat nova-cores and then the same individuals piled on with -2s when a revert was proposed to allow further discuss

Re: [openstack-dev] Review change to nova api pretty please?

Thanks Choumel! Alex On 30 August 2014 11:49, Chmouel Boudjnah wrote: > > On Sat, Aug 30, 2014 at 11:28 AM, Alex Leonhardt > wrote: > >> Is there a list of things "not to send to this list" somewhere accessible >> (link?) that I could review, to not send another (different) request by >> mista

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

Sean, class ResponseBody(dict): > def __init__(self, body={}, resp=None): > self.update(body) > self.resp = resp Are you sure that you would like to have default value {} for method argument and not something like: class ResponseBody(dict): def __init__(self, body=Non

Re: [openstack-dev] Review change to nova api pretty please?

On Sat, Aug 30, 2014 at 11:28 AM, Alex Leonhardt wrote: > Is there a list of things "not to send to this list" somewhere accessible > (link?) that I could review, to not send another (different) request by > mistake and possibly upset or annoy people on here ? There is this document : https://

Re: [openstack-dev] Review change to nova api pretty please?

Thanks Flavio, that was sent to this list a long time before I joined, so my apologies to not have known. Is there a list of things "not to send to this list" somewhere accessible (link?) that I could review, to not send another (different) request by mistake and possibly upset or annoy people on

[openstack-dev] Launch of a instance failed in juno

Launch of a instance failed in juno devstack on ubuntu server 14.04 virtual machine. I am getting error "Host not found". Below is part of /opt/stack/logs/screen/screen-n-cond.log 2014-08-30 12:06:51.721 ERROR nova.scheduler.utils [req-744ba1cf-7433-46b4-9771-9600a87e8c28 admin admin] [instance: 2a