Re: [openstack-dev] [nova] Migration progress

On Wed, Feb 03, 2016 at 10:44:36AM +, Daniel P. Berrange wrote: > On Wed, Feb 03, 2016 at 10:37:24AM +, Koniszewski, Pawel wrote: > > Hello everyone, > > > > On the yesterday's live migration meeting we had concerns that interval of > > writing migration progress to the database is too

Re: [openstack-dev] [nova] Migration progress

On Wed, Feb 03, 2016 at 10:37:24AM +, Koniszewski, Pawel wrote: > Hello everyone, > > On the yesterday's live migration meeting we had concerns that interval of > writing migration progress to the database is too short. > > Information about migration progress will be stored in the database

Re: [openstack-dev] [Magnum] New Core Reviewers

Thanks Adrian and Magnum team for having me as part of the team. It has been a lot of fun working with everyone and I look forward to continuing the great progress of the project. Ton, From: Jay Lau To: "OpenStack Development Mailing List (not for usage

[openstack-dev] [nova] Migration progress

Hello everyone, On the yesterday's live migration meeting we had concerns that interval of writing migration progress to the database is too short. Information about migration progress will be stored in the database and exposed through the API (/servers//migrations/). In current proposition [1]

Re: [openstack-dev] [nova] Migration progress

> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: 03 February 2016 10:49 > To: OpenStack Development Mailing List (not for usage questions) > Cc: Feng, Shaohe > Subject: Re: [openstack-dev] [nova] Migration progress > > On Wed, Feb 03, 2016 at

[openstack-dev] Make a separate library from /neutron/agent/ovsdb

Hello, would it be possible to change /neutron/agent/ovsdb package into a separate library, independent on openstack? It's a pity that there is no high-level python library for ovs handling available and your implementation seems to be great. The module is dependent only or some openstack utils,

Re: [openstack-dev] [keystone] changes to keystone-core!

++! On 01.02.2016 01:26, Lance Bragstad wrote: ++ I'm happy to see this go through! Samuel and Dave have been helping me out a lot lately. Both make great additions to the team! On Thu, Jan 28, 2016 at 9:12 AM, Brad Topol > wrote:

[openstack-dev] [vitrage] Vitrage meeting minutes

Hi, You can find the meeting minutes of Vitrage meeting: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-03-09.00.html Meeting log: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-03-09.00.log.html See you next week, Ifat.

Re: [openstack-dev] [nova] Migration progress

On 03/02/16 10:49, Daniel P. Berrange wrote: On Wed, Feb 03, 2016 at 10:44:36AM +, Daniel P. Berrange wrote: On Wed, Feb 03, 2016 at 10:37:24AM +, Koniszewski, Pawel wrote: Hello everyone, On the yesterday's live migration meeting we had concerns that interval of writing migration

Re: [openstack-dev] Logging and traceback at same time.

On Wed, Feb 03 2016, Khayam Gondal wrote: > Is there a way to do logging the information and traceback at the same > Let me know if this is correct way? Pass exc_info=True in your LOG.() call. -- Julien Danjou ;; Free Software hacker ;; https://julien.danjou.info signature.asc Description:

Re: [openstack-dev] [Neutron] Integrating physical appliance into virtual infrastructure

I think you will want to write an ML2 mechanism driver for your appliance so it can receive all port/network/subnet information that you can forward onto your appliance. To automatically have Neutron's l2pop mechanism setup tunnels on the agent to point to your appliance, you need to register the

Re: [openstack-dev] Adding Ironic node kills devstack configuration

Hi Pavel, 1. Unfortunately no, it is not possible to "update" a running devstack by executing stack.sh, everything is created from scratch - e.g. empty DB is created and all migration scripts are being run to ensure that the DB is in the state required by the component. 2. Could you please post

Re: [openstack-dev] [neutron] - L3 flavors and issues with usecasesfor multiple L3 backends

People need high performance but also xaaS integrated, slow and free but also packet logged. And lots of back-ends have multiple characters. According to the example described in this thread, those characters really should be modeled as different flavors. Indeed, I think people just want to know

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

The service-* commands aren't related to the magnum services (e.g. magnum-conductor). The service-* commands are for services on the bay that the user creates and deletes. Corey On Wed, Feb 3, 2016 at 2:25 AM Eli Qiao wrote: > hi > Whey I try to run magnum service-list

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 2 February 2016 at 02:28, Sam Yaple wrote: > > I disagree with this statement strongly as I have stated before. Nova has > snapshots. Cinder has snapshots (though they do say cinder-backup). Freezer > wraps Nova and Cinder. Snapshots are not backups. They are certainly not >

Re: [openstack-dev] [nova] Migration progress

On Wed, Feb 03, 2016 at 11:27:16AM +, Paul Carlton wrote: > On 03/02/16 10:49, Daniel P. Berrange wrote: > >On Wed, Feb 03, 2016 at 10:44:36AM +, Daniel P. Berrange wrote: > >>On Wed, Feb 03, 2016 at 10:37:24AM +, Koniszewski, Pawel wrote: > >>>Hello everyone, > >>> > >>>On the

[openstack-dev] [api] microversion spec

I've been looking through the reviews on and where it's gotten to - https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst A couple of questions / concerns. There was major push back from API-WG on 'API' itself being in the headers. What is the data on what services

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On Tue, Feb 2, 2016 at 5:08 PM, Foley, Emma L wrote: > Hi Simon, > > > > So collectd acts as a statsd server, and the metrics are aggregated and > dispatched to the collectd daemon. > > Collectd’s write plugins then output the stats to wherever we want them to > go. > > >

[openstack-dev] [Monasca] alarm-definition-list is failing with "service unavailable"

Hello, Seeing the alarm-definition-list is returning "service unavailable" for admin user: stack@ubuntu:~/devstack$ monasca --os-username admin --os-password secretadmin --os-project-name admin alarm-definition-list ERROR (exc:65) exception: { "title": "Service unavailable",

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

No objections from my side. Let's do it. On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov wrote: > Hi Sergey, > > I fully support this idea. It was our plan as well when we were developing > Ubuntu Bootstrap feature. So let's proceed with CentOS bootstrap removal. > > BR, >

Re: [openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

On 02/02/2016 10:03 PM, Matthew Treinish wrote: > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote: >> Folks, >> >> We have some IPv6 related bugs [1,2,3] that have been lingering for some >> time now. They have been hurting the gate (e.g. [4] the most recent >> offending failure) and

Re: [openstack-dev] [nova] do not account compute resource of instances in state SHELVED_OFFLOADED

On 2 February 2016 at 14:11, Sascha Vogt wrote: > Hi, > > Am 31.01.2016 um 18:57 schrieb John Garbutt: >> We need to make sure we don't have configuration values that change >> the semantic of our API. >> Such things, at a minimum, need to be discoverable, but are best

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

On 02.02.2016 17:35, Alexey Shtokolov wrote: > Hi Fuelers! > > As you may be aware, since [0] Fuel has implemented a new orchestration > engine [1] > We switched the deployment paradigm from role-based (aka granular) to > task-based and now Fuel can deploy all nodes simultaneously using >

[openstack-dev] [tricircle] Port Query Performance Test

Hi all, I did a test about the performance of port query in Tricircle yesterday. The result is attached. Three observations in the test result: (1) Neutron client costs much more time than curl, the reason may be neutron client needs to apply for a new token in each run. (2) Eventlet doesn't

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

I can clarify Eli’s question further. 1) is this by designed that we don't allow magnum-api to access DB directly ？ Yes, that is what it is. Actually, The magnum-api was allowed to access DB directly in before. After the indirection API patch landed [1], magnum-api starts using magnum-conductor

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 11/30/2015 07:56 PM, Armando M. wrote: > I would like to suggest that we evolve the structure of the Neutron > governance, so that most of the deliverables that are now part of the > Neutron stadium become standalone projects that are entirely > self-governed (they have their own core/release

[openstack-dev] [release][release] reno 1.4.0 release (independent)

We are delighted to announce the release of: reno 1.4.0: RElease NOtes manager This release is part of the independent release series. With source available at: http://git.openstack.org/cgit/openstack/reno With package available at: https://pypi.python.org/pypi/reno Please report

Re: [openstack-dev] [Magnum] Bug 1541105 options

- Original Message - > From: "Hongbin Lu" > To: "OpenStack Development Mailing List (not for usage questions)" > > > I would vote for a quick fix + a blueprint. > > BTW, I think it is a general consensus that we should move

[openstack-dev] [Neutron] Fullstack tests question

Hello, I'm currently working on patch https://review.openstack.org/#/c/248938/7 which will provide support for LinuxBridge agent in fullstack tests (and make connectivity test for that type of agents). In this test I'm spawning LinuxBridge agent in "host" namespace. Generally tests are working

Re: [openstack-dev] [Magnum] Bug 1541105 options

I would vote for a quick fix + a blueprint. BTW, I think it is a general consensus that we should move away from Atomic for various reasons (painful image building, lack of document, hard to use, etc.). We are working on fixing the CoreOS templates which could replace Atomic in the future.

Re: [openstack-dev] [tricircle] Port Query Performance Test

+1. The neutron client can only operate on the environmental variables it has access to, it doesn't store any other state. So if all it has is credentials, it has to use those to fetch a token. On Wed, Feb 3, 2016 at 12:05 PM, Rick Jones wrote: > On 02/03/2016 05:32 AM,

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 3 February 2016 at 16:32, Sam Yaple wrote: > > Looking into it, however, shows Cinder has no mechanism to delete backups > in the middle of a chain since you use dependent backups (please correct me > if I am wrong here). This means after a number of incremental backups you

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 3 February 2016 at 17:27, Sam Yaple wrote: > > And here we get to the meat of the matter. Squashing backups is awful in > object storage. It requires you to pull both backups, merge them, then > reupload. This also has the downside of casting doubt on a backup since you >

Re: [openstack-dev] Logging and traceback at same time.

On Wed, Feb 03, 2016 at 02:46:28PM +0800, 王华 wrote: > You can use LOG.exception. Yes, I highly recommend using LOG.exception in this case. That is exactly what it's used for. LOG.exception is pretty much exactly like LOG.error, but with the additional behavior that it will log out the details of

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 1:41 PM, Duncan Thomas wrote: > On 2 February 2016 at 02:28, Sam Yaple wrote: > >> >> I disagree with this statement strongly as I have stated before. Nova has >> snapshots. Cinder has snapshots (though they do say

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 2016-02-03 14:32:36 + (+), Sam Yaple wrote: [...] > Luckily, digging into it it appears cinder already has all the > infrastructure in place to handle what we had talked about in a > separate email thread Duncan. It is very possible Ekko can > leverage the existing features to do it's

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

+1 On Wed, Feb 3, 2016 at 4:45 PM, Igor Kalnitsky wrote: > No objections from my side. Let's do it. > > On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov > wrote: > > Hi Sergey, > > > > I fully support this idea. It was our plan as well when we were

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

AFAICT there's no such thing out of the box but it should be fairly straightforward to implement a StatsD writer using the collectd Python plugin. Simon [1] https://collectd.org/documentation/manpages/collectd-python.5.shtml I guess that’ll have to be the plan now: get

Re: [openstack-dev] Logging and traceback at same time.

On Wed, Feb 03, 2016 at 10:36:55AM +0100, Julien Danjou wrote: > On Wed, Feb 03 2016, Khayam Gondal wrote: > > > Is there a way to do logging the information and traceback at the same > > Let me know if this is correct way? > > Pass exc_info=True in your LOG.() call. Ooo, great tip! > > -- >

Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

On 02/02/2016 10:47 PM, Morgan Fainberg wrote: On Feb 2, 2016 19:38, "Yee, Guang" > wrote: > > I presume there’s a spec coming for this “seductive approach”? Not sure if I get all of it. From what’s been described here, conceptually, isn’t

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 2:37 PM, Duncan Thomas wrote: > > > On 3 February 2016 at 16:32, Sam Yaple wrote: > >> >> Looking into it, however, shows Cinder has no mechanism to delete backups >> in the middle of a chain since you use dependent backups

[openstack-dev] [puppet] compatibility of puppet upstream modules

Hi all, I have one general question, currently I am deploying liberty openstack as described in https://wiki.openstack.org/wiki/Puppet/Deploy Unfortunately puppet modules specified in puppet-openstack-integration/Puppetfile are not compatible and some are also missing as visible from following

Re: [openstack-dev] [glance] Virtual Mid-Cycle meeting next week

On 03/02/16 12:20 -0500, Nikhil Komawar wrote: Hi, The time allocation for both days Thursdays and Friday is 2 hours and the agenda proposed already seems to be already handful for the time allocated (please correct me if I am wrong). Nevertheless, I have proposed another couple of topics in

[openstack-dev] OpenStack Mentoring

Mentoring is an important tool for growing our OpenStack community.  Mentors help new community members come on board and existing community members expand their skills and reputation.  Mentees help their mentors expand their worldview and challenge their mindset. This process of gaining

Re: [openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

On 3 February 2016 at 04:28, Sean Dague wrote: > On 02/02/2016 10:03 PM, Matthew Treinish wrote: > > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote: > >> Folks, > >> > >> We have some IPv6 related bugs [1,2,3] that have been lingering for some > >> time now. They have

[openstack-dev] [tosca-parser] [heat-translator] [heat] TOSCA-Parser 0.4.0 PyPI release

Hello Everyone, On behalf of the TOSCA-Parser team, I am pleased to announce the 0.4.0 PyPI release of tosca-parser which can be downloaded from https://pypi.python.org/pypi/tosca-parser This release includes following enhancements: 1) Initial support for TOSCA Simple Profile for Network

[openstack-dev] [tacker] TOSCA-Parser 0.4.0 PyPI release

Hello Tacker team, Sorry I forgot to include the project name in the subject of the following original email, so FYI. Thanks! Regards, Sahdev Zala - Forwarded by Sahdev P Zala/Durham/IBM on 02/03/2016 09:03 PM - From: Sahdev P Zala/Durham/IBM@IBMUS To: "OpenStack Development

Re: [openstack-dev] [Magnum] Bug 1541105 options

Steve, Comments inline On 2/3/16, 3:08 PM, "Steve Gordon" wrote: >- Original Message - >> From: "Hongbin Lu" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> >> I would vote for a

Re: [openstack-dev] Logging and traceback at same time.

Excerpts from Khayam Gondal's message of 2016-02-03 11:28:52 +0500: > Is there a way to do logging the information and traceback at the same time. > Currently I am doing it like this. > > > > > > LOG.error(_LE('Record already exists: %(exception)s ' > > '\n

Re: [openstack-dev] Make a separate library from /neutron/agent/ovsdb

On 02/03/2016 12:23 PM, Petr Horacek wrote: > Hello, > > would it be possible to change /neutron/agent/ovsdb package into a > separate library, independent on openstack? It's a pity that there is > no high-level python library for ovs handling available and your > implementation seems to be

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

tOn 3 February 2016 at 17:52, Sam Yaple wrote: > This is a very similiar method to what Ekko is doing. The json mapping in > Ekko is a manifest file which is a sqlite database. The major difference I > see is Ekko is doing backup trees. If you launch 1000 instances from the >

[openstack-dev] [Magnum] Bug 1541105 options

Hey team, I've been looking into https://bugs.launchpad.net/magnum/+bug/1541105 which covers a bug with etcdctl, and I wanted opinions on how best to fix it. Should we update the image to include the latest version of etcd? Or, should we temporarily install the latest version as a part of

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 6:32 AM, Sam Yaple wrote: > [snip] > Full backups are costly in terms of IO, storage, bandwidth and time. A full > backup being required in a backup plan is a big problem for backups when we > talk about volumes that are terabytes large. > As an

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 3:36 PM, Duncan Thomas wrote: > On 3 February 2016 at 17:27, Sam Yaple wrote: > > >> >> And here we get to the meat of the matter. Squashing backups is awful in >> object storage. It requires you to pull both backups, merge them,

Re: [openstack-dev] [ironic] Third Party CI Deadlines for Mitaka and N

On 17:00 Nov 30, Mike Perez wrote: > On October 28th 2015 at the Ironic Third Party CI summit session [1], there > was > consensus by the Ironic core and participating vendors that the set of > deadlines will be: > > * Mitaka-2ː Driver teams will have registered their intent to run CI by >

[openstack-dev] [Doc] Further DocImpact Changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, TL;DR: DocImpact is changing, again, please review 276065 Some time ago, docs implemented a blueprint[1] to modify the behaviour of the DocImpact script. The agreed change was that all projects *with the exception of the five

Re: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

Dimitry Ushakov, Heat wait condition has a timeout, now the default for it is 6000 in our Heat template. I think we can change it to a reasonable value. Regards， wanghua On Thu, Feb 4, 2016 at 12:38 PM, Dimitry Ushakov < dimitry.usha...@rackspace.com> wrote: > Eli, > > I’m ok with removing

[openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

hello all, as you see that[1], gate failed to merge patch though gate since gate-functional-dsvm-magnum-api will cause timeout error and make job failed. by investigate cases in gate-functional-dsvm-magnum-api, these 2 are time costing. 2016-02-03 22:25:42.834

Re: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

Eli, I'm ok with removing that test but we'll still have the real problem, which is the fact that heat hangs in heat_stack_create while /something/ in cloud init fails to complete. Currently, the theory is that etcdctl hangs, which leaves the entire stack in the progress state [1]. Case in

Re: [openstack-dev] [Neutron] OVS flow modification performance

At Sat, 30 Jan 2016 02:08:55 +, Wuhongning wrote: > > By our testing, ryu openflow has greatly improved the performance, with 500 > port vxlan flow table, from 15s to 2.5s, 6 times better. That's quite a impressive number. What tests did you do? Could you share some details? Also,

Re: [openstack-dev] [docs][all] Software design in openstack

Josh, thanks for pointing this out and in being hospitable to an outsider. Oslo is definitely some of what I was looking for. As you stated, the fact that there is an extensive review system with high participation, that this alone organically leads to particular trends in sw design. I will

Re: [openstack-dev] [Neutron] Evolving the stadium concept

As i have commented on the patch i will also send this to the mailing list: I really dont see why Dragonflow is not part of this list, given the criteria you listed. Dragonflow is fully developed under Neutron/OpenStack, no other repositories. It is fully Open source and already have a community

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

I think we should allow magnum-api to access DB directly like nova-api. As describe in [1], nova may have many compute nodes and it may take an hour or a month to upgrade. But the number of magnum-api and magnum-conductor is limited, the upgrade of them is fast. They don't benefit from the

[openstack-dev] [tricircle] DHCP port problem

Hi all, When implementing L3 north-south networking functionality, I meet the DHCP port problem again. First let me briefly explain the DHCP port problem. In Tricircle, we have a Neutron server using Tricircle plugin in top pod to take control all the Neutron servers in bottom pods. The strategy

Re: [openstack-dev] [tricircle]Question regarding pep8 test

Hi Khayam, Could you check the version of your flake8? It's located in .tox/pep8/bin. D102 is one of the pep8 error, and I find it's not ignored in Tricircle tox.ini, so I guess that flake8 on Jenkins doesn't enable this error by default but in your flake8, this error is enabled. I check the

[openstack-dev] [release][oslo] oslo.messaging 4.1.0 release (mitaka)

We are gleeful to announce the release of: oslo.messaging 4.1.0: Oslo Messaging API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging With package available at:

[openstack-dev] [release][all] release countdown for week R-8, Feb 8-12

Focus - We have 2 more weeks before the final releases for non-client libraries for this cycle, and 3 weeks before the final releases for client libraries. Project teams should be focusing on wrapping up new feature work in all libraries. We have 3 more weeks before the Mitaka-3 milestone

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley wrote: > On 2016-02-03 14:32:36 + (+), Sam Yaple wrote: > [...] > > Luckily, digging into it it appears cinder already has all the > > infrastructure in place to handle what we had talked about in a > > separate email

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

Corey the one you are talking about has changed to coe-service-*. Eli, IMO we should display proper error message. M-api service should only have read permission. Regards, Madhuri From: Corey O'Brien [mailto:coreypobr...@gmail.com] Sent: Wednesday, February 3, 2016 6:50 PM To: OpenStack

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On 03/02/2016 9:16 AM, Foley, Emma L wrote: > AFAICT there's no such thing out of the box but it should be fairly > straightforward to implement a StatsD writer using the collectd Python plugin. > Simon > > [1]

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 3:58 PM, Duncan Thomas wrote: > On 3 February 2016 at 17:52, Sam Yaple wrote: > > >> This is a very similiar method to what Ekko is doing. The json mapping in >> Ekko is a manifest file which is a sqlite database. The major

Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases for multiple L3 backends

+1 – Good discussion in this thread. We once had the plan to go with Gantt (https://wiki.openstack.org/wiki/Gantt) rather than re-invent that wheel but… in any case we have a simple framework to start experimenting ;-) German From: Doug Wiegley

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Wed, Feb 3, 2016 at 4:53 PM, Preston L. Bannister wrote: > On Wed, Feb 3, 2016 at 6:32 AM, Sam Yaple wrote: > >> [snip] >> > Full backups are costly in terms of IO, storage, bandwidth and time. A >> full backup being required in a backup plan is a big

Re: [openstack-dev] [glance] Virtual Mid-Cycle meeting next week

Hi, The time allocation for both days Thursdays and Friday is 2 hours and the agenda proposed already seems to be already handful for the time allocated (please correct me if I am wrong). Nevertheless, I have proposed another couple of topics in the agenda that I would like be discussed briefly.

[openstack-dev] [app-catalog] IRC Meeting Thursday February 4th at 17:00UTC

Join us tomorrow for our next weekly meeting, scheduled for February 4th at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog One thing on the agenda for the 2/4/2016

[openstack-dev] [docs][all] Software design in openstack

I have been scouring OpenStack artifacts to find examples of what encourages good software design / patterns / architecture in the wider system and code. The info will be used in teaching university students. I suppose it would be good for new developers of the community too. I found

Re: [openstack-dev] [tricircle] Port Query Performance Test

On 02/03/2016 05:32 AM, Vega Cai wrote: Hi all, I did a test about the performance of port query in Tricircle yesterday. The result is attached. Three observations in the test result: (1) Neutron client costs much more time than curl, the reason may be neutron client needs to apply for a new

Re: [openstack-dev] Logging and traceback at same time.

Sean McGinnis wrote: On Wed, Feb 03, 2016 at 02:46:28PM +0800, 王华 wrote: You can use LOG.exception. Yes, I highly recommend using LOG.exception in this case. That is exactly what it's used for. LOG.exception is pretty much exactly like LOG.error, but with the additional behavior that it will

Re: [openstack-dev] [Magnum] Bug 1541105 options

Hi Corey, This is slowing down our merge rate and needs to be fixed IMHO. What risk are you talking about when using newer version of etcd ? Is it documented somewhere for the team to have a look ? -Vilobh On Wed, Feb 3, 2016 at 8:11 AM, Corey O'Brien wrote: > Hey

Re: [openstack-dev] [Magnum] Bug 1541105 options

As long as configurations for 2.2 and 2.0 are compatible we shouldn't have an issue I wouldn't think. I just don't know enough about etcd deployment to be sure about that. If we want to quickly improve the gate, I can patch the problematic areas in the templates and then we can make a blueprint

Re: [openstack-dev] [docs][all] Software design in openstack

Nick Yeates wrote: I have been scouring OpenStack artifacts to find examples of what encourages good software design / patterns / architecture in the wider system and code. The info will be used in teaching university students. I suppose it would be good for new developers of the community too.