[openstack-dev] [neutron] NeutronLibImpact: Removing deprecated model_base mixins from core

The deprecated model_base mixins are be being removed from neutron/db/model_base.py and neutron/db/models_v2.py in [1]. The mixins from neutron_lib.db.model_base should be used instead. All subproject maintainers should update their code to use the model_base mixins from neutron-lib. I have

[openstack-dev] [neutron] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

The following _MAX_LEN constants are being removed from neutron/api/v2/attributes.py in [1]. The corresponding DB field size constants from neutron_lib.db.constants should be used instead. All subproject maintainers should update their code to use the the db *_FIELD_SIZE constants from

[openstack-dev] [neutron][lbaas-v2] LBaaS v2 can't consume messages

Dear all, Recently, I built up a " all-in-one " environment about LBaaS v2 by using " haproxy " driver and the lbaas code are from master branch. And I met a strange problem. LBaaS v2 agent can not consume messages when creating loadbalancers in neutron server. I can see some queued messages by

[openstack-dev] [neutron] NeutronLibImpact: Adoption of ExtensionDescriptor from neutron-lib

The ExtensionDescriptor class has been rehomed to neutron-lib and is being removed from neutron core, see [1]. All subproject maintainers should update their code to use the ExtensionDescriptor class from neutron-lib. I have submitted patches [2] for most subprojects. This will be highlighted

Re: [openstack-dev] [Congress] Magnum_driver

Definitely push that code up into Gerrit so we can all take a look. Data like pods and containers is probably the most valuable data from Magnum, so I'd definitely recommend adding that. But push the code you have to Gerrit first. (As long as you leave the ChangeId the same each time you push

Re: [openstack-dev] [keytone] Pike PTL

Steve, You've done amazing job. Thanks for that and making keystone even better! Marek Denis ​ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

Hi all, I am looking at http://stackalytics.com/?project_type=openstack=neutron-group and I see some reviews counted for projects that are for long out of neutron stadium (f.e. dragonflow or kuryr or networking-hyperv). How can we get them excluded from the official neutron stats? I’ve

Re: [openstack-dev] [Congress] Magnum_driver

Hi Tim, You are great. It works! Thanks a lot! I've also solved the problem with py27. The unit test seems to work. The only thing that seems not to work is populate the 'clusters_links' and 'cluster_templates_links' tables: they are empty. Also, the 'labels' table is empty. I've no errors

Re: [openstack-dev] [infra][neutron] Intel NFV CI voting permission in Neutron

> On 14 Nov 2016, at 11:44, Znoinski, Waldemar > wrote: > > Hi Neutron, Infra Cores et al, > I would like to acquire voting (+/-1 Verified) permission for our Intel NFV > CI. > > 1. It's running on Neutron changes since Q1'2015. > 2. Wiki [1]. > 3. It's using

Re: [openstack-dev] [Congress] Magnum_driver

Hi Ruben, Glad you got that worked out. Once in a while I end up deleting my .tox dir because it gets out of date. I guess that's what the --recreate option to tox does. So I learned something. :) The new error message looks to be saying that an object of type 'Cluster' cannot be iterated.

[openstack-dev] [neutron] NeutronLibImpact: Removal of PLURALS

The PLURALS dict in neutron.api.v2.attributes is written to but never used. Before rehoming neutron.api.v2.attributes to neutron-lib I am removing all references to PLURALS [1]. All subproject maintainers should remove the use of PLURALS from their code. I have submitted patches [2] for most

Re: [openstack-dev] [nova] [telemetry] PostgreSQL gate broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 25/11/2016 18:24, Sylvain Bauza a écrit : > > > Le 24/11/2016 13:58, Sylvain Bauza a écrit : > > >> Le 24/11/2016 11:57, Julien Danjou a écrit : >>> Hi, > >>> It seems Nova broke its PostgreSQL support recently, and that >>> impacts

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 17:51, Jeremy Stanley wrote: On 2016-11-25 17:41:07 + (+), Miles Gould wrote: I don't think this is an insurmountable problem: it should be possible to allow users to switch between "code view" and "rendered view" for file-types that support rendering. Yes, it's "just" a

[openstack-dev] [tripleo] TripleO Squads - What's next?

I'm happy to announce we officially accepted TripleO Squads in our project: http://specs.openstack.org/openstack/tripleo-specs/specs/policy/squads.html We hope it will help us to scale our team and improve our way to work together. The next steps... I started a new etherpad:

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 2016-11-25 17:41:07 + (+), Miles Gould wrote: > I don't think this is an insurmountable problem: it should be possible to > allow users to switch between "code view" and "rendered view" for file-types > that support rendering. Yes, it's "just" a matter of writing some code (and

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 17:12, Jeremy Stanley wrote: It came down less to safety and more to the fact that if you force cgit to present rendered content then you lose the ability to reference the source code for the same files. I don't think this is an insurmountable problem: it should be possible to

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 09:15 -0800, Christopher Aedo wrote: On Fri, Nov 25, 2016 at 3:38 AM, Flavio Percoco wrote: Greetings, Just a heads up for everyone. The work on this front has moved forward and the badges are now being generated as part of the governance CI[0]. You can find

Re: [openstack-dev] [nova] [telemetry] PostgreSQL gate broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 24/11/2016 13:58, Sylvain Bauza a écrit : > > > Le 24/11/2016 11:57, Julien Danjou a écrit : >> Hi, > >> It seems Nova broke its PostgreSQL support recently, and that >> impacts Telemetry as we do gate on PostgreSQL. I opened a bug: > >>

[openstack-dev] [all] amend reference/PTI (governance) with supported distros

Hi, I recently found out that some projects in OpenStack do not gate on CentOS platform, while it's one of the most popular disto used to deploy OpenStack in production, after Ubuntu. I've decided to start a discussion and see if we would agree to officially make the statement that we support

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On Fri, Nov 25, 2016 at 3:38 AM, Flavio Percoco wrote: > Greetings, > > Just a heads up for everyone. The work on this front has moved forward and > the > badges are now being generated as part of the governance CI[0]. > > You can find the list of badges here[1] and the pattern

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 2016-11-25 11:37:02 -0500 (-0500), Paul Belanger wrote: [...] > We do have an abandoned path in gerrit to support this[3], but > infra decided to abandon it since it wasn't very safe. So, it is > possible to render markdown in cgit, we just need to confirm how > safe it is today. [...] It came

Re: [openstack-dev] [nova] [telemetry] PostgreSQL gate broken

On 24 November 2016 at 13:52, Chris Friesen wrote: > On 11/24/2016 05:57 AM, Julien Danjou wrote: >> >> Hi, >> >> It seems Nova broke its PostgreSQL support recently, and that impacts >> Telemetry as we do gate on PostgreSQL. I opened a bug: >> >>

Re: [openstack-dev] [new][nimble] New project: Nimble

On Fri, Nov 25, 2016 at 05:41:28PM +0800, Zhenguo Niu wrote: > hi all, > > We are pleased to introduce Nimble, a new OpenStack project which aims to > provide bare metal computing management. Has this name been cleared for use? Nimble is the name of a company, so like Quantum, this seems to me

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On Thu, Oct 13, 2016 at 01:06:43PM +0200, Flavio Percoco wrote: > On 12/10/16 11:01 -0400, Doug Hellmann wrote: > > Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200: > > > Greetings, > > > > > > One of the common complains about the existing project organization in > > > the

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 14:35 +, Amrith Kumar wrote: Thanks Flavio, I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I assume that other projects which want to do this kind of manual cleanup can either use this bug or create their own. Thanks Amrith, I think this is the right

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 23:49 +0900, Ian Y. Choi wrote: Hello Flavio, I have two questions on this thread: 1) I have just written my review on training-guides repository : https://review.openstack.org/#/c/402607/1 . Then would you revise your initialized patchset by yourself? Or Your intention would be

[openstack-dev] [nova] placement/resource providers update 3

More on what's happening in the resource provider and placement API world. See the first message[0] for what this about. If you have any additions or corrections please followup to this message; this is being done to help keep things moving along, if it is wrong we'll go the wrong way and that

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

Hello Flavio, I have two questions on this thread: 1) I have just written my review on training-guides repository : https://review.openstack.org/#/c/402607/1 . Then would you revise your initialized patchset by yourself? Or Your intention would be to discuss more on each repository team

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

The same for Rally project... On Thu, Oct 13, 2016 at 2:56 PM, Qiming Teng wrote: > project-navigator? http://www.openstack.org/software/ > > It is often misinterpreted as: OpenStack has 6 core services which are > all mandatory (because they are *core* services)

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

Thanks Flavio, I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I assume that other projects which want to do this kind of manual cleanup can either use this bug or create their own. -amrith > -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] >

[openstack-dev] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

> On 25 Nov 2016, at 15:23, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka wrote: >> >>> On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: >>> >>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka wrote: > >> On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: >> >> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka wrote: >>> On 25 Nov 2016, at 09:25, Takashi Yamamoto

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 13:46 +, Amrith Kumar wrote: Flavio, I see a number of patches[1] which have been landed on this project but I find that at least the ones that were landed for Trove, and a random sampling of the others all to be different from what you proposed below[2] in one important aspect.

Re: [openstack-dev] [Rally][all] Gitter as an alternative way for communication

Hi Thierry, On Fri, Nov 25, 2016 at 12:51 PM, Thierry Carrez wrote: > Andrey Kurilin wrote: > > I'm happy to announce our new chats at gitter.im : > > [...] > > While I understand where you're coming from, I would like to remind you > that the OpenStack

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On Fri, Nov 25 2016, Amrith Kumar wrote: > I see a number of patches[1] which have been landed on this project but I > find > that at least the ones that were landed for Trove, and a random sampling of > the others all to be different from what you proposed below[2] in one > important aspect.

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

Flavio, I see a number of patches[1] which have been landed on this project but I find that at least the ones that were landed for Trove, and a random sampling of the others all to be different from what you proposed below[2] in one important aspect. In [2] you proposed a structure where the

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

On Fri, Nov 25, 2016 at 7:22 AM, Gabriele Cerami wrote: > On 22 Nov, Emilien Macchi wrote: >> 1) Re-use experience from Puppet OpenStack CI and have environments >> that are in a branched repository. >> a) Move CI environments and pingtest into >>

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 12:33 +, Dulko, Michal wrote: On Fri, 2016-11-25 at 12:38 +0100, Flavio Percoco wrote: Greetings, Just a heads up for everyone. The work on this front has moved forward and the badges are now being generated as part of the governance CI[0]. You can find the list of badges

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On Fri, 2016-11-25 at 12:38 +0100, Flavio Percoco wrote: > Greetings, > > Just a heads up for everyone. The work on this front has moved > forward and the > badges are now being generated as part of the governance CI[0]. > > You can find the list of badges here[1] and the pattern is quite >

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 13:16 +0100, Flavio Percoco wrote: On 25/11/16 12:38 +0100, Flavio Percoco wrote: Greetings, Just a heads up for everyone. The work on this front has moved forward and the badges are now being generated as part of the governance CI[0]. You can find the list of badges here[1] and

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

On 22 Nov, Emilien Macchi wrote: > 1) Re-use experience from Puppet OpenStack CI and have environments > that are in a branched repository. > a) Move CI environments and pingtest into > tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo > is branched and we could add a README

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 25/11/16 12:38 +0100, Flavio Percoco wrote: Greetings, Just a heads up for everyone. The work on this front has moved forward and the badges are now being generated as part of the governance CI[0]. You can find the list of badges here[1] and the pattern is quite obvious, the name of the

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

Greetings, Just a heads up for everyone. The work on this front has moved forward and the badges are now being generated as part of the governance CI[0]. You can find the list of badges here[1] and the pattern is quite obvious, the name of the image is based on the project repo name. I've

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

> On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka wrote: >> >>> On 25 Nov 2016, at 09:25, Takashi Yamamoto wrote: >>> >>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar

Re: [openstack-dev] [Rally][all] Gitter as an alternative way for communication

Andrey Kurilin wrote: > I'm happy to announce our new chats at gitter.im : > [...] While I understand where you're coming from, I would like to remind you that the OpenStack community standardized on IRC for community communication. Maintaining alternate communication channels

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka wrote: > >> On 25 Nov 2016, at 09:25, Takashi Yamamoto wrote: >> >> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka wrote: >>> On 25 Nov 2016, at 05:26, Takashi Yamamoto

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

> On 25 Nov 2016, at 09:25, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka wrote: >> >>> On 25 Nov 2016, at 05:26, Takashi Yamamoto wrote: >>> >>> hi, >>> >>> networking-midonet doesn't have

[openstack-dev] [new][nimble] New project: Nimble

hi all, We are pleased to introduce Nimble, a new OpenStack project which aims to provide bare metal computing management. Compared with Nova, it's more bare metal specific and with more advanced features that VM users don't need, it's not bounded by Nova's API. As we know, Ironic API should

Re: [openstack-dev] [magnum-ui][horizon] use json-schema-form on workflow

From a quick scan, it looks like you're using it several times in the same workflow? Why not just use the existing tabs type and create a single form? Have a look at https://review.openstack.org/#/c/348969/for reference. Rob On 25 Nov 2016 08:28, "Shuu Mutou"

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka wrote: > >> On 25 Nov 2016, at 05:26, Takashi Yamamoto wrote: >> >> hi, >> >> networking-midonet doesn't have stable/newton branch yet. >> newton jobs failures are false alarms. >> >> branching has been

[openstack-dev] [magnum-ui][horizon] use json-schema-form on workflow

Hi Thai, We're trying to use json-schema-form in workflow, but 'required' attribute doesn't work. So we can push 'create' button without input. Could you check following patch? https://review.openstack.org/#/c/400701/ best regards, Shu Muto

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

> On 25 Nov 2016, at 05:26, Takashi Yamamoto wrote: > > hi, > > networking-midonet doesn't have stable/newton branch yet. > newton jobs failures are false alarms. > > branching has been delayed because development of some futures > planned for newton has not been