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

2016-10-02 Thread Davanum Srinivas 
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 in
> master and stable/newton.
>
> The upstream issue being tracked is:
>
> https://github.com/eliben/pycparser/issues/147
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Emilien Macchi 
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 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 dependency when
> deploying python-networking-cisco or neutron db-sync will fail."
>
> The patch has been merged in master and is being backported.
>
> Until everything is built in RDO, I'm also trying this temporary
> workaround in tripleo-ci:
> https://review.openstack.org/380870
>
> I'll +2 +A it tonight if I see that it pass all CI jobs, and give a
> status update here before end of day.
>
> On Sat, Oct 1, 2016 at 8:03 AM, Emilien Macchi  wrote:
>> Hi,
>>
>> I haven't investigated yet (I'll probably look over the week-end), but
>> I found out that all OVB jobs running in our stable/newton CI are
>> failing for the same reason:
>> neutron-db-manage fails to run:
>> https://bugs.launchpad.net/tripleo/+bug/1629542
>>
>> I pasted the Python trace, we might hit a packaging bug or something
>> backported upstream in stable:newton.
>>
>> Any help on this one is very welcome,
>> Thanks!
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Matt Riedemann 
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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Elizabeth K. Joseph 
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 items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-27-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-27-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-27-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Emilien Macchi 
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 dependency when
deploying python-networking-cisco or neutron db-sync will fail."

The patch has been merged in master and is being backported.

Until everything is built in RDO, I'm also trying this temporary
workaround in tripleo-ci:
https://review.openstack.org/380870

I'll +2 +A it tonight if I see that it pass all CI jobs, and give a
status update here before end of day.

On Sat, Oct 1, 2016 at 8:03 AM, Emilien Macchi  wrote:
> Hi,
>
> I haven't investigated yet (I'll probably look over the week-end), but
> I found out that all OVB jobs running in our stable/newton CI are
> failing for the same reason:
> neutron-db-manage fails to run:
> https://bugs.launchpad.net/tripleo/+bug/1629542
>
> I pasted the Python trace, we might hit a packaging bug or something
> backported upstream in stable:newton.
>
> Any help on this one is very welcome,
> Thanks!
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Andrew Laski 


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 standardization to all OpenStack code.
> >
> > How come we then have extensive project specific hacking rules? Why not 
> > make these "nova-specific" rules OpenStack wide?
> >
> > I looked at the checks.py file that Matt linked to below, and I can't see 
> > anything really "nova-specific"; i.e. all of them would translate just fine 
> > to Trove. Is there some reason they can't become OpenStack wide rules?

For some of them there are good reasons not to make them OpenStack wide
checks.

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n155
no db usage in virt driver.

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n168
no db session in public db api

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n201
virt drivers aren't importing modules from other virt drivers

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n220
virt drivers aren't using config options from other virt drivers

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n406
api microversion decorator is first decorator when used

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n616
check that nova specific utility method is used rather than
greenthread|eventlet.spawn|spawn_n

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n643
config options are registered in a central place

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n667
policy options are registered in a central place

http://git.openstack.org/cgit/openstack/nova/tree/nova/hacking/checks.py?h=stable/newton#n681
a nova specific context.can() method must be used for policy enforcement
rather than policy.enforce|authorize

All of these checks are either very specific to Nova or are
philosophical choices that have been made in Nova but don't need to be
shared by other projects.

And as Matt points out below some of the checks not listed above depend
on specific paths being used in the check which makes it more difficult
to share those checks.

A further hindrance to moving these checks to be OpenStack wide is that
each check violation is a failure. So in order to roll a new check out
across projects it requires a lot of churn in each project which
violates the checks. I would prefer to leave it up to each project to
make the decision to incorporate a new check and take the review load.
Ultimately what I think sounds good would be a central listing of checks
that are in use across projects and then leave it up to each project to
replicate those that they like.


> >
> > -amrith
> >
> >> -Original Message-
> >> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> >> Sent: Sunday, October 02, 2016 5:25 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: 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.
> >>>
> >>> Ah I guess the hacking rule is nova-specific:
> >>>
> >>>
> >> https://github.com/openstack/nova/blob/2851ceaed3010c19f42e308be637b952eda
> >> b092a/nova/hacking/checks.py#L342
> >>
> >> We have a similar one in neutron; but note that it does not explicitly
> >> FAIL
> >> on translation markers in test code; it instead fails on no markers in
> >> production code, which is different different.
> >>
> >> Ihar
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> Well for one thing the specific one I pointed out has hard-coded nova 
> paths in it which might not work for other projects.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
>

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

2016-10-02 Thread Fabrizio Soppelsa 
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 usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Imre Farkas 
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 mkovacik on IRC) to the
> ironic-inspector-core team. He's been pretty active on ironic-inspector
> recently, doing meaningful reviews, and he's driving our HA work forward.
>
> Please vote with +1/-1. If no objections are recorded, the change will be
> in effect next Monday.
>

+1 to both. :-)

Congrats Milan, very well deserved!

Imre



>
> Thanks!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Matt Riedemann 

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 specific hacking rules? Why not make these 
"nova-specific" rules OpenStack wide?

I looked at the checks.py file that Matt linked to below, and I can't see anything really 
"nova-specific"; i.e. all of them would translate just fine to Trove. Is there 
some reason they can't become OpenStack wide rules?

-amrith


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Sunday, October 02, 2016 5:25 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: 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.


Ah I guess the hacking rule is nova-specific:



https://github.com/openstack/nova/blob/2851ceaed3010c19f42e308be637b952eda
b092a/nova/hacking/checks.py#L342

We have a similar one in neutron; but note that it does not explicitly
FAIL
on translation markers in test code; it instead fails on no markers in
production code, which is different different.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Well for one thing the specific one I pointed out has hard-coded nova 
paths in it which might not work for other projects.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Elizabeth K. Joseph 
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 (https://review.openstack.org/#/admin/groups/1576,members) and
> trio2o-release (https://review.openstack.org/#/admin/groups/1577,members)

You have been added to these teams and can add the rest of the members.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Doug Hellmann 
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 anything out and that the version numbers are all
> correct.
> 
> This patch also includes a "diff-start" value for each release so
> that the release announcement emails will include the full history
> of a release. The values should match the tag used to create the
> stable/mitaka branch for each repository (so that all of the DAG
> content between that point and the tip of stable/newton are included).
> 
> Please take a few minutes between now and Thursday to look over the
> deliverable file changes for your projects, and comment on the patch
> if you spot anything that looks off.
> 
> https://review.openstack.org/#/c/380478
> 
> Thanks!
> Doug
> 

There seems to be a little confusion about the diff-start values,
which makes sense because it's not something we've ever asked you
to look at before and I didn't give much detail. I'm asking for
help with it this cycle, because we got the announcements wrong
last cycle and added diff-start to address that problem.

When we compute the changes for newton, we want to look at the
entire history of newton. That includes the stable/newton branch,
but it also includes a large part of the master branch between the
point where we created the stable/mitaka branch and the stable/newton
branch. It does *not* include changes that were on the stable/mitaka
branch, because presumably those were either unique (and not part
of newton) or backports (and will be on the master branch segment
we're scanning).

Given a history graph like this:

m  n  m
i  e  a
t  w  s
a  t  t
k  o  e
a  n  r
|  |  |
V  V  V

  C - master HEAD
  |
   B  | - newton RC*, to be newton final
   |  |
A  |  | - most recent mitaka release
|  |  |
|  D' D - patch backported from master to stable/newton
|  |  |
E  |  | - mitaka RC2
|  |  |
F  |  | - patch only on newton (such as a requirements update)
|  \  |
|   \ |
|\G - newton RC1 (start of stable/newton branch)
\ |
 H'   H - a patch in newton that was backported to stable/mitaka
  \   |
   \  I - a patch in newton but not backported to stable/mitaka
\ |
 \J - mitaka RC1 (start of stable/mitaka)
  |
  K - older patch before mitaka RC1

We want to include B (as the RC candidate we are re-tagging), D'
(as a patch that was backported to stable/newton after the branch
was created), G (as the first release candidate for newton), H (a
patch in newton that was also backported to stable/mitaka), and I
(a patch that was not backported to mitaka). Then we want to stop
when we reach J, the point where stable/mitaka was created.

We do not want to include H' (because it is redundant with the copy
of H in the master segment) or F, E, or A (because those are all
commits/tags that were added to stable/mitaka after it was branched
from master).

The diff-start value therefore should correspond with the tag at
J.  I am reasonably confident that for mitaka that is the RC1 tag
for all of the milestone projects. I'll be working on verifying
that mechanically early this week. If you know for certain that
your project was branched later than RC1, let me know.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Chris Dent 


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 awesome but lest we
forget them I've spent a bit of time coming up with a list of leftovers
for things we have already started and not quite finished. Some of these
we knew we were going to punt to Ocata, others are things that have come
up as a result of the work but were not in the original plan. Some are
things I thought up while in the bathtub so could be completely wrong.
Please check my work; I'm sure I've forgotten some things and care about
other things that most don't find relevant.

I'm posting this as it would be great to get some feedback on:

* which of these things matter
* what is missing from the list
* how (or if) we should formalize the doing of the work
* who would like to help out in the doing (getting some help is the main
  goal, all the rest of is set up)

To avoid this being overly long I've kept description to a minimum. If
you'd like some clarification, please ask.

Once we've figured out some form of a plan I'll make sure it gets
recorded in the right place. Before that happens though, I'd like to
hash this out to a reasonable list.

I've added links to in progress stuff where I'm aware of it.

-=-=-

# Things Planned But Not Yet Done

* Aggregate handling
  https://review.openstack.org/#/c/362863/

* Install docs

* API ref docs

* Resource tracker aware of shared resource providers

* Scheduler knows about inventories

* Object crud notifications
  https://review.openstack.org/#/c/308503/
  (way out of date)

* Inventory update example script
  https://github.com/cdent/updateinv
  (also rather out of date and very WIPpy, will be moved to
  nova:contrib)

# Features Needed Sooner or Later

* Microversion handling
  experiment at 
https://gist.github.com/cdent/de50cb05a7ab8219cd4f5b4ab3c181dd
  (This is mostly the Nova way of handling things, modified to work with
  the placement APIs classless style.)

* oslo_policy based authorization handling
  Current auth is admin-role-required for everything

* Uncaught exception transformation
  (there are a couple places where exceptions are rising out
  of the placement app to be caught in FaultWrap, these are
  supposed to become webob responses sooner)

* Optional placement db
  https://review.openstack.org/362766

* More informative 404 handling
  (bare exception.NotFound that don't say what's not found)

* Server retries allocations itself

* Expand discovery json doc
  (current doc only reports microversions, not available resources)

* Add CORS support
  (because we'd like things like horizon to be about to report usages)

* Allocations respecting min_unit etc
  https://bugs.launchpad.net/nova/+bug/1623545

# Cleanup/Refactoring

* Hygienic refactoring (files that are too big, too multi purpose)
  (resource_providers.py is huge and hold lots of objects, ditto for
  test_resource_provider.py (unit and function))

* Refactor/clean/correct json schema to be more accurate readable and
  enforcing
  (current schemas are bug lumps, readability could be enhanced by
  extracting the meaningful meat from the surrounding setup)

* Cleanup clarify wsgi.py/deploy.py overlap
  (they are both performing some parts of setting up the wsgi app,
  boundary unclear)

* Gabbi test decomposition
  (too much per file)

* Decompose handler.py
  (move routes elsewhere)

* Extract http handling in SchedulerReportClient to own file

# Testing Completeness

* Coverage audit and fix
  (because that's just polite)

* Use optional placement db in a gate job

* Performance evaluation
  (allocations per second on one inventory, allocations per second
  across many inventories, where's the knee?)

* Tempest or other form of integration test
  (currently we can only evaluate success of resource tracker +
  placement api by lack of smoke, no real details)

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Amrith Kumar 
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 "nova-specific" rules OpenStack wide?

I looked at the checks.py file that Matt linked to below, and I can't see 
anything really "nova-specific"; i.e. all of them would translate just fine to 
Trove. Is there some reason they can't become OpenStack wide rules?

-amrith

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Sunday, October 02, 2016 5:25 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: 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.
> >
> > Ah I guess the hacking rule is nova-specific:
> >
> >
> https://github.com/openstack/nova/blob/2851ceaed3010c19f42e308be637b952eda
> b092a/nova/hacking/checks.py#L342
> 
> We have a similar one in neutron; but note that it does not explicitly
> FAIL
> on translation markers in test code; it instead fails on no markers in
> production code, which is different different.
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-02 Thread Ihar Hrachyshka 

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.


Ah I guess the hacking rule is nova-specific:

https://github.com/openstack/nova/blob/2851ceaed3010c19f42e308be637b952edab092a/nova/hacking/checks.py#L342


We have a similar one in neutron; but note that it does not explicitly FAIL  
on translation markers in test code; it instead fails on no markers in  
production code, which is different different.


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev