Re: [openstack-dev] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Ruby Loo]

On Thu, Nov 16, 2017 at 1:17 PM, Matt Riedemann  wrote:

> On 11/16/2017 12:15 PM, Matt Riedemann wrote:
>
>> On 11/16/2017 9:58 AM, Jeremy Stanley wrote:
>>
>>> On 2017-11-16 15:17:58 +0900 (+0900), Takashi Natsume wrote:
>>>
 In nova-specs project, there is an 'openstack-tox-py27' job (in
 Zuul check or Zuul gate). The job checks whether spec files comply
 with the template or not, line length, etc. But there are cases
 that the job is not executed even if a spec file is added or
 modified.

>>> [...]
>>>
>>> Most projects want to have their unit test jobs skipped on changes
>>> which only alter documentation. The nova-specs repo is unusual in
>>> that it's attempting to leverage a unit testing job to validate
>>> documentation formatting rather than the sorts of docs linters other
>>> projects rely on.
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Yeah, in other words, the job definition skips the files that we care
>> about in nova-specs:
>>
>> https://github.com/openstack-infra/openstack-zuul-jobs/blob/
>> 00168bf82cf4a13ac6339736667dd532eeeff4e9/zuul.d/jobs.yaml#L238
>>
>> So we'll probably need to change the definition of the nova-specs py27
>> job to run these linter type tests in the pep8 run.
>>
>>
> By the way, it looks like neutron-specs and cinder-specs are going to have
> the same problem.
>
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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
>


We had a similar problem with ironic-specs, and ended up going with
openstack-tox-linters because we do doc8 and some unit tests that do
fancy-schmancy (i.e. I don't remember what) checking :)

--ruby
__
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] [glance] nominating Nikhil Komawar for glance core

[Abhishek Kekane]

Big +2
Glad you are back :)

Abhishek

On 17-Nov-2017 4:59 AM, "Brian Rosmaita"  wrote:

> I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
> was Glance PTL for the Kilo, Liberty, and Newton releases and who was
> a long time Glance core until he stepped down at the end of June this
> year.  Nikhil has informed me that he now has time to do Glance code
> reviews again, and I will be happy to have his experience and
> knowledge of the Glance code base available to inform our code
> reviews, and I propose to reinstate him as a member of the glance core
> team.
>
> I discussed this with the other cores present at today's weekly Glance
> meeting, and they support reinstating Nikhil, so I don't see any
> reason to have a long waiting period.  I'd like to add Nikhil to the
> core list on Monday, November 20, so if anyone has any comments or
> concerns, please let me know before then.
>
> thanks!
> brian
>
> __
> 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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Sean McGinnis]

> > 
> > I think this is the approach we will likely want:
> > 
> > https://review.openstack.org/#/c/520823/
> > 
> 
> I don't have time to look into it right now, but we probably shouldn't run
> openstack-tox-py27 against these repos in the first place, especially after
> this change. It is just wasting infra resources to literally do nothing.
> 
> We are not running pep8 jobs against these repos, which we probably should do
> now that that will actually catch RST formatting issues in newly proposed
> specs.
> 

And the patch to switch jobs to run pep8:

https://review.openstack.org/#/c/520844/

__
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] [glance] nominating Nikhil Komawar for glance core

[Brian Rosmaita]

I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
was Glance PTL for the Kilo, Liberty, and Newton releases and who was
a long time Glance core until he stepped down at the end of June this
year.  Nikhil has informed me that he now has time to do Glance code
reviews again, and I will be happy to have his experience and
knowledge of the Glance code base available to inform our code
reviews, and I propose to reinstate him as a member of the glance core
team.

I discussed this with the other cores present at today's weekly Glance
meeting, and they support reinstating Nikhil, so I don't see any
reason to have a long waiting period.  I'd like to add Nikhil to the
core list on Monday, November 20, so if anyone has any comments or
concerns, please let me know before then.

thanks!
brian

__
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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Sean McGinnis]

On Thu, Nov 16, 2017 at 04:42:11PM -0600, Sean McGinnis wrote:
> On Thu, Nov 16, 2017 at 01:41:56PM -0600, Sean McGinnis wrote:
> > On Thu, Nov 16, 2017 at 12:58:38PM -0600, Matt Riedemann wrote:
> > > >>
> > > >>So we'll probably need to change the definition of the nova-specs py27
> > > >>job to run these linter type tests in the pep8 run.
> > > >>
> > > >
> 
> [snip]
> 
> > > 
> > 
> > The right answer is probably to just switch those to run doc8 against the
> > specs, since it appears the "tests" we have in there just try to do what 
> > that
> > tools is for.
> > 
> > Working on a cinder-specs patch to do that now.
> > 
> 
> I think this is the approach we will likely want:
> 
> https://review.openstack.org/#/c/520823/
> 

I don't have time to look into it right now, but we probably shouldn't run
openstack-tox-py27 against these repos in the first place, especially after
this change. It is just wasting infra resources to literally do nothing.

We are not running pep8 jobs against these repos, which we probably should do
now that that will actually catch RST formatting issues in newly proposed
specs.

__
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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Sean McGinnis]

On Thu, Nov 16, 2017 at 01:41:56PM -0600, Sean McGinnis wrote:
> On Thu, Nov 16, 2017 at 12:58:38PM -0600, Matt Riedemann wrote:
> > >>
> > >>So we'll probably need to change the definition of the nova-specs py27
> > >>job to run these linter type tests in the pep8 run.
> > >>
> > >

[snip]

> > 
> 
> The right answer is probably to just switch those to run doc8 against the
> specs, since it appears the "tests" we have in there just try to do what that
> tools is for.
> 
> Working on a cinder-specs patch to do that now.
> 

I think this is the approach we will likely want:

https://review.openstack.org/#/c/520823/


__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[gordon chung]

On 2017-11-16 03:29 PM, Waines, Greg wrote:
> Ok ... if you don’t mind, i might create a blueprint anyways ... for 
> traceability and documentation purposes.
> 
> We/WindRiver tracks both blueprints and code submissions that we have 
> worked on, as an indication of our upstream contributions.
>
as you wish, as long as you're aware that no one reads it :). we do 
track features under bugs in launchpad[1] and just mark them as wishlist 
normally but i'm not going to stop you from creating a bp. you'll just 
need to ping someone to mark it as implemented when the time comes.

[1] https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0

cheers,

-- 
gord
__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[Waines, Greg]

Ok ... if you don’t mind, i might create a blueprint anyways ... for 
traceability and documentation purposes.
We/WindRiver tracks both blueprints and code submissions that we have worked 
on, as an indication of our upstream contributions.

Greg.


From: gordon chung 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, November 16, 2017 at 2:59 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' 
publisher: Compression and CSV file format



On 2017-11-16 02:48 PM, Waines, Greg wrote:
Cool ... i will go ahead and submit a blueprint for these.

just an fyi, we don't use blueprints in Telemetry projects. just submit
the code :)

if there's many alternatives to the solution or if it's a something
controversial, we usually discuss it here on ML. in this case, it seems
like a pretty regular feature addition.

Wrt the compression blueprint,  locally we subclassed the base python
rotating file handler class in order to optionally compress the file as
part of the “shouldRollover” stage.

sounds good.

--
gord
__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[gordon chung]

On 2017-11-16 02:48 PM, Waines, Greg wrote:
> Cool ... i will go ahead and submit a blueprint for these.

just an fyi, we don't use blueprints in Telemetry projects. just submit 
the code :)

if there's many alternatives to the solution or if it's a something 
controversial, we usually discuss it here on ML. in this case, it seems 
like a pretty regular feature addition.

> 
> Wrt the compression blueprint,  locally we subclassed the base python 
> rotating file handler class in order to optionally compress the file as 
> part of the “shouldRollover” stage.
> 

sounds good.

-- 
gord
__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[Waines, Greg]

Cool ... i will go ahead and submit a blueprint for these.

Wrt the compression blueprint,  locally we subclassed the base python rotating 
file handler class in order to optionally compress the file as part of the 
“shouldRollover” stage.

Greg.


From: gordon chung 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, November 16, 2017 at 1:49 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' 
publisher: Compression and CSV file format



On 2017-11-16 12:44 PM, Waines, Greg wrote:
1.Compression of files (within file rotation) to minimize disk usage and
minimize bandwidth in FTP-ing these files off server
oi.e. as part of file rotation, the newly rotated file would be gzip’d
to compress the file
othis would be an optional parameter in the pipeline definition in
/etc/ceilometer/pipeline.yaml
e.g.
name: meter_file
meters:
  - "*"
publishers:
  - file:///var/test?max_bytes=1000_count=5=true
oagain,
minimizing disk usage and minimizing network bandwidth in FTP-ing these
files off server.

seems like a good idea. just curious, how would you implement this?

2.CSV (Comma Separated Values) File Format
oCSV is widely supported for many off-box Statistical Analysis-type
Tools; especially in Telecom,
oagain this would be done as an optional argument to the file publisher
§the existing format (python dictionary print) would remain as the
default format
§‘format=csv’ would be the argument added to the publisher line in order
to enable CSV format
e.g.
name: meter_file
meters:
  - "*"
publishers:
  - file:///var/test?max_bytes=1000_count=5=csv

this sounds like a good idea. i believe there was a bug previously that
suggested cleaning up the output of the file publisher/dispatcher so
it's not just dumping random blurbs of json. i think the proposed
format=csv trigger makes sense.

I think these would be valuable addons to the Ceilometer File Publisher,

agreed! thanks for suggesting them. this is me assuming you (or a
colleague) will implement this :)

--
gord
__
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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Sean McGinnis]

On Thu, Nov 16, 2017 at 12:58:38PM -0600, Matt Riedemann wrote:
> >>
> >>So we'll probably need to change the definition of the nova-specs py27
> >>job to run these linter type tests in the pep8 run.
> >>
> >
> >By the way, it looks like neutron-specs and cinder-specs are going to have
> >the same problem.
> 
> I don't know if this is what we want to do, but this change removes the py27
> target for nova-specs and runs the same tests under pep8:
> 
> https://review.openstack.org/#/c/520680/
> 
> -- 
> 
> Thanks,
> 
> Matt
> 

The right answer is probably to just switch those to run doc8 against the
specs, since it appears the "tests" we have in there just try to do what that
tools is for.

Working on a cinder-specs patch to do that now.

Sean


__
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][all] Removal of packages from bindep-fallback

[Paul Belanger]

On Thu, Nov 16, 2017 at 04:59:01PM +1100, Ian Wienand wrote:
> Hello,
> 
> Some time ago we started the process of moving towards projects being
> more explicit about thier binary dependencies using bindep [1]
> 
> To facilitate the transition, we created a "fallback" set of
> dependencies [2] which are installed when a project does not specifiy
> it's own bindep dependencies.  This essentially replicated the rather
> ad-hoc environment provided by CI images before we started the
> transition.
> 
> This list has acquired a few packages that cause some problems in
> various situations today.  Particularly packages that aren't in the
> increasing number of distributions we provide, or packages that come
> from alternative repositories.
> 
> To this end, [3,4] proposes the removal of
> 
>  liberasurecode-*
>  mongodb-*
>  python-zmq
>  redis
>  zookeeper
>  ruby-*
> 
> from the fallback packages.  This has a small potential to affect some
> jobs that tacitly rely on these packages.
> 
> NOTE: this does *not* affect devstack jobs (devstack manages it's own
> dependencies outside bindep) and if you want them back, it's just a
> matter of putting them into the bindep file in your project (and as a
> bonus, you have better dependency descriptions for your code).
> 
> We should be able to then remove centos-release-openstack-* from our
> centos base images too [5], which will make life easier for projects
> such as triple-o who have to work-around that.
> 
> If you have concerns, please reach out either via mail or in
> #openstack-infra
> 
> Thank you,
> 
> -i
> 
> [1] https://docs.openstack.org/infra/bindep/
> [2] 
> https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/data/bindep-fallback.txt
> [3] https://review.openstack.org/519533
> [4] https://review.openstack.org/519534
> [5] https://review.openstack.org/519535
> 
++

I think we are in good shape to move forward here, I know a lot of projects of
the last 12 months have moved to intree bindep.txt files, but not every thing.

__
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-job-failures][neutron][infra][all] Tag of openstack/neutron-fwaas-dashboard failed

[Sean McGinnis]

> > 
> > Looking at  the openstackdocstheme document [1], PDF generation
> > expects 'release' variable
> > but AFAIK we only generate HTML version of release notes and I think
> > we can drop 'release'
> > and 'version' variables from conf.py.
> > 
> > [1] https://docs.openstack.org/openstackdocstheme/latest/
> 
> the job has been improved to try - fow now - install the repo. So, we
> only need to fix now repos that need additional dependencies, like
> horizon and neutron related projects. I'm updating all of them now and
> would appreciate speedy review,
> 
> https://review.openstack.org/#/q/topic:releasenotes-version+is:open
> 
> Andreas

I had started a few patches as well:

https://review.openstack.org/#/q/topic:remove_reno_vers+is:open


__
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-job-failures][neutron][infra][all] Tag of openstack/neutron-fwaas-dashboard failed

[Andreas Jaeger]

On 2017-11-16 11:45, Akihiro Motoki wrote:
> 2017-11-16 19:33 GMT+09:00 Andreas Jaeger :
>> On 2017-11-16 11:27, Akihiro Motoki wrote:
>>> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
 On 2017-11-15 19:07, Doug Hellmann wrote:
> [...]
> Someone needs to figure that out. Unfortunately, I don't have the
> bandwidth right now. Maybe you, or someone else from one of the affected 
> projects, can work on it?
>
> Two options have been discussed so far:
>
> 1. Create special jobs for neutron and horizon projects that install
>neutron or horizon, like we do for the release jobs.
>
> 2. Redefine the release notes job so that it doesn't use tox
>but installs only the pieces it needs to run a sphinx build. The
>CTI is already defined in a way to support that [1].
>
> My current preference is for option 2. There may be other options
> that we haven't explored, though.
 I gave it a try in https://review.openstack.org/520362. Note that this
 is only the building part, publishing part is separate - let's first
 iterate on this one,
>>> I noticed most projects require to install themselves now to set
>>> 'version' and 'release' variables in releasenotes/source/conf.py.
>>> For example, 
>>> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
>>> I think we cannot build release notes without installing a project itself.
>>
>> That's really sad ;(
>>
>> But why would we need to set version and release for the releasenotes at
>> all? We only have one - unversioned - document.
>>
>> I suggest to just get rid of it,
> 
> Totally agree.
> 
> I think when we migrated to openstckdocstheme version info was shown
> in the rendered text
> so we started to use version info in conf.py. Some projects started it
> and most projects followed it.
> After migrating openstckdocstheme there is no visible version info in
> the rendered relnotes,
> so I think we can drop it.
> 
> Looking at  the openstackdocstheme document [1], PDF generation
> expects 'release' variable
> but AFAIK we only generate HTML version of release notes and I think
> we can drop 'release'
> and 'version' variables from conf.py.
> 
> [1] https://docs.openstack.org/openstackdocstheme/latest/

the job has been improved to try - fow now - install the repo. So, we
only need to fix now repos that need additional dependencies, like
horizon and neutron related projects. I'm updating all of them now and
would appreciate speedy review,

https://review.openstack.org/#/q/topic:releasenotes-version+is:open

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Matt Riedemann]

On 11/16/2017 12:17 PM, Matt Riedemann wrote:
Yeah, in other words, the job definition skips the files that we care 
about in nova-specs:


https://github.com/openstack-infra/openstack-zuul-jobs/blob/00168bf82cf4a13ac6339736667dd532eeeff4e9/zuul.d/jobs.yaml#L238 



So we'll probably need to change the definition of the nova-specs py27 
job to run these linter type tests in the pep8 run.




By the way, it looks like neutron-specs and cinder-specs are going to 
have the same problem.


I don't know if this is what we want to do, but this change removes the 
py27 target for nova-specs and runs the same tests under pep8:


https://review.openstack.org/#/c/520680/

--

Thanks,

Matt

__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[gordon chung]

On 2017-11-16 12:44 PM, Waines, Greg wrote:
> 
> 1.Compression of files (within file rotation) to minimize disk usage and 
> minimize bandwidth in FTP-ing these files off server
> 
> oi.e. as part of file rotation, the newly rotated file would be gzip’d 
> to compress the file
> 
> othis would be an optional parameter in the pipeline definition in 
> /etc/ceilometer/pipeline.yaml
> e.g.
> 
> name: meter_file
> 
> meters:
> 
>      - "*"
> 
> publishers:
> 
>      - file:///var/test?max_bytes=1000_count=5=true
> 
> oagain,
> minimizing disk usage and minimizing network bandwidth in FTP-ing these 
> files off server.

seems like a good idea. just curious, how would you implement this?

> 
> 2.CSV (Comma Separated Values) File Format
> 
> oCSV is widely supported for many off-box Statistical Analysis-type 
> Tools; especially in Telecom,
> 
> oagain this would be done as an optional argument to the file publisher
> 
> §the existing format (python dictionary print) would remain as the 
> default format
> 
> §‘format=csv’ would be the argument added to the publisher line in order 
> to enable CSV format
> e.g.
> 
> name: meter_file
> 
> meters:
> 
>      - "*"
> 
> publishers:
> 
>      - file:///var/test?max_bytes=1000_count=5=csv
>
this sounds like a good idea. i believe there was a bug previously that 
suggested cleaning up the output of the file publisher/dispatcher so 
it's not just dumping random blurbs of json. i think the proposed 
format=csv trigger makes sense.

> 
> I think these would be valuable addons to the Ceilometer File Publisher,
> 

agreed! thanks for suggesting them. this is me assuming you (or a 
colleague) will implement this :)

-- 
gord
__
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] [tripleo] Migrating TripleO CI in-tree tomorrow - please README

[Emilien Macchi]

TL;DR: don't approve or recheck any tripleo patch from now, until
further notice on this thread.

Some good progress has been made on migrating legacy tripleo CI jobs
to be in-tree:
https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3

The next steps:
- Let the current gate to finish their jobs running.
- Stop approving patches from now, and wait the gate to be done and cleared
- Alex and I will approve the migration patches tomorrow and we hope
to have them in the gate by Friday afternoon (US time) when gate isn't
busy anymore. We'll also have to backport them all.
- When these patches will be merged (it might take the weekend to
land, depending how the gate will be), we'll run duplicated jobs until
https://review.openstack.org/514778 is merged. I'll try to ping
someone from Infra over the week-end if we can land it, that would be
great.
- Once https://review.openstack.org/514778 is merged, people are free
to do recheck or approve any patches. We hope it should happen over
the weekend.
- I'll continue to migrate all other tripleo projects to have in-tree
layout. On the list: t-p-e, t-i-e, paunch, os-*-config,
tripleo-validations.

Thanks for your help,
-- 
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] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Matt Riedemann]

On 11/16/2017 12:15 PM, Matt Riedemann wrote:

On 11/16/2017 9:58 AM, Jeremy Stanley wrote:

On 2017-11-16 15:17:58 +0900 (+0900), Takashi Natsume wrote:

In nova-specs project, there is an 'openstack-tox-py27' job (in
Zuul check or Zuul gate). The job checks whether spec files comply
with the template or not, line length, etc. But there are cases
that the job is not executed even if a spec file is added or
modified.

[...]

Most projects want to have their unit test jobs skipped on changes
which only alter documentation. The nova-specs repo is unusual in
that it's attempting to leverage a unit testing job to validate
documentation formatting rather than the sorts of docs linters other
projects rely on.



__ 


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



Yeah, in other words, the job definition skips the files that we care 
about in nova-specs:


https://github.com/openstack-infra/openstack-zuul-jobs/blob/00168bf82cf4a13ac6339736667dd532eeeff4e9/zuul.d/jobs.yaml#L238 



So we'll probably need to change the definition of the nova-specs py27 
job to run these linter type tests in the pep8 run.




By the way, it looks like neutron-specs and cinder-specs are going to 
have the same problem.


--

Thanks,

Matt

__
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] [nova] [infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Matt Riedemann]

On 11/16/2017 9:58 AM, Jeremy Stanley wrote:

On 2017-11-16 15:17:58 +0900 (+0900), Takashi Natsume wrote:

In nova-specs project, there is an 'openstack-tox-py27' job (in
Zuul check or Zuul gate). The job checks whether spec files comply
with the template or not, line length, etc. But there are cases
that the job is not executed even if a spec file is added or
modified.

[...]

Most projects want to have their unit test jobs skipped on changes
which only alter documentation. The nova-specs repo is unusual in
that it's attempting to leverage a unit testing job to validate
documentation formatting rather than the sorts of docs linters other
projects rely on.



__
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



Yeah, in other words, the job definition skips the files that we care 
about in nova-specs:


https://github.com/openstack-infra/openstack-zuul-jobs/blob/00168bf82cf4a13ac6339736667dd532eeeff4e9/zuul.d/jobs.yaml#L238

So we'll probably need to change the definition of the nova-specs py27 
job to run these linter type tests in the pep8 run.


--

Thanks,

Matt

__
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] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

[Waines, Greg]

Hey there,

I am looking for some feedback on 2x enhancement / blueprint proposals for the 
‘file’ publisher in ceilometer.
i.e.   
https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/file.py


Are the Ceilometer owners open to looking at blueprints for the following ?


1.   Compression of files (within file rotation) to minimize disk usage and 
minimize bandwidth in FTP-ing these files off server

oi.e. as part of file rotation, the newly rotated file would be gzip’d to 
compress the file

othis would be an optional parameter in the pipeline definition in 
/etc/ceilometer/pipeline.yaml
e.g.
name: meter_file
meters:
- "*"
publishers:
- file:///var/test?max_bytes=1000_count=5=true

oagain,
minimizing disk usage and minimizing network bandwidth in FTP-ing these files 
off server.


2.   CSV (Comma Separated Values) File Format

oCSV is widely supported for many off-box Statistical Analysis-type Tools; 
especially in Telecom,

oagain this would be done as an optional argument to the file publisher

§  the existing format (python dictionary print) would remain as the default 
format

§  ‘format=csv’ would be the argument added to the publisher line in order to 
enable CSV format
e.g.
name: meter_file
meters:
- "*"
publishers:
- file:///var/test?max_bytes=1000_count=5=csv




let me know your feedback,

I think these would be valuable addons to the Ceilometer File Publisher,

Greg.

__
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] [networking-bagpipe] [networking-bgpvpn] missing tarballs for queens milestone 1

[James Page]

Hi

Corey and I have been working through the first Queens milestones for
Ubuntu (and the UCA) - both networking-bagpipe and networking-bgpvpn don't
have published tarballs on tarballs.openstack.org.

Would it be possible to get those up? or we can cut our own from the git
repo for this milestone if that's not possible.

Cheers

James
__
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] Updates on the TripleO on Kubernetes work

[James Slagle]

On Thu, Nov 16, 2017 at 8:44 AM, Flavio Percoco  wrote:
> Integration with TripleO Heat Templates
> ===
>
> This work is on-going and you should eventually see some patches popping-up
> on
> the reviews list. One of the goals, besides consuming these ansible roles
> from
> t-h-t, is to be able to create a PoC for upgrades and have an end-to-end
> test/demo of this work.
>
> As we progress, we are trying to nail down an end-to-end deployment before
> creating roles for all the services that are currently supported by TripleO.
> We
> will be adding projects as needed with a focus on the end-to-end goal.

When we consume these ansible-role-k8s-* roles from t-h-t, I think
that should be a stepping stone towards migrating away from having to
use Heat to deploy and configure those services. We know that these
new ansible roles will be deployable standalone, and the interface to
do that should be typical ansible best practices (role defaults, vars,
etc).

We can offer a mechanism such that one can migrate from a
tripleo-heat-templates/docker/services/database/mysql.yaml deployed
mariadb to one deployed via
ansible-role-k8s-mariadb. The config-download mechanism could be
updated to generate or pull from Heat the necessary ansible vars files
for configuring the roles. We should make sure that the integration
with tripleo-heat-templates results in the same inputs/outputs that
someone would consume if using the roles standalone. Future iterations
would then not have to require Heat for that service at all, unless
the operator wanted to continue to configure the service via Heat
parameters/environments.

What I'm trying to propose is a path towards deprecating the Heat
parameter/environment driven and hieradata driven approach to
configuring the services. The ansible-role-k8s-* roles should offer a
new interface, so I don't think we have to remain tied to Heat
forever, so we should consider what we want the long term goal to be
in an ideal world, and take some iterative steps to get there.

It's probably worthwhile as a thought experiment to update this
diagram[0] as to how it might look at different future stages. The
first stage might just be t-h-t driven ansible-role-k8s-* , followed
by a migration to ansible-role-k8s-* as the primary interface, and
then finally perhaps no Heat[1].

[0] https://slagle.fedorapeople.org/tripleo-ansible-arch.png
[1] Except for perhaps deployment of baremetal resources, but even
then I'm personally of the opinion that would be better serviced by
Mistral->Ansible->Ironic directly.

-- 
-- James Slagle
--

__
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][api] POST /api-sig/news

[Ed Leafe]

Greetings OpenStack community,

No meeting this week, as people are still straggling back after the Sydney 
summit. There will also be no meeting next week, due to the US Thanksgiving 
holiday. So I guess we'll see you all again in December!

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [nova] [infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Jeremy Stanley]

On 2017-11-16 15:17:58 +0900 (+0900), Takashi Natsume wrote:
> In nova-specs project, there is an 'openstack-tox-py27' job (in
> Zuul check or Zuul gate). The job checks whether spec files comply
> with the template or not, line length, etc. But there are cases
> that the job is not executed even if a spec file is added or
> modified.
[...]

Most projects want to have their unit test jobs skipped on changes
which only alter documentation. The nova-specs repo is unusual in
that it's attempting to leverage a unit testing job to validate
documentation formatting rather than the sorts of docs linters other
projects rely on.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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] [release] Release countdown for week R-14, November 18-24

[Sean McGinnis]

G'day mate, it's our regular release countdown email.

Development Focus
-

We are now just a few weeks away from the second milestone. Work on new feature
should be well underway.

There was good turn out last week at the Summit. For those that were able to
attend, please share any insights from those discussions with your teams.

General Information
---

Membership freeze coincides with milestone 2 [0]. This means projects that have
not done a release yet must do so for the next two milestones to be included in
the Queens release.

[0] https://releases.openstack.org/queens/schedule.html#q-mf

We still have a few projects following cycle-with-milestones that have not done
a Queens-1 release:

congress-dashboard
freezer[-web-ui]
searchlight[-ui]
senlin

We also have cycle-with-intermediary projects without a release yet. Please
take a look and see if these are ready to do a release for this cycle yet. It's
best to "release early, release often".

  aodh
  ceilometer
  ceilometermiddleware
  django_openstack_auth
  glance-store
  heat-translator
  ironic-ui
  karbor-dashboard
  karbor
  keystonemiddleware
  kuryr-kubernetes
  ldappool
  mistral-lib
  monasca-ceilometer
  monasca-kibana-plugin
  monasca-thresh
  mox3
  murano-agent
  networking-hyperv
  os-client-config
  os-traits
  os-vif
  osc-lib
  panko
  patrole
  pycadf
  python-aodhclient
  python-barbicanclient
  python-brick-cinderclient-ext
  python-ceilometerclient
  python-cloudkittyclient
  python-congressclient
  python-designateclient
  python-freezerclient
  python-glanceclient
  python-ironic-inspector-client
  python-karborclient
  python-keystoneclient
  python-magnumclient
  python-mistralclient
  python-muranoclient
  python-neutronclient
  python-novaclient
  python-octaviaclient
  python-openstackclient
  python-pankoclient
  python-saharaclient
  python-searchlightclient
  python-senlinclient
  python-solumclient
  python-swiftclient
  python-tackerclient
  python-tricircleclient
  python-vitrageclient
  python-zaqarclient
  requestsexceptions
  requirements
  solum-dashboard
  solum
  tacker-horizon
  tosca-parser
  vitrage-dashboard
  vitrage
  zun-ui
  zun

There were some issues with release jobs during the zuulv3 transition, but just
to be clear, that should not impact making requests for releases. It slowed
down how quickly we were able to process those requests, but the patches can be
submitted at any time. We still have a few gotchas with things like horizon
plugins and some npm issues, but for the most part, all release job issues have
been fixed.

There are quite a few projects that have not responded to the policy-in-code
[1] and split-tempest [2] Queens series goals. Just a reminder that teams
should respond to these goals, even if they do not trigger any work for your
specific project.

[1] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[2] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html

Upcoming Deadlines & Dates
--

Queens-2 Milestone: December 7
Rocky PTG in Dublin: Week of February 26, 2018

-- 
Sean McGinnis (smcginnis)

__
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] [TripleO] Workflow Squad Meetings

[Dougal Matthews]

Hey all,

Starting next week we are going to have regular weekly meetings for the
workflows squad. This will be at 3pm UTC every Wednesday.

https://etherpad.openstack.org/p/tripleo-workflows-squad-status

We will be using the above etherpad to store the meeting details, location
etc and lake notes for the squad status.

Cheers,
Dougal
__
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] Nominate akrivoka for tripleo-validations core

[Alex Schultz]

+1

On Mon, Nov 6, 2017 at 7:32 AM, Honza Pokorny  wrote:
> Hello people,
>
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.
>
> Thanks
>
> Honza Pokorny
>
> __
> 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] Nominate chem and matbu for tripleo-core !

[Emilien Macchi]

On Thu, Nov 16, 2017 at 2:31 AM, Marios Andreou  wrote:
[...]
> I'll ping alex when he's online later to check that chem and matbu are added
> to the right launchpad and gerrit groups.

Note: we accept anyone willing to do self triage in Launchpad group,
not only cores.
If you can't self triage a bug in Launchpad, please let us know and
we'll fix it, even if you're not core.
The URL to do it is: https://launchpad.net/~tripleo-drivers/+addmember

For Gerrit, I took care of it.
-- 
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] [tripleo] Updates on the TripleO on Kubernetes work

[Flavio Percoco]

Hi Team,

I wanted to take a chance to send some updates about the work that we have been
doing on the Kubernetes side of things and how things are progressing. As you
read this update, please bear in mind that we are still at the early stages of
this work and there are many things under discussion, as WIP, discussed but not
implemented, etc. I'm sure many of you have many questions and I hope we will be
able to answer them all as the work progresses. For now, let's take the update
bellow and see where we are headed from here:

Kubernetes on the overcloud
===

The work on this front started with 2[0][1] patches that some of you might have
seen and then evolved into using the config download mechanism to execute these
tasks as part of the undercloud tasks[2][3] (Thanks a bunch, Jiri, for your work
here). Note that [0] needs to be refactored to use the same mechanism used in
[2].

There are quite a few things to improve here:

- How to configure/manage the loadbalancer/vips on the overcloud Kubespray is
- currently being cloned and we need to build a package for it More CI is likely
- needed for this work

[0] https://review.openstack.org/494470
[1] https://review.openstack.org/471759
[2] https://review.openstack.org/#/c/511272/
[3] https://review.openstack.org/#/c/514730/

Ansible roles for k8s
=

We discussed and did research[0] on the topic of whether we should use ansible
or some other tool to deploy OpenStack services on Kubernetes. The conclusion
from that topic was that TripleO would be better fit by a solution based on pure
ansible modules and that's the work we have been pushing forward.

As some of you might have noticed, we started importing some of the roles that
were created for the PoC[0] into openstack. So far we have imported 3 roles
(mariadb, keystone, tripleo) and there are more to come[1] but before importing
the remaining roles, we would like to nail down the CI jobs for the ones that
have been imported.

You'll notice that these roles don't mention tripleo in their name (except for
the tripleo one) because they are intended to be consumed not only by TripleO.
Hopefully, they'll grow into more robust roles that will be consumed by other
tools.

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119696.html
[1] https://github.com/tripleo-apb

CI for the ansible-role-k8s-* repos
===

If you look closely to these repos, you'll notice that these roles can be run
standalone, in full Ansible fashion. To follow the same strategy, the first jobs
that have been added test the ability to deploy these roles with the minimum set
of requirements. For example, the ansible-role-k8s-mariadb role is deployed
without extra dependencies, whereas the ansible-role-k8s-keystone role requires
the ansible-role-k8s-mariadb.

This is very very very basic testing. I'm working on running tempest jobs for
openstack services as I write this email and I'll be working on full-blown
integration jobs as soon as we nail some of these basic jobs down.

If we compare what's been done so far to what we have in the rest of tripleo, it
doesn't sound too exciting. It's great progress, nonetheless.

In addition to the things missing in our CI effort, we would also like to build
a CI job that is consumable by other projects in the community (or, eventually,
consume some of the jobs created by other projects in the community).[0]

[0] https://etherpad.openstack.org/p/tripleo-ptg-queens-kolla-collaboration

Integration with TripleO Heat Templates
===

This work is on-going and you should eventually see some patches popping-up on
the reviews list. One of the goals, besides consuming these ansible roles from
t-h-t, is to be able to create a PoC for upgrades and have an end-to-end
test/demo of this work.

As we progress, we are trying to nail down an end-to-end deployment before
creating roles for all the services that are currently supported by TripleO. We
will be adding projects as needed with a focus on the end-to-end goal.

As a final note, we're collecting patches and updates on this etherpad[0] and
we'll provide more concrete updates on the containers squad etherpad as well.
Admitedly, we should be sending updates like this one more often so, I commit to
do so.

[0] https://etherpad.openstack.org/p/tripleo-on-kubernetes

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [tripleo] Tagging Parameters

[Saravanan KR]

Hi,

A new attribute "tags" has been added to the template parameters in
heat [1]. By adding this, we can categorize the parameters based on
features, which can be used for validations. Currently, I am working
on a patch [2] which will add the "role_specific" tag to the
parameters, which are accepted as role-specific. The next step is to
add a validation to role-specific parameters.

Regards,
Saravanan KR

[1] https://review.openstack.org/#/c/506133/
[2] https://review.openstack.org/#/c/517231/

__
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] Nominate chem and matbu for tripleo-core !

[Carlos Camacho Gonzalez]

Yeah!!! Welcome both!

On Thu, Nov 16, 2017 at 11:32 AM, Marios Andreou 
wrote:

> Thanks to everyone who voted and with only positive feedback (successfully
> spread across two threads ** ) it looks like we can now welcome Sofer and
> Mathieu to the tripleo core team.
>
> I'll ping alex when he's online later to check that chem and matbu are
> added to the right launchpad and gerrit groups.
>
> thanks,
>
> marios
>
> **
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> November/124385.html
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> November/124386.html
>
>
> On Thu, Nov 9, 2017 at 10:48 AM, Marios Andreou 
> wrote:
>
>> Hello fellow owls,
>> (appologies for duplicate, forgot to add the tripleo in subject so
>> worried it would be missed)
>>
>> I would like to nominate (and imo these are both long overdue already):
>>
>> Sofer Athlan Guyot (chem)  and
>>
>> Mathieu Bultel (matbu)
>>
>> to tripleo-core. They have both made many many core contributions to the
>> upgrades & updates over the last 3 cycles touching many of the tripleo
>> repos (tripleo-heat-templates, tripleo-common, python-tripleoclient,
>> tripleo-ci, tripleo-docs and others tripleo-quickstart/extras too unless am
>> mistaken).
>>
>> IMO their efforts and contributions are invaluable for the upgrades squad
>> (and beyond - see openstack overcloud config download for example) and we
>> will be very lucky to have them as fully voting cores.
>>
>> Please vote with +1 or -1 for either or both chem and matbu - I'll keep
>> it open for a week as customary,
>>
>> thank you,
>>
>> marios
>>
>
>
> __
> 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] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Andreas Jaeger]

On 2017-11-16 11:45, Akihiro Motoki wrote:
> 2017-11-16 19:33 GMT+09:00 Andreas Jaeger :
>> On 2017-11-16 11:27, Akihiro Motoki wrote:
>>> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
 On 2017-11-15 19:07, Doug Hellmann wrote:
> [...]
> Someone needs to figure that out. Unfortunately, I don't have the
> bandwidth right now. Maybe you, or someone else from one of the affected 
> projects, can work on it?
>
> Two options have been discussed so far:
>
> 1. Create special jobs for neutron and horizon projects that install
>neutron or horizon, like we do for the release jobs.
>
> 2. Redefine the release notes job so that it doesn't use tox
>but installs only the pieces it needs to run a sphinx build. The
>CTI is already defined in a way to support that [1].
>
> My current preference is for option 2. There may be other options
> that we haven't explored, though.
 I gave it a try in https://review.openstack.org/520362. Note that this
 is only the building part, publishing part is separate - let's first
 iterate on this one,
>>> I noticed most projects require to install themselves now to set
>>> 'version' and 'release' variables in releasenotes/source/conf.py.
>>> For example, 
>>> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
>>> I think we cannot build release notes without installing a project itself.
>>
>> That's really sad ;(
>>
>> But why would we need to set version and release for the releasenotes at
>> all? We only have one - unversioned - document.
>>
>> I suggest to just get rid of it,
> 
> Totally agree.
> 
> I think when we migrated to openstckdocstheme version info was shown
> in the rendered text
> so we started to use version info in conf.py. Some projects started it
> and most projects followed it.
> After migrating openstckdocstheme there is no visible version info in
> the rendered relnotes,
> so I think we can drop it.
> 
> Looking at  the openstackdocstheme document [1], PDF generation
> expects 'release' variable
> but AFAIK we only generate HTML version of release notes and I think
> we can drop 'release'
> and 'version' variables from conf.py.
> 
> [1] https://docs.openstack.org/openstackdocstheme/latest/

Testing now with:
https://review.openstack.org/#/c/520373/

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Andreas Jaeger]

On 2017-11-16 11:33, Andreas Jaeger wrote:
> On 2017-11-16 11:27, Akihiro Motoki wrote:
>> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
>>> On 2017-11-15 19:07, Doug Hellmann wrote:
 [...]
 Someone needs to figure that out. Unfortunately, I don't have the
 bandwidth right now. Maybe you, or someone else from one of the affected 
 projects, can work on it?

 Two options have been discussed so far:

 1. Create special jobs for neutron and horizon projects that install
neutron or horizon, like we do for the release jobs.

 2. Redefine the release notes job so that it doesn't use tox
but installs only the pieces it needs to run a sphinx build. The
CTI is already defined in a way to support that [1].

 My current preference is for option 2. There may be other options
 that we haven't explored, though.
>>> I gave it a try in https://review.openstack.org/520362. Note that this
>>> is only the building part, publishing part is separate - let's first
>>> iterate on this one,
>> I noticed most projects require to install themselves now to set
>> 'version' and 'release' variables in releasenotes/source/conf.py.
>> For example, 
>> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
>> I think we cannot build release notes without installing a project itself.
> 
> That's really sad ;(
> 
> But why would we need to set version and release for the releasenotes at
> all? We only have one - unversioned - document.
> 
> I suggest to just get rid of it,
> Andreas

Indeed, it failed, see:

http://logs.openstack.org/73/520373/1/check/build-openstack-releasenotes/f3cbb61/

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Akihiro Motoki]

2017-11-16 19:33 GMT+09:00 Andreas Jaeger :
> On 2017-11-16 11:27, Akihiro Motoki wrote:
>> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
>>> On 2017-11-15 19:07, Doug Hellmann wrote:
 [...]
 Someone needs to figure that out. Unfortunately, I don't have the
 bandwidth right now. Maybe you, or someone else from one of the affected 
 projects, can work on it?

 Two options have been discussed so far:

 1. Create special jobs for neutron and horizon projects that install
neutron or horizon, like we do for the release jobs.

 2. Redefine the release notes job so that it doesn't use tox
but installs only the pieces it needs to run a sphinx build. The
CTI is already defined in a way to support that [1].

 My current preference is for option 2. There may be other options
 that we haven't explored, though.
>>> I gave it a try in https://review.openstack.org/520362. Note that this
>>> is only the building part, publishing part is separate - let's first
>>> iterate on this one,
>> I noticed most projects require to install themselves now to set
>> 'version' and 'release' variables in releasenotes/source/conf.py.
>> For example, 
>> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
>> I think we cannot build release notes without installing a project itself.
>
> That's really sad ;(
>
> But why would we need to set version and release for the releasenotes at
> all? We only have one - unversioned - document.
>
> I suggest to just get rid of it,

Totally agree.

I think when we migrated to openstckdocstheme version info was shown
in the rendered text
so we started to use version info in conf.py. Some projects started it
and most projects followed it.
After migrating openstckdocstheme there is no visible version info in
the rendered relnotes,
so I think we can drop it.

Looking at  the openstackdocstheme document [1], PDF generation
expects 'release' variable
but AFAIK we only generate HTML version of release notes and I think
we can drop 'release'
and 'version' variables from conf.py.

[1] https://docs.openstack.org/openstackdocstheme/latest/

__
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-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Andreas Jaeger]

On 2017-11-16 11:27, Akihiro Motoki wrote:
> 2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
>> On 2017-11-15 19:07, Doug Hellmann wrote:
>>> [...]
>>> Someone needs to figure that out. Unfortunately, I don't have the
>>> bandwidth right now. Maybe you, or someone else from one of the affected 
>>> projects, can work on it?
>>>
>>> Two options have been discussed so far:
>>>
>>> 1. Create special jobs for neutron and horizon projects that install
>>>neutron or horizon, like we do for the release jobs.
>>>
>>> 2. Redefine the release notes job so that it doesn't use tox
>>>but installs only the pieces it needs to run a sphinx build. The
>>>CTI is already defined in a way to support that [1].
>>>
>>> My current preference is for option 2. There may be other options
>>> that we haven't explored, though.
>> I gave it a try in https://review.openstack.org/520362. Note that this
>> is only the building part, publishing part is separate - let's first
>> iterate on this one,
> I noticed most projects require to install themselves now to set
> 'version' and 'release' variables in releasenotes/source/conf.py.
> For example, 
> http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
> I think we cannot build release notes without installing a project itself.

That's really sad ;(

But why would we need to set version and release for the releasenotes at
all? We only have one - unversioned - document.

I suggest to just get rid of it,
Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Nominate chem and matbu for tripleo-core !

[Marios Andreou]

Thanks to everyone who voted and with only positive feedback (successfully
spread across two threads ** ) it looks like we can now welcome Sofer and
Mathieu to the tripleo core team.

I'll ping alex when he's online later to check that chem and matbu are
added to the right launchpad and gerrit groups.

thanks,

marios

**
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124385.html
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124386.html


On Thu, Nov 9, 2017 at 10:48 AM, Marios Andreou  wrote:

> Hello fellow owls,
> (appologies for duplicate, forgot to add the tripleo in subject so worried
> it would be missed)
>
> I would like to nominate (and imo these are both long overdue already):
>
> Sofer Athlan Guyot (chem)  and
>
> Mathieu Bultel (matbu)
>
> to tripleo-core. They have both made many many core contributions to the
> upgrades & updates over the last 3 cycles touching many of the tripleo
> repos (tripleo-heat-templates, tripleo-common, python-tripleoclient,
> tripleo-ci, tripleo-docs and others tripleo-quickstart/extras too unless am
> mistaken).
>
> IMO their efforts and contributions are invaluable for the upgrades squad
> (and beyond - see openstack overcloud config download for example) and we
> will be very lucky to have them as fully voting cores.
>
> Please vote with +1 or -1 for either or both chem and matbu - I'll keep it
> open for a week as customary,
>
> thank you,
>
> marios
>
__
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] Nominate chem and matbu for tripleo-core !

[Marios Andreou]

Thanks to everyone who voted and with only positive feedback (successfully
spread across two threads ** ) it looks like we can now welcome Sofer and
Mathieu to the tripleo core team.

I'll ping alex when he's online later to check that chem and matbu are
added to the right launchpad and gerrit groups.

thanks,

marios

**
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124385.html
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124386.html




On Thu, Nov 9, 2017 at 10:44 AM, Marios Andreou  wrote:

> Hello fellow owls,
>
> I would like to nominate (and imo these are both long overdue already):
>
> Sofer Athlan Guyot (chem)  and
>
> Mathieu Bultel (matbu)
>
> to tripleo-core. They have both made many many core contributions to the
> upgrades & updates over the last 3 cycles touching many of the tripleo
> repos (tripleo-heat-templates, tripleo-common, python-tripleoclient,
> tripleo-ci, tripleo-docs and others tripleo-quickstart/extras too unless am
> mistaken).
>
> IMO their efforts and contributions are invaluable for the upgrades squad
> (and beyond - see openstack overcloud config download for example) and we
> will be very lucky to have them as fully voting cores.
>
> Please vote with +1 or -1 for either or both chem and matbu - I'll keep it
> open for a week as customary,
>
> thank you,
>
> marios
>
__
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-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Akihiro Motoki]

2017-11-16 18:59 GMT+09:00 Andreas Jaeger :
> On 2017-11-15 19:07, Doug Hellmann wrote:
>> Excerpts from Akihiro Motoki's message of 2017-11-16 01:32:00 +0900:
>>> 2017-11-15 1:06 GMT+09:00 Andreas Jaeger :
 On 2017-11-14 17:03, Doug Hellmann wrote:
> Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
>> On 2017-11-13 22:09, Doug Hellmann wrote:
>>> Excerpts from zuul's message of 2017-11-13 20:37:18 +:
 Unable to freeze job graph: Unable to modify final job >>> publish-openstack-releasenotes branches: None source: 
 openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute 
 required_projects={'openstack/horizon': >>> at 0x7ff848d06b70>} with variant >>> branches: None source: 
 openstack-infra/openstack-zuul-jobs/zuul.d/project-templates.yaml@master#285>

>>>
>>> It looks like there is a configuration issue with
>>> neutron-fwaas-dashboard.
>>
>> Yes, we marked  publish-openstack-releasenotes as final - and then the
>> job added requirements to it.
>>
>> I see at least these two different fixes:
>> - remove the final: true from the job
>> - add neutron and horizon to the job like we done for release job. But
>> there are other projects that have even more requirements.
>>
>> Infra team, what's the best approach here?
>>
>> Andreas
>
> No projects should even need to install *themselves* much less their
> other dependencies to build release notes. It should be possible to
> build release notes just with sphinx and reno (and their dependencies).

 It should - but that's not how those projects seem to be set up ;(
>>>
>>> The current setup is what most horizon plugins do. It is not special.
>>>
>>> The release notes of neutron-fwaas-dashboard can be built with sphinx,
>>> openstackdocstheme, reno and neutron-fwaas-dashboard itself.
>>> I am fine to change this appropriately, but what is the right thing to do?
>>> Do we need to change 'releasenotes' env to depend on only sphinx,
>>> openstackdocstheme and reno?
>>>
>>> Akihiro
>>
>> Someone needs to figure that out. Unfortunately, I don't have the
>> bandwidth right now. Maybe you, or someone else from one of the affected 
>> projects, can work on it?
>>
>> Two options have been discussed so far:
>>
>> 1. Create special jobs for neutron and horizon projects that install
>>neutron or horizon, like we do for the release jobs.
>>
>> 2. Redefine the release notes job so that it doesn't use tox
>>but installs only the pieces it needs to run a sphinx build. The
>>CTI is already defined in a way to support that [1].
>>
>> My current preference is for option 2. There may be other options
>> that we haven't explored, though.
>
> I gave it a try in https://review.openstack.org/520362. Note that this
> is only the building part, publishing part is separate - let's first
> iterate on this one,

I noticed most projects require to install themselves now to set
'version' and 'release' variables in releasenotes/source/conf.py.
For example, 
http://git.openstack.org/cgit/openstack/nova/tree/releasenotes/source/conf.py#n51
I think we cannot build release notes without installing a project itself.

>
> Andreas
>
>> Doug
>>
>> [1] 
>> https://governance.openstack.org/tc/reference/project-testing-interface.html#release-notes
>>
>> __
>> 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
>>
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

[Andreas Jaeger]

On 2017-11-15 19:07, Doug Hellmann wrote:
> Excerpts from Akihiro Motoki's message of 2017-11-16 01:32:00 +0900:
>> 2017-11-15 1:06 GMT+09:00 Andreas Jaeger :
>>> On 2017-11-14 17:03, Doug Hellmann wrote:
 Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100:
> On 2017-11-13 22:09, Doug Hellmann wrote:
>> Excerpts from zuul's message of 2017-11-13 20:37:18 +:
>>> Unable to freeze job graph: Unable to modify final job >> publish-openstack-releasenotes branches: None source: 
>>> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute 
>>> required_projects={'openstack/horizon': >> at 0x7ff848d06b70>} with variant >> branches: None source: 
>>> openstack-infra/openstack-zuul-jobs/zuul.d/project-templates.yaml@master#285>
>>>
>>
>> It looks like there is a configuration issue with
>> neutron-fwaas-dashboard.
>
> Yes, we marked  publish-openstack-releasenotes as final - and then the
> job added requirements to it.
>
> I see at least these two different fixes:
> - remove the final: true from the job
> - add neutron and horizon to the job like we done for release job. But
> there are other projects that have even more requirements.
>
> Infra team, what's the best approach here?
>
> Andreas

 No projects should even need to install *themselves* much less their
 other dependencies to build release notes. It should be possible to
 build release notes just with sphinx and reno (and their dependencies).
>>>
>>> It should - but that's not how those projects seem to be set up ;(
>>
>> The current setup is what most horizon plugins do. It is not special.
>>
>> The release notes of neutron-fwaas-dashboard can be built with sphinx,
>> openstackdocstheme, reno and neutron-fwaas-dashboard itself.
>> I am fine to change this appropriately, but what is the right thing to do?
>> Do we need to change 'releasenotes' env to depend on only sphinx,
>> openstackdocstheme and reno?
>>
>> Akihiro
> 
> Someone needs to figure that out. Unfortunately, I don't have the
> bandwidth right now. Maybe you, or someone else from one of the affected 
> projects, can work on it?
> 
> Two options have been discussed so far:
> 
> 1. Create special jobs for neutron and horizon projects that install
>neutron or horizon, like we do for the release jobs.
> 
> 2. Redefine the release notes job so that it doesn't use tox
>but installs only the pieces it needs to run a sphinx build. The
>CTI is already defined in a way to support that [1].
> 
> My current preference is for option 2. There may be other options
> that we haven't explored, though.

I gave it a try in https://review.openstack.org/520362. Note that this
is only the building part, publishing part is separate - let's first
iterate on this one,

Andreas

> Doug
> 
> [1] 
> https://governance.openstack.org/tc/reference/project-testing-interface.html#release-notes
> 
> __
> 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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [Tripleo] Composable role OVS-DPDK compute node with single NIC

[Samuel Monderer]

Hi,

I managed to deploy a compute node with ovs-dpdk using two NICs. The first
for the provisioning network and control plane, the other NIC is used
tenant network over ovs-dpdk.

I then tried to use only a single nic for provisioning and ovs-dpdk.
I used the nic configuration below for the compute nodes running ovs-dpdk
but encountered two problems.
First the tenant network was working (wasn't able to get DHCP running and
even when I manually configured it wasn't able to reach the router)
Second the default route on control plane is not set even though it is
configured in /etc/sysconfig/network-scripts/route-br-ex

Samuel

OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
-
type: ovs_user_bridge
name: {get_input: bridge_name}
use_dhcp: false
dns_servers: {get_param: DnsServers}
addresses:
-
ip_netmask:
list_join:
- '/'
- - {get_param: ControlPlaneIp}
- {get_param: ControlPlaneSubnetCidr}
routes:
-
ip_netmask: 169.254.169.254/32
next_hop: {get_param: EC2MetadataIp}
-
default: true
next_hop: {get_param: ControlPlaneDefaultRoute}
members:
-
type: ovs_dpdk_port
name: dpdk0
members:
-
type: interface
name: nic1
-
type: vlan
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
-
type: vlan
vlan_id: {get_param: TenantNetworkVlanID}
addresses:
-
ip_netmask: {get_param: TenantIpSubnet}
__
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