Re: [openstack-dev] [infra]please help to add initial members to trio2o-core and trio2o-release group

On Wed, Sep 28, 2016 at 6:54 PM, joehuang wrote: > Hello, > > Trio2o is a new project which is derived from Tricircle: > https://review.openstack.org/#/c/367114/ > > Please add the initial members (same as that in Tricircle) to the group > trio2o-core

Re: [openstack-dev] [ironic] ironic-inspector-core team update

On Mon, Sep 26, 2016 at 11:24 AM, Dmitry Tantsur wrote: > Hi folks! > > As you probably know, Imre has decided to leave us for other challenges, > so our small core team has become even smaller. I'm removing him on his > request. > > I suggest adding Milan Kovacik (milan or

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

On 10/2/2016 5:47 AM, Amrith Kumar wrote: It was my understanding that hacking rules were like the 'Ten Commandments', the 'Four Opens'; things that were universally true across all projects and an attempt to bring standardization to all OpenStack code. How come we then have extensive project

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

On Sun, Oct 2, 2016, at 11:02 AM, Matt Riedemann wrote: > On 10/2/2016 5:47 AM, Amrith Kumar wrote: > > It was my understanding that hacking rules were like the 'Ten > > Commandments', the 'Four Opens'; things that were universally true across > > all projects and an attempt to bring

[openstack-dev] [magnum] Swarm Mode -- to come?

Hello, how about the (newest) Swarm Mode (Docker 1.12+) support in Magnum? I don’t find any blueprint on Launchpad on the matter yet, is this going to be worked? Ta, Fabrizio. __ OpenStack Development Mailing List (not for

[openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

There was a pycparser 2.14 package update on pypi today which is making cinder-manager db sync fail. This is making all dsvm/grenade jobs fail in master and stable/newton. The upstream issue being tracked is: https://github.com/eliben/pycparser/issues/147 -- Thanks, Matt Riedemann

Re: [openstack-dev] [tripleo] all OVB jobs failing on stable/newton - neutron fails to sync db

I confirm the issue should be solved by the packaging fix, I've seen OVB jobs passing CI now :-) I closed the bug, please let me know if you still see some errors in our gate. Thanks, On Sun, Oct 2, 2016 at 6:22 PM, Emilien Macchi wrote: > A bit of investigation drove me to

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

Fun start for release week :) Thanks for the heads up Matt -- Dims On Sun, Oct 2, 2016 at 8:54 PM, Matt Riedemann wrote: > There was a pycparser 2.14 package update on pypi today which is making > cinder-manager db sync fail. This is making all dsvm/grenade jobs fail

Re: [openstack-dev] [tripleo] all OVB jobs failing on stable/newton - neutron fails to sync db

A bit of investigation drove me to a new dependency required by python-networking-cisco. I proposed the new dependency in RDO: https://review.rdoproject.org/r/#/c/2889/ "Since https://review.openstack.org/#/c/377937/ has been merged upstream, we now require python-neutron-tests as a package

[openstack-dev] [Infra] Meeting Tuesday October 4th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday October 4th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda

Re: [openstack-dev] [all][i18n] do we need translation mark for strings in tests?

Matt Riedemann wrote: On 10/1/2016 5:49 PM, Matt Riedemann wrote: No you shouldn't need to mark strings for translation in test code. I believe we have a hacking rule for marking LOG.info/warning/error messages for translation but it should skip test directories.

[openstack-dev] [all] Why do we have project specific hacking rules?

It was my understanding that hacking rules were like the 'Ten Commandments', the 'Four Opens'; things that were universally true across all projects and an attempt to bring standardization to all OpenStack code. How come we then have extensive project specific hacking rules? Why not make these

[openstack-dev] [nova][placement] placement newton leftovers

A week or so ago, Jay posted a latest news on the placement API and some plans for Ocata: http://lists.openstack.org/pipermail/openstack-dev/2016-September/104443.html We're gearing up for the next steps (traits, custom resource classes, the scheduler using inventories, etc). This is

Re: [openstack-dev] [release][ptl] please review versions for final newton release

Excerpts from Doug Hellmann's message of 2016-09-30 14:57:53 -0400: > I have prepared a patch to openstack/releases to re-tag all of the > current release candidates using their final release version numbers. > > I could use some assistance reviewing the results to ensure that I > have not left