Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework?

Hi, mellanox is also developing a ML2 driver : https://blueprints.launchpad.net/neutron/+spec/mlnx-ml2-support The Havana release is already out, and we are currently working for IceHouse. But the code for IceHouse should be under review before feb. 18th. So it would be difficult to have your cod

Re: [openstack-dev] Ready to import Launchpad Answers into Ask OpenStack

Thank you! On Tue, Feb 11, 2014 at 11:36 AM, Stefano Maffulli wrote: > Hi Sergey > > On Tue 11 Feb 2014 08:01:48 AM CET, Sergey Lukjanov wrote: > > Stefano, is it possible to import savanna's answers@launchpad to > ask.o.o? > > Yes, indeed. I apologize for not putting you explicitly in the cc li

Re: [openstack-dev] [Heat] in-instance update hooks

Hi Clint, thanks for writing this down. This is a really interesting use case and feature, also in relation to what was recently discussed on rolling updates. I have a couple of thoughts and questions: 1) The overall idea seems clear to me but I have problems understanding the detailed flow and

Re: [openstack-dev] [Heat] in-instance update hooks

Hi Clint, nice blueprint. I've added a section about Savanna to the etherpad. Our further usecase looks like the Trove's one - we probably like to support resizing nodes. Additionally, we'd like to decommission data nodes before reboot/shutdown them. Thanks. On Tue, Feb 11, 2014 at 9:22 AM, Cli

Re: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance

On 10/02/14 05:28 +, Eiichi Aikawa wrote: Hi, all, Thanks for your comment. Please let me re-explain. The main purpose of our blueprint is to use network resources more efficiently. To complete this purpose, we suggested the method of using 2 lists. We think, as I wrote before, by listing

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

> Second, there is nothing wrong with booting the instances (or instantiating other > resources) as separate commands as long as we support some kind of > reservation token. I'm not sure what reservation token would do, is it some kind of informing the scheduler that the resources would not be ini

[openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running tests

Hello, I created a new devstack environment today and installed tox 1.7.0, and getting error *"tox.ConfigError: ConfigError: substitution key 'posargs' not found".* Details in [1]. Anybody encountered similar error before? Any workarounds/updates needed? [1] http://paste.openstack.org/show/6417

[openstack-dev] [Mistral]

Do we have (or think about) a shorthand to calling REST_API action, without defining a service? FULL DSL: Services: TimeService: type: REST_API parameters: baseUrl:http://api.timezonedb.com key: actions: get-time: task-paramet

Re: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running tests

- Original Message - > From: "Swapnil Kulkarni" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, February 11, 2014 11:26:29 AM > Subject: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running > tests > > Hello, > > I created a ne

Re: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running tests

On 02/11/2014 10:26 AM, Swapnil Kulkarni wrote: > Hello, > > I created a new devstack environment today and installed tox 1.7.0, and > getting error *"tox.ConfigError: ConfigError: substitution key 'posargs' > not found".* > > Details in [1]. > > Anybody encountered similar error before? Any wor

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-10 18:45 GMT+01:00 Chris Friesen : > > In that model, we would pass a bunch of information about multiple > resources to the solver scheduler, have it perform scheduling *and reserve > the resources*, then return some kind of resource reservation tokens back > to the caller for each resour

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

+1 On 2/11/14 1:28 AM, "Mark McClain" wrote: >All- > >I¹d like to nominate Oleg Bondarev to become a Neutron core reviewer. >Oleg has been valuable contributor to Neutron by actively reviewing, >working on bugs, and contributing code. > >Neutron cores please reply back with +1/0/-1 votes. > >ma

Re: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running tests

Hi. This seems to be related: https://bugs.launchpad.net/openstack-ci/+bug/1274135 We also encountered this. On Tue, 2014-02-11 at 14:56 +0530, Swapnil Kulkarni wrote: > Hello, > > > I created a new devstack environment today and installed tox 1.7.0, > and getting error "tox.ConfigError: ConfigE

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

+1 Il 11/feb/2014 10:47 "Gary Kotton" ha scritto: > +1 > > > On 2/11/14 1:28 AM, "Mark McClain" wrote: > > >All- > > > >I¹d like to nominate Oleg Bondarev to become a Neutron core reviewer. > >Oleg has been valuable contributor to Neutron by actively reviewing, > >working on bugs, and contributi

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

Hi Mark and Anita, could we declare stable/havana neutron gate jobs good enough at this point? There are still random failures as this no-op change shows https://review.openstack.org/72576 but I don't think they're stable/havana specific. >> Do we have a list of those somewhere? > Pulled out wher

Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core

James E. Blair wrote: > I'm very pleased to propose that we add Sergey Lukjanov to the > infra-core team. > > He is among the top reviewers of projects in openstack-infra, and is > very familiar with how jenkins-job-builder and zuul are used and > configured. He has done quite a bit of work in he

Re: [openstack-dev] [Heat] in-instance update hooks

Excerpts from Thomas Spatzier's message of 2014-02-11 00:38:53 -0800: > Hi Clint, > > thanks for writing this down. This is a really interesting use case and > feature, also in relation to what was recently discussed on rolling > updates. > > I have a couple of thoughts and questions: > > 1) The

Re: [openstack-dev] universal wheel support

On Monday 10 February 2014 19:02:55 Doug Hellmann wrote: > On Mon, Feb 10, 2014 at 1:14 PM, Joe Gordon wrote: > > On Mon, Feb 10, 2014 at 9:00 AM, Doug Hellmann > > > > wrote: > > > On Sat, Feb 8, 2014 at 7:08 PM, Monty Taylor > > > > wrote: > > >> Hey all! > > >> > > >> There are a bunch of

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

On 02/10/2014 06:28 PM, Mark McClain wrote: > All- > > I’d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg > has been valuable contributor to Neutron by actively reviewing, working on > bugs, and contributing code. > > Neutron cores please reply back with +1/0/-1 votes.

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

+1 of course! Edgar Sent from my iPhone > On Feb 11, 2014, at 8:28 AM, Mark McClain wrote: > > All- > > I’d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg > has been valuable contributor to Neutron by actively reviewing, working on > bugs, and contributing code. >

[openstack-dev] [Murano] Can we migrate to oslo.messaging?

oslo.messaging is a library that provides RPC and Notifications API, they are part of the same library for mostly historical reasons. One of the major goals of *oslo.messaging* is to provide clean RPC and Notification API without any trace of messaging q

[openstack-dev] [Neutron][IPv6] NAT64 Discussion

In previous Neutron IPv6 team meeting, we discussed the requirement of providing NAT64 in OpenStack to facilitate the communication between IPv6 and IPv4 hosts. For example, from tenant IPv6 network to external traditional IPv4 network. I was suggested to initiate a discussion in ML to gather all f

[openstack-dev] Fwd: [Openstack] [GSoC] Call for Mentors and Participants

Hi all, Apologies if you saw this already. Since we have a really tight deadline to drum up mentor and student participation, forwarding this once to the openstack-dev mailing list. The deadline is this Friday the 14th. thanks, dims On Sun, Feb 9, 2014 at 5:34 PM, Davanum Srinivas wrote: > > Hi

Re: [openstack-dev] OpenStack-dev Digest, Vol 22, Issue 27

Hi Shixiong, Thanks for the reply and clearing up my question! The document you've shared - they aren't the only possible combinations correct? Each of the two fields can have any one of these four values in any possible combination yes? Thanks! On 2/11/14 7:00 AM, "openstack-dev-requ...@lists.o

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

> In that model, we would pass a bunch of information about multiple > resources to the solver scheduler, have it perform scheduling *and > reserve the resources*, then return some kind of resource reservation > tokens back to the caller for each resource. The caller could then > allocate each

Re: [openstack-dev] [Murano] Can we migrate to oslo.messaging?

On Tue, Feb 11, 2014 at 8:05 AM, Serg Melikyan wrote: > oslo.messaging is a library > that provides RPC and Notifications API, they are part of the same library > for mostly historical reasons. One of the major goals of *oslo.messaging* is > to provide

[openstack-dev] [Nova][Glance]supporting of v1 and v2 glance APIs in Nova

Greetings A few days ago, I met some problems when using 'createimage' feature in Nova, we found that using V1 of glanceclient has some problem with processing of metadata, the version number and even the glance URIs are both hardcoded in Nova. then, we found the bluepring[1] proposed, and the ma

Re: [openstack-dev] [Mistral]

Dmitry, I think you are right here. I think for simple case we should be able to use in-place action definition without having to define the action separately. Like you said it’s only valuable if we need to reuse it. The only difference I see between std:send-email and something like REST_API is

Re: [openstack-dev] [Murano] Can we migrate to oslo.messaging?

Doug, thank you for your response! With moving to *oslo.messaging *I think we need to carefully re-evaluate our communication patterns and try to either fit them to RPC/Notification, or work on extending *oslo.messaging *with some new ideas. Adopting a new library is always a challenge. >The RPC

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote: Second, there is nothing wrong with booting the instances (or instantiating other resources) as separate commands as long as we support some kind of reservation token. I'm not sure what reservation token would do, is it some kind of informing the

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

On 02/11/2014 04:57 AM, Alan Pevec wrote: > Hi Mark and Anita, > > could we declare stable/havana neutron gate jobs good enough at this point? > There are still random failures as this no-op change shows > https://review.openstack.org/72576 > but I don't think they're stable/havana specific. > >>

Re: [openstack-dev] [Heat] in-instance update hooks

On 02/10/2014 10:22 PM, Clint Byrum wrote: Hi, so in the previous thread about rolling updates it became clear that having in-instance control over updates is a more fundamental idea than I had previously believed. During an update, Heat does things to servers that may interrupt the server's purp

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

+1 Sumit. On Feb 10, 2014 3:33 PM, "Mark McClain" wrote: > All- > > I'd like to nominate Oleg Bondarev to become a Neutron core reviewer. > Oleg has been valuable contributor to Neutron by actively reviewing, > working on bugs, and contributing code. > > Neutron cores please reply back with +1/

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Le 11/02/2014 16:09, Chris Friesen a écrit : Yes. So what I'm suggesting is that we schedule the two VMs as one call to the SolverScheduler. The scheduler then gets reservations for the necessary resources and returns them to the caller. This would be sort of like the existing Claim object

[openstack-dev] [Murano] Community meeting agenda - 02/11/2014

Hi, This is just a reminder that we are going to have a weekly meeting of Murano team in IRC (#openstack-meeting-alt) today at 17:00 UTC (9am PST) . The agenda can be found here: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda Feel free to add anything you want to discuss. -- Regar

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

> > Like a restaurant reservation, it would "claim" the resources for use by > someone at a later date. That way nobody else can use them. > That way the scheduler would be responsible for determining where the > resource should be allocated from, and getting a reservation for that > resource. It

[openstack-dev] Hyper-v meeting cancelled.

Hi all. We are currently working to bring additional compute power to the hyper-v ci infrastructure. Because this task currently takes precedence I need to cancel the meeting for today. P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.or

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Thanks, I will look closely at it. De : Dina Belova [mailto:dbel...@mirantis.com] Envoyé : mardi 11 février 2014 16:45 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler Like a restaurant r

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

I thought of adding some more points about the Solver Scheduler to this conversation. Think of SolverScheduler as a placement decision engine, which gives an optimal solution for the specified request based on the current information available at a specific time. The request could potentially be a

Re: [openstack-dev] [Heat] in-instance update hooks

Excerpts from Steven Dake's message of 2014-02-11 07:19:19 -0800: > On 02/10/2014 10:22 PM, Clint Byrum wrote: > > Hi, so in the previous thread about rolling updates it became clear that > > having in-instance control over updates is a more fundamental idea than > > I had previously believed. Duri

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Hi Dina, Thanks for note about Climate logic. This is something that will be very useful, when we will have to schedule from Nova multiple instances (of potentially different flavors) as a single request. If the Solver Scheduler, can make a request to the Climate service to reserve the resour

[openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack

Hi Openstackers, We are working on link aggregation support in Fuel. We wonder what are the most desirable types of bonding now in datacenters. We had some issues (see below) with OVS bond in LACP mode, and it turned out that standard Linux bonding (attached to OVS bridges) was a better option in

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

Le 11/02/2014 17:23, Yathiraj Udupi (yudupi) a écrit : Hi Dina, Thanks for note about Climate logic. This is something that will be very useful, when we will have to schedule from Nova multiple instances (of potentially different flavors) as a single request. If the Solver Scheduler, can ma

Re: [openstack-dev] [Mistral]

Yes it makes sense, let's draft how it may look; and also think over implementation implications - now we separate task parameters, action parameters, and service parameters, we may need to merge them when instantiating the action. DZ. On Feb 11, 2014, at 6:19 AM, Renat Akhmerov wrote: > D

Re: [openstack-dev] [Nova][Glance]supporting of v1 and v2 glance APIs in Nova

> A few days ago, I met some problems when using 'createimage' feature in > Nova, we found that using V1 of glanceclient has some problem with > processing of metadata, the version number and even the glance URIs are > both hardcoded in Nova. > > then, we found the bluepring[1] proposed, and the m

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

> > This is something to explore to add in Nova, using > a local service or external service (need to explore Climate). I need to find out more about Climate. Here is Climate Launchpad: https://launchpad.net/climate That's still really young project, but I believe it'll have great future speak

[openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - "Without any kind of NAT"

Hello Stackers! It is very nice to watch the OpenStack evolution in IPv6! Great job guys!! I have another idea: "Floating IP" for IPv6, or just "Floating IPv6" With IPv4, as we know, OpenStack have a feature called "Floating IP", which is basically a 1-to-1 NAT rule (within tenant's Namespace

Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time

Hi Kyle, Almost missed this - sounds good to me. Thanks, - Stephen On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery wrote: > Folks: > > I'd like to propose moving the Neutron Group Policy meeting going > forward, starting with this Thursday. The meeting has been at 1600 > UTC on Thursdays, I

[openstack-dev] www.xrefs.info: addition of openflow and SDN

I setup http://www.xrefs.info for open source developers to do cross reference search based on OpenGrok. It covers projects like linux kernel from version 0.01 to latest, android, linux packages, BSD, cloud computing, big data, SDN etc.. Check it out...Let me know if you have any suggestions or com

Re: [openstack-dev] [Heat] in-instance update hooks

Another scaling down/update use case: Say I have a pool of ssh servers for users to use (compute cluster login nodes). Autoscaling up is easy. Just launch a new node and add it to the load balancer. Scaling down/updating is harder. It should ideally: * Set the admin state on the load balancer for

Re: [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - "Without any kind of NAT"

Hello Stackers! It is very nice to watch the OpenStack evolution in IPv6! Great job guys!! Thanks! I have another idea: "Floating IP" for IPv6, or just "Floating IPv6" With IPv4, as we know, OpenStack have a feature called "Floating IP", which is basically a 1-to-1 NAT rule (within tenant

Re: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack

Excerpts from Andrey Danin's message of 2014-02-11 08:42:46 -0800: > Hi Openstackers, > > We are working on link aggregation support in Fuel. We wonder what are the > most desirable types of bonding now in datacenters. We had some issues (see > below) with OVS bond in LACP mode, and it turned out

Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core

Thank you all! I'm glad to help infra team with extremely growing number of CRs to their projects. On Tue, Feb 11, 2014 at 2:24 PM, Thierry Carrez wrote: > James E. Blair wrote: > > I'm very pleased to propose that we add Sergey Lukjanov to the > > infra-core team. > > > > He is among the top r

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

hi Sylvain and Dina, Thanks for your pointers about Climate. I will take a closer look at it and try it out. So after a reservation lease for a VM is made by Climate, who acts on it to finally instantiate the VM ? Is it Climate or Nova should act on the lease to finally provision the VM. Tha

Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time

Hi Kyle, The new time sounds good to me as well, thanks for initiating this. ~sumit. On Tue, Feb 11, 2014 at 9:02 AM, Stephen Wong wrote: > Hi Kyle, > > Almost missed this - sounds good to me. > > Thanks, > - Stephen > > > > On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery > wrote: >> >> Folk

Re: [openstack-dev] [Neutron][LBaaS] Proposal for model

[Roger] Hi Stephen! Great job! Obviously your experience is both awesome and essential here. I would ask that we add a historical archive (physically implemented as a log file, probably) object to your model. When you mentioned sending data off to Ceilometer, that triggered me to think about

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

> > So after a reservation lease for a VM is made by Climate, who acts on it > to finally instantiate the VM ? Is it Climate or Nova should act on the > lease to finally provision the VM. Now to take resources for VM it's actually created and then immediately shelved, not to be in active state an

Re: [openstack-dev] [Heat] in-instance update hooks

Thanks Kevin, great summary. This is beyond the scope of in-instance notification. I think this is more like the generic notification API that Thomas Herve suggested in the rolling updates thread. It can definitely use the same method for its implementation, and I think it is adjacent to, and not

Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler

2014-02-11 18:28 GMT+01:00 Yathiraj Udupi (yudupi) : > > > Thanks for your pointers about Climate. I will take a closer look at it > and try it out. So after a reservation lease for a VM is made by Climate, > who acts on it to finally instantiate the VM ? Is it Climate or Nova should > act on t

[openstack-dev] [oslo-notify] notifications consumed by multiple subscribers

Hi, I’m planning to use oslo.notify mechanisms to implement a climate blueprint: https://blueprints.launchpad.net/climate/+spec/notifications. Ideally, the notifications sent by climate should be received by multiple services subscribed to the same topic. Is that possible with oslo.notify? And m

Re: [openstack-dev] [Murano] Can we migrate to oslo.messaging?

On Tue, Feb 11, 2014 at 9:59 AM, Serg Melikyan wrote: > Doug, thank you for your response! > > With moving to *oslo.messaging *I think we need to carefully > re-evaluate our communication patterns and try to either fit them to > RPC/Notification, or work on extending *oslo.messaging *with some new

Re: [openstack-dev] [oslo-notify] notifications consumed by multiple subscribers

On Tue, Feb 11, 2014 at 1:28 PM, Sanchez, Cristian A < cristian.a.sanc...@intel.com> wrote: > Hi, > I'm planning to use oslo.notify mechanisms to implement a climate > blueprint: https://blueprints.launchpad.net/climate/+spec/notifications. > Ideally, the notifications sent by climate should be re

Re: [openstack-dev] [infra] Meeting Tuesday February 11th at 19:00 UTC

On Mon, Feb 10, 2014 at 7:48 AM, Elizabeth Krumbach Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting tomorrow, Tuesday February 11th, at 19:00 UTC in > #openstack-meeting Thanks to everyone who attended, minutes and logs now available here: Minutes: http

Re: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack

- Original Message - > From: "Andrey Danin" > To: openstack-dev@lists.openstack.org, "fuel-dev" > > Sent: Tuesday, February 11, 2014 11:42:46 AM > Subject: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack > > Hi Openstackers, > > We are working on link aggregation support in

Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time

FYI, I’ve made the change on the meeting pages as well [1]. The Neutron Group Policy meeting is now at 1700UTC Thursday’s on #openstack-meeting-alt. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting On Feb 11, 2014, at 11:30 AM, Sumit Naiksatam wro

Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id

I believe it would need to be like: network_vlan_ranges = physnet1:100:300, phynet2:100:300, phynet3:100:300 Additional comments inline: On Mon, Feb 10, 2014 at 8:49 PM, Vinay Bannai wrote: > Bob and Kyle, > > Thanks for your review. > We looked at this option and it seems it might meet our n

[openstack-dev] [python-openstacksdk] First meeting scheduled

As I said last week; we’re ready to kickoff and have regular meetings for the “unified python SDK” project. The initial meeting is scheduled on the wiki: https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting Date/Time: Feb. 19th - 19:00 UTC / 1pm CST IRC channel: #openstack-meet

Re: [openstack-dev] [keystone] role of Domain in VPC definition

Ravi, It seems that the following Blueprint https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support has been approved. However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation. I have an issue with this approach as

Re: [openstack-dev] [Trove] Backup/Restore encryption/decryption issue

Denis Makogon writes: > Goodday, OpenStack DВaaS community. > > > I'd like to start conversation about guestagent security issue related > to backup/restore process. Trove guestagent service uses AES with 256 bit > key (in CBC mode) [1] to encrypt backups which are stored at predefined >

Re: [openstack-dev] [python-openstacksdk] First meeting scheduled

Jesse, Why not next approach: 1) Switch all clients to apiclient[1] (internal unification) 2) Unify API of all clients (external unification) 3) Unify work with keystone 4) Graduate apiclient 5) Switch all clients to apiclient lib 6) Make one simple plugable mechanism. e.g. subclass based factory

Re: [openstack-dev] [Trove] Backup/Restore encryption/decryption issue

As we decided at meeting, we wouldn't keep our own implementations of security stuff, we'll use Barbican as single entry point of delivering secrets. I hadn't talked with Barbican team, but since oslo-incubator will (someday) release oslo.crypto lib for all projects, i think that adding implementat

Re: [openstack-dev] [python-openstacksdk] First meeting scheduled

On Feb 11, 2014, at 3:02 PM, Boris Pavlovic wrote: > Jesse, > > Why not next approach: > 1) Switch all clients to apiclient[1] (internal unification) This was discussed several weeks ago here: http://lists.openstack.org/pipermail/openstack-dev/2014-January/024441.html This discussion covered

Re: [openstack-dev] [Trove] Replication Contract Verbiage

Daniel Salinas writes: > https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API#REPLICATION > > I have updated the wiki page to reflect the current proposal for > replication verbiage with some explanation of the choices. I would like to > open discussion here regarding that verbia

[openstack-dev] [requirements] problems with non overlapping requirements changes

A few weeks ago we realized one of the wrecking balls in the gate were non overlapping requirements changes, like this - https://review.openstack.org/#/c/72475/ Regular jobs in the gate have to use the OpenStack mirror. Requirements repo doesn't, because it needs to be able to test things not in t

Re: [openstack-dev] oslo.config improvements

On Mon, 2014-02-10 at 10:50 -0500, Doug Hellmann wrote: > > 2) It locates options based on them being defined at the top > level of a > module (not in function or packed into some object), but it > gets info by > looking at cfg.CONF, which require re

Re: [openstack-dev] [oslo-notify] notifications consumed by multiple subscribers

The notification system can specify multiple queues to publish to, so each of your dependent services can feed from a separate queue. However, this is a critical bug in oslo.messaging that has broken this feature. https://bugs.launchpad.net/nova/+bug/1277204 Hopefully it'll get fixed quickly a

Re: [openstack-dev] oslo.config improvements

On Tue, Feb 11, 2014 at 4:38 PM, Shaun McCance wrote: > On Mon, 2014-02-10 at 10:50 -0500, Doug Hellmann wrote: > > > > 2) It locates options based on them being defined at the top > > level of a > > module (not in function or packed into some object), but it > > g

Re: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack

On 12 February 2014 05:42, Andrey Danin wrote: > Hi Openstackers, > > > We are working on link aggregation support in Fuel. We wonder what are the > most desirable types of bonding now in datacenters. We had some issues (see > below) with OVS bond in LACP mode, and it turned out that standard Linu

Re: [openstack-dev] [Neutron] Support for multiple provider networks with same VLAN segmentation id

One way to look at the VLANs is that it identifies a security zone that meets some regulatory compliance standards. The VLANs on each rack are separated from other VLANs by using VRF. Tenants in our case map to applications. So each application is served by a VIP with a pool of VMs. So all applicat

Re: [openstack-dev] [Nova][Glance]supporting of v1 and v2 glance APIs in Nova

2014-02-12 0:38 GMT+08:00 Eddie Sheffield : > > A few days ago, I met some problems when using 'createimage' feature in > > Nova, we found that using V1 of glanceclient has some problem with > > processing of metadata, the version number and even the glance URIs are > > both hardcoded in Nova. > >

[openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

Hi, The patch I submitted for L3 service framework integration fails on jenkins test, py26 and py27. The console only gives following error message, 2014-02-12 00:45:01.710 | FAIL: process-returncode 2014-02-12 00:45:01.711 | tags: worker-1 and at the end, 2014-02-12 00:45:01.916 | ERROR: Invoc

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan wrote: > Hi, > > The patch I submitted for L3 service framework integration fails on jenkins > test, py26 and py27. The console only gives following error message, > > 2014-02-12 00:45:01.710 | FAIL: process-returncode > 2014-02-12 00:45:01.711 | tags: wo

Re: [openstack-dev] [Murano] Can we migrate to oslo.messaging?

Is murano python3.x compatible, from what I understand oslo.messaging isn't (yet). If murano is supporting python3.x then brining in oslo.messaging might make it hard for murano to be 3.x compatible. Maybe not a problem (I'm not sure of muranos python version support). From: Serg Melikyan mailt

Re: [openstack-dev] [Murano] Can we migrate to oslo.messaging?

Hi Joshua, Currently we are not 3.x compatible, at least not all of the modules. Migration to python3 should eventually be done, but for now it is the least of our concerns, while relying on a non-standard messaging solution instead of community-approved one is likely to cause problems, both in te

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

Hi, Clark, Thanks for your reply. I thought the same thing at first, but the page by default only shows the failed cases. The other 1284 cases were OK. Gary On Tue, Feb 11, 2014 at 6:07 PM, Clark Boylan wrote: > On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan wrote: > > Hi, > > > > The patch I su

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

On Tue, Feb 11, 2014 at 7:05 PM, Gary Duan wrote: > Hi, Clark, > > Thanks for your reply. > > I thought the same thing at first, but the page by default only shows the > failed cases. The other 1284 cases were OK. > > Gary > > > On Tue, Feb 11, 2014 at 6:07 PM, Clark Boylan > wrote: >> >> On Tue,

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

Clark, You are right. The test must have been bailed out. The question is what I should look for. Even a successful case has a lot of Traceback, ERROR log in subunit_log.txt. Thanks, Gary On Tue, Feb 11, 2014 at 7:19 PM, Clark Boylan wrote: > On Tue, Feb 11, 2014 at 7:05 PM, Gary Duan wrote:

[openstack-dev] [Nova] modify_image_attribute() in ec2_api is broken in Nova

Hi all, I met some problems when testing an ec2_api:'modify_image_attribute()' in Nova. I found the params send to Nova, are not suitable to match it in AWS api. I logged it in launchpad: https://bugs.launchpad.net/nova/+bug/1272844 - 1. Here is the definition part of modify_image_at

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

Hi Gary- Look into the logs with a search towards your written code keywords.. There might be some issues related to PEP8 or invalid import paths. Hope this helps. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 From: Gary Duan [mailto:garyd...@gmail.com] Sent: Wednesd

Re: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack

On 11 February 2014 18:42, Andrey Danin wrote: > We are working on link aggregation support in Fuel. We wonder what are the > most desirable types of bonding now in datacenters. We had some issues (see > below) with OVS bond in LACP mode, and it turned out that standard Linux > bonding (attached