[openstack-dev] [oslo] Cancel next two meetings ( Dec 6 and Jan 1)

[ChangBo Guo]

Next two mondays are holidays , there is no urgent topic to discuss, so
let's skip the meeting.

Merry Christmas and Happy New Year!

-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
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] [neutron] Stepping down from core

[Gary Kotton]

Armando, wishing you the best in the future.
Forza Juve!

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Tuesday, December 19, 2017 at 12:28 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] Stepping down from core

Hi Armando,

It's been a great pleasure working with you. We appreciate your hard work and 
dedication.
Best wishes and good luck at your new commitments.

Thanks,
Hirofumi

2017-12-16 4:01 GMT+09:00 Armando M. 
>:
Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more and 
more sporadic. While I tried hard to stay committed and fulfill my core 
responsibilities I feel like I failed to retain the level of quality and 
consistency that I would have liked ever since I stepped down from being the 
Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core is a 
duty rather than a privilege, and I personally feel like it's way overdue for 
me to recognize on the mailing list that it's the time that I state officially 
my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on 
neutron IRC channels, support the neutron team, being the release liasion for 
Queens, participate at meetings, and be open to providing feedback to anyone 
who thinks my opinion is still valuable, especially when dealing with the 
neutron quirks for which I might be (git) blamed :)

Cheers,
Armando


__
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] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Arkady.Kanevsky]

Thanks for response.
My recommendation is:
1. only allow patches into openstack/ironic-tempest-plugin
2. Give Ironic CI owners time period (3 weeks?) to switch their setup to only 
use openstack/ironic-tempest-plugin and not master and report back to Ironic CI 
team if it works for them. If yes, go ahead and switch if not, report back.
3. At the end of that time, if majority of Ironic CI site complete their  
transition to ironic-tempest-plugin we switch.

Thanks,
Arkady


-Original Message-
From: Matthew Treinish [mailto:mtrein...@kortar.org] 
Sent: Monday, December 18, 2017 2:50 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Ironic] Removal of tempest plugin code from 
openstack/ironic & openstack/ironic-inspector

On Mon, Dec 18, 2017 at 01:37:13PM -0700, Julia Kreger wrote:
> > And actually I almost think the holiday time is the best time since 
> > the fewest number of people are going to care. But maybe I'm wrong. 
> > I do wonder if nobody is around to watch a 3rd Party CI for two 
> > weeks, how likely is it to still be working when they get back?
> >
> > I'm not vehemently opposed to delaying, but somewhat opposed.
> >
> > Thoughts?
> 
> I agree and disagree of course. :)  Arkady raises a good point about 
> availability of people, and the simple fact is they will be broken if 
> nobody is around to fix them. That being said, the true measurement is 
> going to be if third party CI shows the commits to remove the folders 
> as passing. If they pass, ideally we should proceed with removing them 
> sooner rather than later to avoid confusion. If they break after the 
> removal of the folders but still ultimately due to the removal of the 
> folders, we have found a bug that will need to be corrected, and we 
> can always temporarily revert to restore the folders in the mean time 
> until people return.
> 

Well it depends, there might not be a failure mode with removing the in-tree 
plugins. It depends on the test selection the 3rd party ci's run. (or if 
they're doing anything extra downstream which has a hard dependency on the 
in-tree stuff, like importing from it directly) If they're running anything 
from tempest itself it's unlikely they'd fail because of the plugin removal. 
The plugins are loaded dynamically during test discovery, and if you remove a 
plugin then it just doesn't get loaded by tempest anymore. So for the normal 
case this would only cause a failure if the only tests being selected were in 
the plugin (and then it fails because no tests were run).

-Matt Treinish

__
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] Mutli-arch image support

[Tony Breeds]

Hi All,
As you're all aware we're trying to bring support to tripleo that
enables multiple-architectures in the same tripleo managed/deployed
overcloud.  The first real difference comes to how we handle the ,now,
multiple images required.

To validated that my understanding of the x86_64 only situation is
correct we have the following images:
 - ironic-python-agent.kernel
 - ironic-python-agent.initramfs
 - overcloud-full.vmlinuz
 - overcloud-full.initrd
 - overcloud-full.qcow2

And we'll need each of those to support multiple architectures which
backwards compatibility the list for a 2 architecture cloud would be 
 - {,x86_64-}ironic-python-agent.kernel
 - {,x86_64-}ironic-python-agent.initramfs
 - {,x86_64-}overcloud-full.vmlinuz
 - {,x86_64-}overcloud-full.initrd
 - {,x86_64-}overcloud-full.qcow2
 - ppc64le-ironic-python-agent.kernel
 - ppc64le-ironic-python-agent.initramfs
 - ppc64le-overcloud-full.vmlinuz
 - ppc64le-overcloud-full.initrd
 - ppc64le-overcloud-full.qcow2

All images would be tagged with a hw_architecture, defaulting to x86_64
if not supplied.

So the selection model for any given image target would be:
 1. $arch-imagename
 2. if arch isn't supplied or is x86_64 fall back to plain imagename

And then we'd add logic to tripleo to look at the architecture of the
baremetal node and pick the correct image for deploy/imageing.  There
are a couple of work in progress changes to do this at:
 - https://review.openstack.org/#/q/status:open+topic:bug/173822

We can iterate on those, however a single architecture 'ppc64le' doesn't
always provide adequate differentiation.  For example you may need one
kernel image (and userspace) for POWER8 processors and a different one
for POWER9.  Ideally we'd just use arch but that's invariant :(

I'd like to introduce the concept of a platform which is in many ways a
companion or a fine grained selector for images.  This would be supplied
by the operator in instackenv.json, added as image meta-data as the
image is uploaded and if needed added to the baremetal node as
a capability.  Then the selection model would become:
 1. $arch-imagename with appropriate image meta-data
 1. $arch-imagename
 2. if arch isn't supplied or is x86_64 fall back to plain imagename

How does that sound?

Yours Tony.


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

Re: [openstack-dev] [neutron] Stepping down from core

[Sukhdev Kapur]

Hey Armando,

Your leadership will be sorely missed.

Cheers..
-Sukhdev


On Fri, Dec 15, 2017 at 11:01 AM, Armando M.  wrote:

> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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] [TripleO] Tis the season...for a cloud reboot

[Joe Talerico]

Ben - Can you provide some links to the ovs port exhaustion issue for
some background?

Thanks,
Joe

On Mon, Dec 18, 2017 at 10:43 AM, Ben Nemec  wrote:
> Hi,
>
> It's that magical time again.  You know the one, when we reboot rh1 to avoid
> OVS port exhaustion. :-)
>
> If all goes well you won't even notice that this is happening, but there is
> the possibility that a few jobs will fail while the te-broker host is
> rebooted so I wanted to let everyone know.  If you notice anything else
> hosted in rh1 is down (tripleo.org, zuul-status, etc.) let me know.  I have
> been known to forget to restart services after the reboot.
>
> I'll send a followup when I'm done.
>
> -Ben
>
> __
> 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] [neutron] Stepping down from core

[Hirofumi Ichihara]

Hi Armando,

It's been a great pleasure working with you. We appreciate your hard work
and dedication.
Best wishes and good luck at your new commitments.

Thanks,
Hirofumi

2017-12-16 4:01 GMT+09:00 Armando M. :

> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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

[openstack-dev] [all] New documentation PTI jobs are live - some fallout possible

[Monty Taylor]

Hey everybody,

For several weeks we've been working on implementing updates to the 
Sphinx documentation jobs to use the new PTI. [0][1][2][3][4]


tl;dr
* we're no longer using tox for building sphinx docs
* if your doc build jobs break all of a sudden, ping us in #openstack-infra
* there is some optional cleanup you can now do if you want

The command that is run to build docs
-

The command that is run by the Zuul jobs is::

sphinx-build -b html doc/source doc/build/html

If the project has a setup.cfg file with:

[build_sphinx]
warnings-is-error=1

then a -W is added:

sphinx-build -W -b html doc/source doc/build/html

We are no longer using tox for sphinx jobs
--

There are some interesting variations in how people are doing doc 
requirements out there. We've caught many of them, but even just this 
morning found two new ways in which projects had managed to be different.


The long and short of it is that the place we *want* to be is for there 
to be a file, doc/requirements.txt, that contains requirements necessary 
for building sphinx docs. That same interface can be used by Javascript, 
Go, Rust, C++, Ruby, Ansible, Puppet, whatever really - it's not python 
specific.


To facilitate moving to that file, the jobs look for a 
doc/requirements.txt file and use it if they find it. If they don't find 
it, they look for a test-requirements.txt file (since that's what should 
have been driving the old version of the PTI anyway)


If your doc build jobs break all of a sudden
-

Cases in which you might not be handled and will need a patch to your 
project:


* You did not have your doc requirements expressed in test-requirements.txt.

Some projects have used a [doc] extra in their setup.cfg file. Others 
just have requirements listed on the [docs] and [venv] environments in 
their tox.ini file.


The simple fix is simply to push up a patch putting your doc 
requirements into doc/requirements.txt


* Your docs depend on the pbr autodoc feature.

My bad. TOTALLY missed this one when we were prepping. There is a patch 
[5] up that should fix/workaround this issue that we'll land as soon as 
we verifty it fixes the pbr autodoc using projects.


* Your tools/tox_install.sh is doing something weird and we didn't find 
it and fix it before hand.


These are more case-by-case - so definitely come find us.

There is some optional cleanup you can now do if you want
-

Now that the job update is live, it's no longer necessary for doc 
requirements to be listed in the normal test requirements (turns out you 
don't need to install sphinx to run your unittests)


* If you have a doc/requirements.txt already that we added recently, we 
will have put a reference to it in the [venv] tox.ini. You can remove it 
from there - or honestly from any tox venv that isn't [docs]


* If you have a normal test-requirements.txt file that has both types, 
you can move your documentation requirements to doc/requirements.txt and 
remove them from test-requirements.txt


* If you have distro-package requirements that are needed for your docs 
to build, you can (and should) add them to bindep.txt and mark them with 
the 'doc' profile. We also fall back to finding things in the 'test' 
profile - but being more explicit is more better.


* If you have a 'docs' environment for tox:

  ** Reminder: the tox 'docs' environment is a developer convenience. 
It is not used in building anything in the gate. **


If you are a project that follows constraints, update your docs env to 
look something like:


[docs]
deps =

-c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
  -r{toxinidir}/requirements.txt
  -r{toxinidir}/doc/requirements.txt
commands = sphinx-build -b html doc/source doc/build/html

The constraints file and requirements.txt file entries are important to 
ensure that you're getting constraints applied. If you are not a project 
that follows the upper-constraints system, you can omit both the 
constraints reference and the requirements.txt reference:


[docs]
deps = -r{toxinidir}/doc/requirements.txt
commands = sphinx-build -b html doc/source doc/build/html

Thanks!
Monty

[0] https://review.openstack.org/#/c/508694/
[1] 
https://governance.openstack.org/tc/reference/project-testing-interface.html#documentation
[2] 
https://governance.openstack.org/tc/reference/pti/python.html#documentation
[3] 
https://governance.openstack.org/tc/reference/pti/golang.html#documentation
[4] 
https://governance.openstack.org/tc/reference/pti/javascript.html#documentation

[5] https://review.openstack.org/#/c/528796

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Matthew Treinish]

On Mon, Dec 18, 2017 at 01:37:13PM -0700, Julia Kreger wrote:
> > And actually I almost think the holiday time is the best time since the
> > fewest number of people are going to care. But maybe I'm wrong. I do wonder
> > if nobody is around to watch a 3rd Party CI for two weeks, how likely is it
> > to still be working when they get back?
> >
> > I'm not vehemently opposed to delaying, but somewhat opposed.
> >
> > Thoughts?
> 
> I agree and disagree of course. :)  Arkady raises a good point about
> availability of people, and the simple fact is they will be broken if
> nobody is around to fix them. That being said, the true measurement is
> going to be if third party CI shows the commits to remove the folders
> as passing. If they pass, ideally we should proceed with removing them
> sooner rather than later to avoid confusion. If they break after the
> removal of the folders but still ultimately due to the removal of the
> folders, we have found a bug that will need to be corrected, and we
> can always temporarily revert to restore the folders in the mean time
> until people return.
> 

Well it depends, there might not be a failure mode with removing the in-tree
plugins. It depends on the test selection the 3rd party ci's run. (or if they're
doing anything extra downstream which has a hard dependency on the in-tree
stuff, like importing from it directly) If they're running anything from tempest
itself it's unlikely they'd fail because of the plugin removal. The plugins are
loaded dynamically during test discovery, and if you remove a plugin then it
just doesn't get loaded by tempest anymore. So for the normal case this would
only cause a failure if the only tests being selected were in the plugin (and
then it fails because no tests were run).

-Matt Treinish


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

Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Julia Kreger]

> And actually I almost think the holiday time is the best time since the
> fewest number of people are going to care. But maybe I'm wrong. I do wonder
> if nobody is around to watch a 3rd Party CI for two weeks, how likely is it
> to still be working when they get back?
>
> I'm not vehemently opposed to delaying, but somewhat opposed.
>
> Thoughts?

I agree and disagree of course. :)  Arkady raises a good point about
availability of people, and the simple fact is they will be broken if
nobody is around to fix them. That being said, the true measurement is
going to be if third party CI shows the commits to remove the folders
as passing. If they pass, ideally we should proceed with removing them
sooner rather than later to avoid confusion. If they break after the
removal of the folders but still ultimately due to the removal of the
folders, we have found a bug that will need to be corrected, and we
can always temporarily revert to restore the folders in the mean time
until people return.

__
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] cyclomatic complexity check in flake8 & Python 3

[Zane Bitter]

On 12/12/17 08:40, Sean Dague wrote:

On 12/12/2017 08:08 AM, Thierry Carrez wrote:

Zane Bitter wrote:



Here's how the allegedly most complex function in Heat[5] shakes out,
for example:

   mccabe  py27  py36
   0.2.1    14 6
   0.3.1    23    23
   0.6.1    23    23

I don't have a solution to suggest, but I burned most of my day digging
into this so I just wanted to let y'all know how screwed we are.

Thanks for digging into this, Zane. I'd say we have two options, based
on how useful running those tests is:

1/ If they are useful, we should bump the version, at the same time
adjusting max-complexity per repo to match the most complex function
(with some slack factor). Encourage more projects to use cyclomatic
complexity checks and fix the biggest offenders using cycle goals.

2/ If they are not useful, just drop cyclomatic complexity tests overall
rather than relying on wrong results and wasting CPU cycles

So I'd like to hear from the 60+ repos on whether using those tests lead
to any good results :)


I don't know how useful these end up being (#1), though I've seen
patches from time to time with people trying to reduce them.


One problem with the theory is that the max complexity is pretty much 
always going to be dominated by a couple of tent-pole values, with 
everything else free to accumulate complexity under the radar. (I 
apologise for the preceding mixed metaphor.) If you could specify 
per-file exceptions then you could at least use it in the way that's 
intended (whether that's useful or not is still up for debate - 
personally I'm in Thomas's "not" camp), but afaik you can't.



The current max in Nova is 35. Moving to mccabe 0.6.1 generates 2 errors:

Running flake8 on all files
./nova/compute/manager.py:763:5: C901 'ComputeManager._init_instance' is
too complex (37)
./nova/tests/functional/api_samples_test_base.py:144:5: C901
'ApiSampleTestBase._compare_result' is too complex (36)


There are some good fixes in 0.6.1 that are pushing the scores up, like 
now counting complexity that occurs inside of the 'else' part of 
try/except/else, but I suspect that the vast majority of the increase is 
due to one giant, honking regression:


https://github.com/PyCQA/mccabe/issues/27#issuecomment-352535619

so TBH I wouldn't recommend updating to any current release. Only if 
somebody is motivated to actually fix that bug might it be worth 
considering.


cheers,
Zane.


I honestly think this is one of the things that you declare a flag day a
couple weeks out, warn everyone they are going to have to adjust their
max, and move forward. It's a very easy fix when pep8 starts failing people.

-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] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[John Villalovos]

One issue is that development is going to move forward on
openstack/ironic-tempest-plugin. No new code will go into the tempest
plugin code in either openstack/ironic or openstack/ironic-inspector.

And actually I almost think the holiday time is the best time since the
fewest number of people are going to care. But maybe I'm wrong. I do wonder
if nobody is around to watch a 3rd Party CI for two weeks, how likely is it
to still be working when they get back?

I'm not vehemently opposed to delaying, but somewhat opposed.

Thoughts?
John

On Mon, Dec 18, 2017 at 11:19 AM,  wrote:

> John,
>
> Should we give all Ironic CI maintainers to do the migration before
> pulling the code from master?
>
> Especially that close to holiday season when a lot of folks are out.
>
> We want to avoid Ironic CI not being functional for several weeks.
>
> Thanks,
>
> Arkady
>
>
>
> *From:* John Villalovos [mailto:openstack@sodarock.com]
> *Sent:* Monday, December 18, 2017 10:59 AM
> *To:* openstack-dev 
> *Subject:* Re: [openstack-dev] [Ironic] Removal of tempest plugin code
> from openstack/ironic & openstack/ironic-inspector
>
>
>
> To hopefully make things more clear.
>
> All of the ironic related projects that were using the tempest-plugin code
> from either openstack/ironic or openstack/ironic-inspector have been
> migrated to use the tempest-plugin code in openstack/ironic-tempest-plugin.
> This includes master and stable branches. Previously all branches (master
> and stable) were pulling from the master branch of openstack/ironic and/or
> openstack/ironic-inspector to get the tempest-plugin code. Now they all
> pull from the master branch of openstack/ironic-tempest-plugin. Note:
> openstack/ironic-tempest-plugin will NOT have any stable branches, only
> master.
>
> We will be removing all the tempest-plugin code from the master branch of
> openstack/ironic and openstack/ironic-inspector on Tuesday 19-Dec-2017. We
> will NOT be removing the tempest-plugin code from any stable branches. We
> (Ironic) didn't/don't use that code but since downstream consumers may we
> will leave it in place.
>
> Any 3rd Party CI that are testing using the tempest-plugin code pulled
> from master will need to update their CI to now use
> openstack/ironic-tempest-plugin
>
> Again we will be removing all the tempest-plugin code from the master
> branch of openstack/ironic and openstack/ironic-inspector on Tuesday
> 19-Dec-2017. If your CI depends on that code, please update to use the new
> openstack/ironic-tempest-plugin repository.
>
>
>
>
>
> On Mon, Dec 18, 2017 at 8:33 AM, John Villalovos <
> openstack@sodarock.com> wrote:
>
>
>
>
>
> On Fri, Dec 15, 2017 at 7:27 AM, John Villalovos <
> openstack@sodarock.com> wrote:
>
> I wanted to send out a note to any 3rd Party CI or other users of the
> tempest plugin code inside either openstack/ironic or
> openstack/ironic-inspector. That code has been migrated to the
> openstack/ironic-inspector-plugin repository. We have been busily (
> https://review.openstack.org/#/q/topic:ironic-tempest-plugin ) migrating
> all of the projects to use this new repository.
>
> If you have a 3rd Party CI or something else that is depending on the
> tempest plugin code please migrate it to use openstack/ironic-tempest-
> plugin.
>
> We plan to remove the tempest plugin code on Tuesday 19-Dec-2017 from
> openstack/ironic and openstack/ironic-tempest-plugin. And then after that
> doing backports of those changes to the stable branches.
>
>
>
> After discussion on IRC in regards to back-porting to the stable branches.
> We will NOT backport the removal of the tempest plugin code as it could
> break distros and other consumers.
>
>
>
>
>
>
>
> __
> 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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Authentication refactoring
1.1. Finalize migration to keystoneauth adapters: 
https://review.openstack.org/#/c/478825/
2. BIOS interface spec:
2.1. https://review.openstack.org/#/c/496481/
3. Traits
3.1. https://review.openstack.org/#/c/528238/
4. Rescue:
4.1. driver interface https://review.openstack.org/#/c/509335/
4.2. RPC https://review.openstack.org/#/c/509336/
4.3. network interface update: https://review.openstack.org/#/c/509342 
Rebase Required
5. The tempest plugin split
5.1. https://etherpad.openstack.org/p/ironic-tempest-plugin-migration
6. Routed Networks - Review for input only
6.1. Add baremetal neutron agent https://review.openstack.org/#/c/456235/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/525053 - firmware update for iLO5
irmc:
  None

oneview:
Introduce hpOneView and ilorest to OneView -  
https://review.openstack.org/#/c/523943/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
allow concurrent updating of dnsmasq configuration 
https://review.openstack.org/#/c/504438/ Merged
fix dsvm (firewall) config deprecations 
https://review.openstack.org/#/c/523196/ Merged
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 11 Dec 2017 and 18 Dec 2017)
- Ironic: 218 bugs + 261 wishlist items. 2 new, 158 in progress, 0 critical, 32 
high and 30 incomplete
- Inspector: 17 bugs + 29 wishlist items. 0 new, 15 in progress, 0 critical, 4 
high and 5 incomplete
- Nova bugs with Ironic tag: 12. 2 new, 0 critical, 0 high
- via http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4 Merged
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/
- radosgw (https://bugs.launchpad.net/ironic/+bug/1737957)

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1671145
- status as of 15 Dec 2017:
- TODO:
- easier access to versions in ironicclient
- see 
https://etherpad.openstack.org/p/ironic-api-version-negotiation
- discussion of various ways to implement it happened on the 
midcycle
- dtantsur wants to have an API-SIG guideline on consuming 
versions in SDKs
- still 

Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Arkady.Kanevsky]

John,
Should we give all Ironic CI maintainers to do the migration before pulling the 
code from master?
Especially that close to holiday season when a lot of folks are out.
We want to avoid Ironic CI not being functional for several weeks.
Thanks,
Arkady

From: John Villalovos [mailto:openstack@sodarock.com]
Sent: Monday, December 18, 2017 10:59 AM
To: openstack-dev 
Subject: Re: [openstack-dev] [Ironic] Removal of tempest plugin code from 
openstack/ironic & openstack/ironic-inspector

To hopefully make things more clear.
All of the ironic related projects that were using the tempest-plugin code from 
either openstack/ironic or openstack/ironic-inspector have been migrated to use 
the tempest-plugin code in openstack/ironic-tempest-plugin. This includes 
master and stable branches. Previously all branches (master and stable) were 
pulling from the master branch of openstack/ironic and/or 
openstack/ironic-inspector to get the tempest-plugin code. Now they all pull 
from the master branch of openstack/ironic-tempest-plugin. Note: 
openstack/ironic-tempest-plugin will NOT have any stable branches, only master.
We will be removing all the tempest-plugin code from the master branch of 
openstack/ironic and openstack/ironic-inspector on Tuesday 19-Dec-2017. We will 
NOT be removing the tempest-plugin code from any stable branches. We (Ironic) 
didn't/don't use that code but since downstream consumers may we will leave it 
in place.
Any 3rd Party CI that are testing using the tempest-plugin code pulled from 
master will need to update their CI to now use openstack/ironic-tempest-plugin
Again we will be removing all the tempest-plugin code from the master branch of 
openstack/ironic and openstack/ironic-inspector on Tuesday 19-Dec-2017. If your 
CI depends on that code, please update to use the new 
openstack/ironic-tempest-plugin repository.


On Mon, Dec 18, 2017 at 8:33 AM, John Villalovos 
> wrote:


On Fri, Dec 15, 2017 at 7:27 AM, John Villalovos 
> wrote:
I wanted to send out a note to any 3rd Party CI or other users of the tempest 
plugin code inside either openstack/ironic or openstack/ironic-inspector. That 
code has been migrated to the openstack/ironic-inspector-plugin repository. We 
have been busily ( https://review.openstack.org/#/q/topic:ironic-tempest-plugin 
) migrating all of the projects to use this new repository.
If you have a 3rd Party CI or something else that is depending on the tempest 
plugin code please migrate it to use openstack/ironic-tempest-plugin.
We plan to remove the tempest plugin code on Tuesday 19-Dec-2017 from 
openstack/ironic and openstack/ironic-tempest-plugin. And then after that doing 
backports of those changes to the stable branches.

After discussion on IRC in regards to back-porting to the stable branches. We 
will NOT backport the removal of the tempest plugin code as it could break 
distros and other consumers.



__
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] [os-upstream-institute] Meeting Today and January 1st Cancelled

[Kendall Nelson]

Hello :)

Since our agenda is empty and we are quickly approaching Christmas and
getting into vacation mode, today's meeting is canceled.

Since the next meeting is scheduled for January 1st and I expect most
people to still be on vacation we will resume regularly scheduled OUI
meetings starting January 9th.

If you have spare time in the next few weeks and want to help out, please
work on adding/completing items on our storyboard[1].

Happy Holidays and Happy New Year!

-Kendall (diablo_rojo)

[1] https://storyboard.openstack.org/#!/project/913
__
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] Removing old baremetal commands from python-tripleoclient

[Ben Nemec]

On 12/17/2017 05:55 PM, Tony Breeds wrote:

On Fri, Dec 15, 2017 at 01:04:52PM +0100, Dmitry Tantsur wrote:

On 12/15/2017 04:49 AM, Tony Breeds wrote:

Hi All,
  In review I01837a9daf6f119292b5a2ffc361506925423f11 I updated
ValidateInstackEnv to handle the case when then instackenv.json file
needs to represent a node that deosn't require a pm_user for IMPI to
work.

It turns out that I foudn that code path with grep rather than the
result of a deploy step failing.  That's becuase it's only used for a
command that isn't used anymore, and the validation logic has been moved
to a mistral action.

That lead me to look at which of the commands in that file aren't needed
anymore.  If my analysis is correct we have the collowing commands:

openstack baremetal instackenv validate:
  tripleoclient.v1.baremetal:ValidateInstackEnv
  NOT Deprecated


See below, it can be fixed. But I'd really prefer us to roll it into
something like "openstack overcloud node import --validate-only".


I can look at that.  I suspect it'd be a trivial wrapper aroudn the
existing code in tripleo-common
  

openstack baremetal import:
  tripleoclient.v1.baremetal:ImportBaremetal
  DEPRECATED in b272a5c6 2017-01-03
  New command: openstack overcloud node import
openstack baremetal introspection bulk start:
  tripleoclient.v1.baremetal:StartBaremetalIntrospectionBulk
  DEPRECATED in b272a5c6 2017-01-03
  New command: openstack overcloud node introspect
openstack baremetal introspection bulk status:
  tripleoclient.v1.baremetal:StatusBaremetalIntrospectionBulk
  NOT Deprecated
openstack baremetal configure ready state:
  tripleoclient.v1.baremetal:ConfigureReadyState
  NOT Deprecated
openstack baremetal configure boot:
  tripleoclient.v1.baremetal:ConfigureBaremetalBoot
  DEPRECATED in b272a5c6 2017-01-03
  New command: openstack overcloud node configure


YES PLEASE to all of this. The "baremetal" part make users often confuse
these commands with ironicclient commands.


Okay so it's trivial to remove the deprecated commands but is it okay to
just drop the commands that haven't been deprecated?


I would say no to just dropping them.  However, in the context of what 
you're doing there's also no need to make them work with multi-arch. 
That's assuming we deprecate them now, of course, which we should do 
ASAP.  Deprecated commands should not be expected to work with new 
functionality.




I guess I'll propose a change and we can hash it out on the




So my questions are basically:
1) Can we remove the deprecated code?
2) Does leaving the not deprecated commands make sesne?
3) Should we deprecate the remaining commands?
3) Do I need to update ValidateInstackEnv or is it okay for it to be
 busted for my use case?


I'm sorry for not getting to it ever, but the fix should be quite simple.
You need to drop all its code from tripleoclient and make it use this
workflow instead: 
https://github.com/openstack/tripleo-common/blob/master/workbooks/baremetal.yaml#L103.
It is much newer, and is actually used in enrollment as well. If it is also
broken for you - please fix it. But the code in tripleoclient is long rotten
:)


I have a patch to fix the triple-common code also.  And I'm very happy
to focus on that :)

Yours Tony.



__
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] [horizon] Adding Ivan Kolodyazhny to the Horizon Core team

[Ivan Kolodyazhny]

Thanks Ying and the team!

I'm happy to be a part of our Horizon Core Reviewers team. I have a bit
more opportunity to make Horizon better now.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Dec 18, 2017 at 2:39 PM, Chenjun Shen 
wrote:

> Congratulations to Ivan!
>
> On Sun, Dec 17, 2017 at 1:39 PM, Akihiro Motoki  wrote:
>
>> Welcome Ivan to the team!
>>
>> Akihiro
>>
>> 2017-12-16 1:52 GMT+09:00 Ying Zuo (yinzuo) :
>> > Hi everyone,
>> >
>> >
>> >
>> > After some discussion with the Horizon Core team, I am pleased to
>> announce
>> > that we are adding Ivan Kolodyazhny to the team. Ivan has been actively
>> > contributing to Horizon since the beginning of the Pike release. He has
>> > worked on many bug fixes, blueprints, and performed thorough code
>> reviews.
>> > You may have known him by his IRC nickname e0ne since he's one of the
>> most
>> > active members on #openstack-horizon. Please join me in welcoming Ivan
>> to
>> > the Horizon Core team :)
>> >
>> >
>> >
>> >
>> >
>> > Regards,
>> >
>> > Ying
>> >
>> >
>> >
>> >
>> > 
>> __
>> > 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
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
__
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] [neutron] Stepping down from core

[Henry Fourie]

Armando,
Appreciate all the hard work and sage advice. Best wishes.
- Louis

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, December 15, 2017 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] Stepping down from core

Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more and 
more sporadic. While I tried hard to stay committed and fulfill my core 
responsibilities I feel like I failed to retain the level of quality and 
consistency that I would have liked ever since I stepped down from being the 
Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core is a 
duty rather than a privilege, and I personally feel like it's way overdue for 
me to recognize on the mailing list that it's the time that I state officially 
my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on 
neutron IRC channels, support the neutron team, being the release liasion for 
Queens, participate at meetings, and be open to providing feedback to anyone 
who thinks my opinion is still valuable, especially when dealing with the 
neutron quirks for which I might be (git) blamed :)

Cheers,
Armando

__
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] [neutron] Stepping down from core

[Ihar Hrachyshka]

It's a sad day. But I am happy we had you in leadership for so many
productive years. I also hope the community is anti-fragile and adopts
to changes.

I wish you all the best.
Ihar

On Fri, Dec 15, 2017 at 11:01 AM, Armando M.  wrote:
> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being the
> Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core is
> a duty rather than a privilege, and I personally feel like it's way overdue
> for me to recognize on the mailing list that it's the time that I state
> officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing with
> the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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] [neutron] Stepping down from core

[Brian Haley]

Armando,

It is sad to see you step down, just wanted to thank you for your 
leadership and hard work, both upstream and downstream, it's definitely 
made neutron a better project for everyone.  Good luck wherever life 
takes you.


-Brian

On 12/15/2017 02:01 PM, Armando M. wrote:

Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been 
more and more sporadic. While I tried hard to stay committed and fulfill 
my core responsibilities I feel like I failed to retain the level of 
quality and consistency that I would have liked ever since I stepped 
down from being the Neutron PTL back at the end of Ocata.


I stated many times when talking to other core developers that being 
core is a duty rather than a privilege, and I personally feel like it's 
way overdue for me to recognize on the mailing list that it's the time 
that I state officially my intention to step down due to other commitments.


This does not mean that I will disappear tomorrow. I'll continue to be 
on neutron IRC channels, support the neutron team, being the release 
liasion for Queens, participate at meetings, and be open to providing 
feedback to anyone who thinks my opinion is still valuable, especially 
when dealing with the neutron quirks for which I might be (git) blamed :)


Cheers,
Armando



__
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] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[John Villalovos]

To hopefully make things more clear.

All of the ironic related projects that were using the tempest-plugin code
from either openstack/ironic or openstack/ironic-inspector have been
migrated to use the tempest-plugin code in openstack/ironic-tempest-plugin.
This includes master and stable branches. Previously all branches (master
and stable) were pulling from the master branch of openstack/ironic and/or
openstack/ironic-inspector to get the tempest-plugin code. Now they all
pull from the master branch of openstack/ironic-tempest-plugin. Note:
openstack/ironic-tempest-plugin will NOT have any stable branches, only
master.

We will be removing all the tempest-plugin code from the master branch of
openstack/ironic and openstack/ironic-inspector on Tuesday 19-Dec-2017. We
will NOT be removing the tempest-plugin code from any stable branches. We
(Ironic) didn't/don't use that code but since downstream consumers may we
will leave it in place.

Any 3rd Party CI that are testing using the tempest-plugin code pulled from
master will need to update their CI to now use
openstack/ironic-tempest-plugin

Again we will be removing all the tempest-plugin code from the master
branch of openstack/ironic and openstack/ironic-inspector on Tuesday
19-Dec-2017. If your CI depends on that code, please update to use the new
openstack/ironic-tempest-plugin repository.


On Mon, Dec 18, 2017 at 8:33 AM, John Villalovos  wrote:

>
>
> On Fri, Dec 15, 2017 at 7:27 AM, John Villalovos <
> openstack@sodarock.com> wrote:
>
>> I wanted to send out a note to any 3rd Party CI or other users of the
>> tempest plugin code inside either openstack/ironic or
>> openstack/ironic-inspector. That code has been migrated to the
>> openstack/ironic-inspector-plugin repository. We have been busily (
>> https://review.openstack.org/#/q/topic:ironic-tempest-plugin ) migrating
>> all of the projects to use this new repository.
>>
>> If you have a 3rd Party CI or something else that is depending on the
>> tempest plugin code please migrate it to use openstack/ironic-tempest-plugi
>> n.
>>
>> We plan to remove the tempest plugin code on Tuesday 19-Dec-2017 from
>> openstack/ironic and openstack/ironic-tempest-plugin. And then after
>> that doing backports of those changes to the stable branches.
>>
>
> After discussion on IRC in regards to back-porting to the stable branches.
> We will NOT backport the removal of the tempest plugin code as it could
> break distros and other consumers.
>
>
>
__
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] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[John Villalovos]

On Fri, Dec 15, 2017 at 7:27 AM, John Villalovos  wrote:

> I wanted to send out a note to any 3rd Party CI or other users of the
> tempest plugin code inside either openstack/ironic or
> openstack/ironic-inspector. That code has been migrated to the
> openstack/ironic-inspector-plugin repository. We have been busily (
> https://review.openstack.org/#/q/topic:ironic-tempest-plugin ) migrating
> all of the projects to use this new repository.
>
> If you have a 3rd Party CI or something else that is depending on the
> tempest plugin code please migrate it to use openstack/ironic-tempest-
> plugin.
>
> We plan to remove the tempest plugin code on Tuesday 19-Dec-2017 from
> openstack/ironic and openstack/ironic-tempest-plugin. And then after that
> doing backports of those changes to the stable branches.
>

After discussion on IRC in regards to back-porting to the stable branches.
We will NOT backport the removal of the tempest plugin code as it could
break distros and other consumers.
__
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] [First Contact] [OUI] Call for Project Liaisons

[Kendall Nelson]

Thanks Alex!  I added you as our Watcher liaison :)

-Kendall (diablo_rojo)

On Mon, Dec 18, 2017 at 1:11 AM Чадин Александр 
wrote:

> Hi Kendall, mark me as Watcher liaison.
> Alexander Chadin (IRC alexchadin), a.cha...@servionica.ru, UTC +3.
>
> > On 12 Dec 2017, at 00:25, Kendall Nelson  wrote:
> >
> > Hello,
> >
> > As some of you may know there is a newly formed SIG focused on the
> initial interactions of someone new to the community called the First
> Contact SIG. While the team we have looking out for these first
> introductions is growing they can only get us so far. After we get them up
> to speed with the tools and community it is important that they are
> connected with someone who can get them up to speed on a project. While
> these SIG members cover a variety of projects, there are several projects
> that don’t have someone to help these newcomers.
> >
> > If you are interested in being a project liaison please reply to this
> thread with your name, irc nic, email, and timezone (UTC +/- x).
> >
> > Previously, Upstream Institute had started to collect a list of people
> interested in helping get new community members up to speed in the past and
> I think it would be good to unite these efforts. That list covers only 6
> projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you signed
> up before and are interested in this renewed effort please let me know!
> >
> > Even if everyone from the initial effort participates, there are still
> many projects missing from the list. How best to ensure the growth and
> success of your project than to invest in the people interested in
> contributing to your project?
> >
> > Thanks!
> >
> > Kendall Nelson (diablo_rojo)
> >
> __
> > 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
>
__
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] [neutron] Stepping down from core

[Jakub Libosvar]

I'm sad reading this. Thanks for everything you did for the community
and best of luck in your new adventures.

Jakub

On 15/12/2017 20:01, Armando M. wrote:
> Hi neutrinos,
> 
> To some of you this email may not come as a surprise.
> 
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being
> the Neutron PTL back at the end of Ocata.
> 
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
> 
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
> 
> Cheers,
> Armando
> 
> 
> 
> __
> 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] about add transformer into libvirt

[gordon chung]

On 2017-12-18 10:28 AM, Jaze Lee wrote:
> Is there some document about how to use rate? I do not find any about it
> Thanks.
> 

https://gnocchi.xyz/rest.html#archive-policy

its' similar to how other aggregates are defined. it's just not part of 
default aggregation methods.

-- 
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] [neutron] Stepping down from core

[Miguel Lavalle]

Hi Armando,

I can only echo here the sadness I expressed to you last week during our
one on one conversation. This decision shows, like in many occasions in the
past, that above all, you are a man a deep principles. As I said, I admire
you for that. You have made invaluable contributions to OpenStack in
general and Neutron in particular. We thank you for that. On a personal
note, I will always be grateful for all the mentoring  and patience that
you have provided me for a long time.

What encourages me is your commitment to continue being a member of the
Neutron team. We need your knowledge, wisdom and guidance and we will
actively seek it. I am looking forward to it!

Un Abbraccio

Miguel


On Mon, Dec 18, 2017 at 7:32 AM, Sławomir Kapłoński 
wrote:

> Hi Armando,
>
> It's very sad to hear that.
> Thanks for all Your work for Neutron community as well as for all Your
> help for other contributors.
> Good luck!
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
> > Wiadomość napisana przez Armando M.  w dniu
> 15.12.2017, o godz. 20:01:
> >
> > Hi neutrinos,
> >
> > To some of you this email may not come as a surprise.
> >
> > During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
> >
> > I stated many times when talking to other core developers that being
> core is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
> >
> > This does not mean that I will disappear tomorrow. I'll continue to be
> on neutron IRC channels, support the neutron team, being the release
> liasion for Queens, participate at meetings, and be open to providing
> feedback to anyone who thinks my opinion is still valuable, especially when
> dealing with the neutron quirks for which I might be (git) blamed :)
> >
> > Cheers,
> > Armando
> >
> > 
> __
> > 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
>
__
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] Tis the season...for a cloud reboot

[Ben Nemec]

Hi,

It's that magical time again.  You know the one, when we reboot rh1 to 
avoid OVS port exhaustion. :-)


If all goes well you won't even notice that this is happening, but there 
is the possibility that a few jobs will fail while the te-broker host is 
rebooted so I wanted to let everyone know.  If you notice anything else 
hosted in rh1 is down (tripleo.org, zuul-status, etc.) let me know.  I 
have been known to forget to restart services after the reboot.


I'll send a followup when I'm done.

-Ben

__
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] about add transformer into libvirt

[Jaze Lee]

2017-12-18 21:17 GMT+08:00 gordon chung :
>
>
> On 2017-12-17 11:08 PM, Jaze Lee wrote:
>> Hello.
>>
>> 2017-12-16 9:30 GMT+08:00 Jaze Lee :
>>> 2017-12-15 23:17 GMT+08:00 gordon chung :


 On 2017-12-14 10:38 PM, Jaze Lee wrote:
> It sounds like great. When the gnocchi can be ready to do transformer's 
> work?
> If it takes long time, we have to move to compute temporarily.

 it already exists in gnocchi 4.1+. we just need to change the workflow
 in ceilometer so it integrates with gnocchi.
>>> Oh, I do not quite understand, can you give more details?
>>> I do not know change which part of workflow in ceilometer.
>>>
>
> i don't openstack on weekends.
Sorry...

>
> what needs to change is that rate aggregate needs to be enabled for
> specific meters such as cpu. this will effectively calculate the cputime
> per second. then you apply the same maths on timeseries that transformer
> does when you query gnocchi.

Is there some document about how to use rate? I do not find any about it
Thanks.

>
> --
> 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] [ironic] reminder about deadlines

[Ruby Loo]

On Fri, Dec 15, 2017 at 9:15 AM, Dmitry Tantsur  wrote:

> Hi all!
>
> Half of the Queens cycle is behind us. I'd like to remind about a few
> deadlines and how they affect us:
>
> 1. Jan 18th is the non-client library release deadline. It affects
> ironic-lib and sushy. The latter has a few outstanding changes - please try
> to find some time to get them a bit of attention. We have one months left,
> minus holidays.
>
> 2. Jan 25th is the client release deadline. If you work on new API, it has
> to land before that point with its client change to end up in ironicclient
> Queens.
>
> 3. Jan 25th is also the feature freeze. We haven't had a formal feature
> freeze for a few cycles. But after troubles with releasing Pike we decided
> to get back to it.
>

Note that this date is not only ironic's feature freeze. If your feature
needs ironic changes to land before changes can be done in another project
(eg nova or neutron), there is less time for you to get the ironic portion
landed.


>
> Feature freeze exceptions *may* be given to priority work, low-impact
> vendor changes and low-impact work substantially improving operator's
> and/or user's experience. Feature freeze exceptions are unlikely to be
> granted to major API additions or breaking changes.
>
> If you think your work may be affected by the feature freeze, please start
> planning accordingly.
>
> Thank you and happy winter holidays,
> Dmitry
>
> __
> 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

[openstack-dev] [all] TL;DR: Switching to longer dev cycles ?

[Thierry Carrez]

A lot of people chose to stay away from the 118-message long thread and
wish there was a summary of it and the discussions on IRC around it.

Mike posted one on the -dev digest:

https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-december-9-15th/

Here is my try at summarizing, in hope it will be helpful.

First, you should read the initial proposal at:

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html


Most of the +1s appear to come from people that would welcome less of a
"taxing treadmill" (in jgriffith's words). A significant share of them
are in the packaging space, where the quantity of work is more directly
correlated to the release cadence.


A lot of objections were posted on the ML or on IRC (and for the record,
I agree with most of them):

1/ Treating the symptom rather than underlying cause

While increasing overall cycle length would ease the pain resulting from
a number of issues, it does not directly treat the underlying causes,
and it has other consequences that may not be as beneficial. The most
obvious of those being that we'd get less done overall, due to having
less forced rhythm/deadlines.

2/ Nobody would consume intermediary releases, resulting in longer
feedback loops

The proposal encourages releasing intermediary releases more often, as a
way to keep releasing early and often. However, for most projects, users
would likely wait for the "real" releases (those with proper feature
freezes, stabilization period and stable branches for post-release
bugfixes) rather than use the intermediaries. This would likely result
in a deteriorated longer feedback loop, with devs waiting up to one year
to get real-world usage / bugs on a feature they just added. So 6-month
"real" releases might still be the right sweet spot between what we can
deliver and a reasonable feedback loop length.

3/ The change would not simplify the life of part-time contributors

The main driver for the proposal is to make OpenStack development more
doable by people who can only spend 20% of their work time on OpenStack
upstream development, as our current pace can be overwhelming. However,
most of the difficulty to keep up is linked to change velocity, and
change velocity is not directly driven by cycle length, so it may stay
mostly the same. If a change is too big to land in 6-month work by a
part-time contributor, it can be split. And if a change misses the boat,
it's a one-year wait rather than a 6-month one.

4/ The overhead of cycle events is not that overwhelming

One goal of the proposal is to reduce the amount of time spent in a year
around development cycle events and process (PTL election, PTG
preparation, feature freeze, release process...) in order to get some
extra time back. Some objected that these don't take that much time,
that feature freeze or PTG prep are actually good things to do, or that
boilerplate can be reconsidered without lengthening the cycle. We could,
for example, only run one PTL election per year without increasing the
dev cycle length.

5/ Most issues that the proposal aims to solve can be solved with better
project management

Getting more realistic at planning the work that can get done within a
cycle would go a long way to make people feel better about the available
time they have. Actively engaging with part-time contributors and making
them feel welcome and valuable would probably drive more direct results
than an extrinsic change like increasing the cycle length. This may
point to the need to spend more time together in a productive
environment like the PTG rather than less.

6/ Larger events are easier to justify and get to

For a number of people it is easier to justify traveling to PTGs than to
smaller midcycles team meetups. Removing one PTG might therefore limit
valuable face-to-face time for team members. It would definitely reduce
the amount of time we spend on cross-project collaboration.

7/ Focus on the real solutions

Fast-forward upgrades (and supporting selected branches past their end
of life) are the real solutions for helping users and vendors keep up
with the rate of releases, not making less of them. We should focus on
that, and the proposal might actually make that more difficult (or a
longer endeavor). We could also try to make releases cycles less of a
"taxing treadmill" by removing as much boilerplate as possible within a
cycle and implementing other low-hanging fruit changes.


I hope I captured most of the objections. If you feel like one of the
objections was not mentioned (or not adequately represented), please add
to this thread :)

-- 
Thierry Carrez (ttx)

__
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] [neutron] Stepping down from core

[Sławomir Kapłoński]

Hi Armando,

It's very sad to hear that.
Thanks for all Your work for Neutron community as well as for all Your help for 
other contributors.
Good luck!

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Armando M.  w dniu 15.12.2017, o 
> godz. 20:01:
> 
> Hi neutrinos,
> 
> To some of you this email may not come as a surprise.
> 
> During the past few months my upstream community engagements have been more 
> and more sporadic. While I tried hard to stay committed and fulfill my core 
> responsibilities I feel like I failed to retain the level of quality and 
> consistency that I would have liked ever since I stepped down from being the 
> Neutron PTL back at the end of Ocata.
> 
> I stated many times when talking to other core developers that being core is 
> a duty rather than a privilege, and I personally feel like it's way overdue 
> for me to recognize on the mailing list that it's the time that I state 
> officially my intention to step down due to other commitments.
> 
> This does not mean that I will disappear tomorrow. I'll continue to be on 
> neutron IRC channels, support the neutron team, being the release liasion for 
> Queens, participate at meetings, and be open to providing feedback to anyone 
> who thinks my opinion is still valuable, especially when dealing with the 
> neutron quirks for which I might be (git) blamed :)
> 
> Cheers,
> Armando
> 
> __
> 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] about add transformer into libvirt

[gordon chung]

On 2017-12-17 11:08 PM, Jaze Lee wrote:
> Hello.
> 
> 2017-12-16 9:30 GMT+08:00 Jaze Lee :
>> 2017-12-15 23:17 GMT+08:00 gordon chung :
>>>
>>>
>>> On 2017-12-14 10:38 PM, Jaze Lee wrote:
 It sounds like great. When the gnocchi can be ready to do transformer's 
 work?
 If it takes long time, we have to move to compute temporarily.
>>>
>>> it already exists in gnocchi 4.1+. we just need to change the workflow
>>> in ceilometer so it integrates with gnocchi.
>> Oh, I do not quite understand, can you give more details?
>> I do not know change which part of workflow in ceilometer.
>>

i don't openstack on weekends.

what needs to change is that rate aggregate needs to be enabled for 
specific meters such as cpu. this will effectively calculate the cputime 
per second. then you apply the same maths on timeseries that transformer 
does when you query gnocchi.

-- 
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] [First Contact] [SIG] Presence at the PTG

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

I’m also interested.

Br,
Gerg0

From: Kendall Nelson [mailto:kennelso...@gmail.com]
Sent: Saturday, December 16, 2017 12:27 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

Thinking more around a half a day to a full day, but if you can't make it the 
whole time I will likely type up a summary to send to the dev list at the end 
and take notes all throughout our discussions.
-Kendall (diablo_rojo)

On Thu, Dec 14, 2017 at 5:10 PM Ghanshyam Mann 
> wrote:
+1, nice idea. I will make it.

btw, what will be the meeting duration you are planning like an hour or 2 ?


-gmann


On Fri, Dec 15, 2017 at 5:55 AM, Kendall Nelson 
> wrote:
> Hello,
>
> It came up in a discussion today that it might be good to get together and
> discuss all the activities around on boarding and various other initial
> interactions to get us all on the same page and a little more
> organized/established.
>
> Given that SIGs have space the beginning of the week (Mon/Tuesday), I am
> proposing that we meet for one of these days. If you are interested, please
> let me know so I can get a headcount.
>
> -Kendall (diablo_rojo)
>
> __
> 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
__
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] Cleaning up -1 votes from the Jenkins account

[Jeremy Stanley]

Over the weekend, I used the Gerrit API to remove any remaining
negative Verified votes on open changes from the old "Jenkins"
account used by our former Zuul 2.x deployment. This did result in
some 4k+ review update events and notifications from me since the
current version of Gerrit leaves a generated comment on deletion of
a reviewer. Apologies for the noise.

We had kept these in place for a couple months in an effort to
provide a smooth transition and not have too many changes with no
apparent CI result. The effect in the UI for any changes which were
still on pre-v3-rollout patch sets is that the old Jenkins -1 still
took precedence in the change list view even if there were more
recent +1 votes from Zuul v3. Now that these have been cleaned up,
that behavior should hopefully no longer be present.
-- 
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

Re: [openstack-dev] [horizon] Adding Ivan Kolodyazhny to the Horizon Core team

[Chenjun Shen]

Congratulations to Ivan!

On Sun, Dec 17, 2017 at 1:39 PM, Akihiro Motoki  wrote:

> Welcome Ivan to the team!
>
> Akihiro
>
> 2017-12-16 1:52 GMT+09:00 Ying Zuo (yinzuo) :
> > Hi everyone,
> >
> >
> >
> > After some discussion with the Horizon Core team, I am pleased to
> announce
> > that we are adding Ivan Kolodyazhny to the team. Ivan has been actively
> > contributing to Horizon since the beginning of the Pike release. He has
> > worked on many bug fixes, blueprints, and performed thorough code
> reviews.
> > You may have known him by his IRC nickname e0ne since he's one of the
> most
> > active members on #openstack-horizon. Please join me in welcoming Ivan to
> > the Horizon Core team :)
> >
> >
> >
> >
> >
> > Regards,
> >
> > Ying
> >
> >
> >
> >
> > 
> __
> > 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
>
__
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] [neutron-dev] [neutron] Generalized issues in the unit testing of ML2 mechanism drivers

[Mike Kolesnik]

On Wed, Dec 13, 2017 at 2:30 PM, Michel Peterson  wrote:

> Through my work in networking-odl I've found what I believe is an issue
> present in a majority of ML2 drivers. An issue I think needs awareness so
> each project can decide a course of action.
>
> The issue stems from the adopted practice of importing
> `neutron.tests.unit.plugins.ml2.test_plugin` and creating classes with
> noop operation to "inherit" tests for free [1]. The idea behind is nice,
> you inherit >600 tests that cover several scenarios.
>
> There are several issues of adopting this pattern, two of which are
> paramount:
>
> 1. If the mechanism driver is not loaded correctly [2], the tests then
> don't test the mechanism driver but still succeed and therefore there is no
> indication that there is something wrong with the code. In the case of
> networking-odl it wasn't discovered until last week, which means that for
> >1 year it this was adding PASSed tests uselessly.
>
> 2. It gives a false sense of reassurance. If the code of those tests is
> analyzed it's possible to see that the code itself is mostly centered
> around testing the REST endpoint of neutron than actually testing that the
> mechanism succeeds on the operation it was supposed to test. As a result of
> this, there is marginally added value on having those tests. To be clear,
> the hooks for the respective operations are called on the mechanism driver,
> but the result of the operation is not asserted.
>
> I would love to hear more voices around this, so feel free to comment.
>

​i talked to a few guys from networking-ovn which are now processing this
info so they could chime in, but from what I've understood the issue wasn't
given much thought in networking-ovn (and I suspect other mechanism
drivers).
​

>
> Regarding networking-odl the solution I propose is the following:
>   **First**, discard completely the change mentioned in the footnote #2.
>   **Second**, create a patch that completely removes the tests that follow
> this pattern.
>   **Third**, incorporate the neutron tempest plugin into the CI and rely
> on that for assuring coverage of the different scenarios.
>

​This sounds like a good plan to me.
​

>
> Also to mention that when discovered this issue in networking-odl we took
> a decision not to merge more patches until the PS of footnote #2 was
> addressed. I think we can now decide to overrule that decision and proceed
> as usual.
>

​Agreed.
​

>
>
>
> [1]: http://codesearch.openstack.org/?q=class%20.*\(.*TestMl2
> 
> [2]: something that was happening in networking-odl and addressed by
> https://review.openstack.org/#/c/523934
>
> ___
> neutron-dev mailing list
> neutron-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/neutron-dev
>
>


-- 
Regards,
Mike
__
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] [monasca] Nominate Amir Mofakhar to Monasca core

[Bedyk, Witold]

Hello everyone,

I would like to nominate Amir Mofakhar to the Monasca core reviewers team.

Welcome onboard,
Witek

__
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] [mistral][irc] Switching to office hours from weekly meetings

[Renat Akhmerov]

Hi,

At the previous weekly meeting we decided to learn about experience of other 
teams using office hours instead of having weekly meetings in IRC. The main 
reason is that it’s almost impossible to find a good time slot so that it works 
for everyone and most of our meetings have pretty few attendees. Or, our 
meetings end very quickly because people are just focused on their tasks and 
there’s not so much to discuss.

That said, there won’t be a weekly meeting today. We’ll try to propose time 
slots for office hours this week.

Until then, should you have anything to discuss just come to our IRC channel 
#openstack-mistral or write to this mailing list with tags 
"[openstack-dev][mistral]” in the subject.

Thanks

Renat Akhmerov
@Nokia
__
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]Notification update week 51

[Balazs Gibizer]

Hi,

Here is the last status update / focus settings mail for 2017

Bugs

[High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when
sending notification during attach_interface
Fix proposed and needs a second core to look at: 
https://review.openstack.org/#/c/527920/



Versioned notification transformation
-
Only have two transformation patches ready as the rest are in merge 
conflict or failing tests:
* https://review.openstack.org/#/c/403660 Transform instance.exists 
notification
* https://review.openstack.org/#/c/480955 Add sample test for instance 
audit



Service create and destroy notifications

https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification
Every related patch has been merged and the bluperint has been set to 
implemented state.



Introducing instance.lock and instance.unlock notifications
---
Needs a specless bp to be proposed to the Rocky cycle
https://review.openstack.org/#/c/526251/


Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples
There are two patches on the branch, one of them only need a second
core to look at.


Weekly meeting
--
The vacation period is close so there is no meeting any more in 2017. 
The first meeting in 2018 is expected to be held on 9th of January.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180109T17

Thanks for the attention in 2017, let's continue the work next year.
Cheers,
gibi




__
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] [First Contact] [OUI] Call for Project Liaisons

[Чадин Александр]

Hi Kendall, mark me as Watcher liaison.
Alexander Chadin (IRC alexchadin), a.cha...@servionica.ru, UTC +3.

> On 12 Dec 2017, at 00:25, Kendall Nelson  wrote:
> 
> Hello,
> 
> As some of you may know there is a newly formed SIG focused on the initial 
> interactions of someone new to the community called the First Contact SIG. 
> While the team we have looking out for these first introductions is growing 
> they can only get us so far. After we get them up to speed with the tools and 
> community it is important that they are connected with someone who can get 
> them up to speed on a project. While these SIG members cover a variety of 
> projects, there are several projects that don’t have someone to help these 
> newcomers.
> 
> If you are interested in being a project liaison please reply to this thread 
> with your name, irc nic, email, and timezone (UTC +/- x).
> 
> Previously, Upstream Institute had started to collect a list of people 
> interested in helping get new community members up to speed in the past and I 
> think it would be good to unite these efforts. That list covers only 6 
> projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you signed up 
> before and are interested in this renewed effort please let me know!
> 
> Even if everyone from the initial effort participates, there are still many 
> projects missing from the list. How best to ensure the growth and success of 
> your project than to invest in the people interested in contributing to your 
> project?
> 
> Thanks!
> 
> Kendall Nelson (diablo_rojo)
> __
> 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

[openstack-dev] [FEMDC] Edge sessions during the next PTG

[lebre . adrien]

Dear all, 

As briefly discussed during the last telco around edge challenges [1], we have 
the opportunity to have sessions during the next PTG in Dublin. 
If you are interested by such sessions and you plan to attend to the PTG, 
please put your name  and questions/topic you would like to discuss at the 
bottom of [2]. 

Please remind that the PTG is a place to discuss about technical aspects (and 
have the opportunities to exchanges with core-devs of the different projects). 
The objective is to dive into details. For this aim, we would like to identify 
concrete actions we can do before the PTG in order to have fruitful exchanges. 

Best regards, 
ad_ri3n_
PS: I need to inform the foundation about number of participants and how many 
slots we would like to have. Please complete the pad [2] ASAP, thanks ;-)

[1] https://etherpad.openstack.org/p/2017_edge_computing_working_sessions
[2] https://etherpad.openstack.org/p/edge-openstack-related

__
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