[openstack-dev] [tripleo] Screencast of the undercloud deploying mariadb

[Flavio Percoco]

Hey Team,

I took the time to record a small screencast[0] showing tripleo undercloud
deplying mariadb on kubernetes. It's it's a *PoC*. It's very basic, some things
are hard coded, but it highlights 3 things that I believe are critical for
TripleO:

* Unified configuration management
* Re-use of existing data
* Re-use existing templates and libraries

You can find some more info in the blog post. I'll be working on a detailed
version to explain how some of these parts work. This way we can keep moing the
discussions forward.

Flavio

[0] https://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html#one

--
@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

Re: [openstack-dev] [all] New code contributors no longer forced to join the foundation

[Swapnil Kulkarni]

On Tue, Aug 8, 2017 at 4:58 AM, Jeremy Stanley  wrote:
> Due to improvements in the OpenStack Foundation member directory and
> our technical election tooling, it is no longer necessary to join
> the foundation as an individual member just to be able to submit
> changes through Gerrit for official repositories. You do, however,
> still eventually need to join if you want to be able to participate
> in technical elections (as a candidate or a voter).
>
> The Account Setup section[1] of the Developer's Guide has been
> updated to reflect the new simpler process, and a separate
> (optional) Eligibility to Vote in Elections section[2] has been
> added. This process change significantly simplifies the onboarding
> process for new code contributors by removing a very error-prone
> and, for many, eyebrow-raising hurdle.
>
> A little background: the Bylaws of the OpenStack Foundation Appendix
> 4 Technical Committee Member Policy[3] (section 3b) limits voter
> rolls for technical elections to Foundation Individual Members. It
> was never strictly required by policy to join the foundation if you
> only wanted to contribute code and had no interest in voting, which
> is not an entirely uncommon case for new contributors. Due to
> previous technical limitations in our systems we still forced new
> contributors to join, because that was the easiest way at the time
> to be relatively certain who was qualified to participate in
> technical elections. Now that we have a mechanism for verifying
> membership on demand when validating nominations and generating
> voter rolls, we have made the step of joining the foundation
> optional (though still very much recommended once you reach the
> point as a contributor where you want to participate in community
> governance processes).
>
> [1] https://docs.openstack.org/infra/manual/developers.html#account-setup
> [2] 
> https://docs.openstack.org/infra/manual/developers.html#eligibility-to-vote-in-elections
> [3] https://www.openstack.org/legal/technical-committee-member-policy/
> --
> Jeremy Stanley
>
> __
> 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
>

Great, excellent step to reduce barrier to entry. Kudos!

__
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] New code contributors no longer forced to join the foundation

[Flavio Percoco]

On 07/08/17 23:28 +, Jeremy Stanley wrote:

Due to improvements in the OpenStack Foundation member directory and
our technical election tooling, it is no longer necessary to join
the foundation as an individual member just to be able to submit
changes through Gerrit for official repositories. You do, however,
still eventually need to join if you want to be able to participate
in technical elections (as a candidate or a voter).


This is already a great step towards simplifying the new contributor experience.
Thank you and to everyone involved in this effort.

Great work,
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

Re: [openstack-dev] [horizon]when I access my website, there is '500 internal server error'

[Rob Cresswell]

It looks to me like you're updating dependencies past those that are supported 
in Ocata. When installing / upgrading packages, you should make sure they are 
bound by upper-constraints in the global requirements repo. Does horizon work 
from your AIO *before* you modified it?

Rob

On 8 Aug 2017 2:24 am, "王俊" > 
wrote:
Hi:
the log is here: http://paste.openstack.org/show/617722/ .
I install Ocata in centos by all in one,then I copy Ironic-UI plugin to 
‘enable’,I update some lib which is Ironic-UI based on,when I restart the httpd 
server, the error coming. how can I fix it except reinstall the env?

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2017-08-07 14:33:22 -0500:
> On 8/3/2017 1:39 PM, Boden Russell wrote:
> > I think we have a gap in our OSC CLI for non-stadium plugin/driver
> > projects (neutron plugin projects, nova driver projects) that implement
> > RESTful resource API attribute extensions.
> > 
> > For details, go directly to [1].
> > For a summary read on...
> > 
> > 
> > For OpenStack APIs that support extensions (ex [2]), the classic
> > python-client CLIs worked "out of the box" for extensions
> > adding attributes to existing RESTful resources.
> > 
> > For example, your project has a neutron plugin that adds a 'my_bool'
> > boolean attribute to 'network' resources that can be set via POST/PUT
> > and is returned with GET. This just works with the python-neutronclient
> > CLI without any client-side code changes.
> > 
> > 
> > However, with OSC resource attributes must be added directly/statically
> > to the sdk's resource and then consumed in the client; the support does
> > not come "for free" in the CLI. While this is fine for stadium projects
> > (they can contribute directly to the sdk/client), non-stadium projects
> > have no viable option to plugin/extend the CLI today for this type of
> > API extension mechanism.
> > 
> > With the phasing out of the python clients, a number of our users will
> > be left without a CLI to interface with these extensions.
> > 
> > I'd like to try and close this gap in Queens and welcome discussion in [1].
> > 
> > Thanks
> > 
> > 
> > [1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
> > [2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions
> > 
> > __
> > 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
> > 
> 
> There is nothing like this for Nova so I'm not sure why Nova should be 
> involved here. We dropped all support for extending the API via 
> stevedore extension loading in Pike [1]. The virt drivers don't extend 
> the REST API either.
> 
> [1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike
> 

And there was much rejoicing.

If the thing you're doing doesn't fit in the mainline API, then what
you're doing is making a new API. Extensions just bypass the important
part where that API gets designed and thought through.

__
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] [kolla][kolla-k8s] Installation in ubuntu 14.04

[Jeffrey Zhang]

technically, it should work.

But this is not tested, at least on kolla CI gate.

On Tue, Aug 8, 2017 at 10:13 AM, ESWAR RAO  wrote:

> Hi All,
>
> I am trying to install openstack containers using kolla-k8s.
>
> I am following below link:
> https://docs.openstack.org/kolla-kubernetes/latest/deployment-guide.html#
>
> As per link, its only supported/validated for ubuntu 16.04.
>
> Please let me know if any version 0.6/0.5.0.4 is supported for ubuntu
> 14.04.
> Its not mentioned in release notes.
>
> Also how to determine upfront which openstack version does it support.
>
> Thanks
> Eswar Rao
>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

[Yaguang Tang]

Thanks Along, finally I figure out that this is a bug  and fixed by this
commit

commit e749b60f49a4a3b48cc5da67a797f717dd8cd01d
Author: Julien Danjou 
Date:   Tue Jun 20 16:36:14 2017 +0200

utils: use ASCII bytes as member id

Tooz actually wants ASCII bytes and not random bytes.

Fixes #130

diff --git a/gnocchi/utils.py b/gnocchi/utils.py
index f81d93e..7666711 100644
--- a/gnocchi/utils.py
+++ b/gnocchi/utils.py
@@ -90,7 +90,7 @@ def _enable_coordination(coord):


 def get_coordinator_and_start(url):
-my_id = uuid.uuid4().bytes
+my_id = str(uuid.uuid4()).encode()
 coord = coordination.get_coordinator(url, my_id)
 _enable_coordination(coord)
 return coord, my_id


On Mon, Aug 7, 2017 at 10:10 PM, Along Meng  wrote:

> From the log info,It shows that your 'node' maybe is not the valid str.
> You can show the node name via 'print node' and try to call 
> str(node).encode('utf-8')
> , identify does it can goes well.
>
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
> str(node).encode('utf-8')
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xde in position 4:
> ordinal not in range(128)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>
>
>
> On Sat, Aug 5, 2017 at 7:16 PM, Yaguang Tang  wrote:
>
>> Hi gnocchi devs,
>>
>> I have an issue when using gnocchi 4.0, the storage backend is ceph, and
>> tooz coordination is redis. currently  gnocchi api in apache wsgi mode,
>> only one controller node running gnocchi-metricd & gnocchi-statsd daemon.
>> the error log of gnocchi-metricd is as follow.
>>
>>
>>
>> 2017-08-05 18:14:18.643 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
>> storage backend use 'cradox' python library
>> 2017-08-05 18:14:18.654 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
>> storage backend use 'cradox' python library
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils [-] Unhandled
>> exception
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils Traceback (most
>> recent call last):
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/cotyledon/_utils.py", line 84, in
>> exit_on_exception
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils yield
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/cotyledon/_service.py", line 139, in
>> _run
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.run()
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 120, in run
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>> self._configure()
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 87, in
>> wrapped_f
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>> r.call(f, *args, **kw)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 177, in
>> call
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>> fut.result()
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line
>> 396, in result
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>> self.__get_result()
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 159, in
>> call
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils result =
>> fn(*args, **kwargs)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 193, in
>> _configure
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.GROUP_ID,
>> partitions=200)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tooz/coordination.py", line 284, in
>> join_partitioned_group
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
>> partitioner.Partitioner(self, group_id)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tooz/partitioner.py", line 45, in
>> __init__
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>> partitions=self.partitions)
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tooz/hashring.py", line 47, in __init__
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>> self.add_nodes(set(nodes))
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
>> "/usr/lib/python2.7/site-packages/tooz/hashring.py", line 71, in
>> add_nodes
>> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
>> str(node).encode('utf-8')
>> 

[openstack-dev] [kolla][kolla-k8s] Installation in ubuntu 14.04

[ESWAR RAO]

Hi All,

I am trying to install openstack containers using kolla-k8s.

I am following below link:
https://docs.openstack.org/kolla-kubernetes/latest/deployment-guide.html#

As per link, its only supported/validated for ubuntu 16.04.

Please let me know if any version 0.6/0.5.0.4 is supported for ubuntu 14.04.
Its not mentioned in release notes.

Also how to determine upfront which openstack version does it support.

Thanks
Eswar Rao
__
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] [neutron][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

hi

i'll create stable/pike (and probably a release) for tap-as-a-service
in this week.

__
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] [neutron][networking-l2gw] pike

[Takashi Yamamoto]

hi,

who is planning to make stable/pike for networking-l2gw?

__
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] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

hi,

can anyone with an appropriate permission create a stable/pike
and pike rc1 for neutron-vpnaas?

stable/pike
11.0.0.0rc1
openstack/neutron-vpnaas
8278615c1f35f98447a3f9692a78ab45e90ee8c6

thank you.

__
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] [horizon]when I access my website, there is '500 internal server error'

[王俊]

Hi:
the log is here: http://paste.openstack.org/show/617722/ .
I install Ocata in centos by all in one,then I copy Ironic-UI plugin to 
‘enable’,I update some lib which is Ironic-UI based on,when I restart the httpd 
server, the error coming. how can I fix it except reinstall the env?

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
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] New code contributors no longer forced to join the foundation

[Davanum Srinivas]

Thanks Jeremy! i know it took a lot of background work/effort by the
team to get here.

-- Dims

On Mon, Aug 7, 2017 at 7:28 PM, Jeremy Stanley  wrote:
> Due to improvements in the OpenStack Foundation member directory and
> our technical election tooling, it is no longer necessary to join
> the foundation as an individual member just to be able to submit
> changes through Gerrit for official repositories. You do, however,
> still eventually need to join if you want to be able to participate
> in technical elections (as a candidate or a voter).
>
> The Account Setup section[1] of the Developer's Guide has been
> updated to reflect the new simpler process, and a separate
> (optional) Eligibility to Vote in Elections section[2] has been
> added. This process change significantly simplifies the onboarding
> process for new code contributors by removing a very error-prone
> and, for many, eyebrow-raising hurdle.
>
> A little background: the Bylaws of the OpenStack Foundation Appendix
> 4 Technical Committee Member Policy[3] (section 3b) limits voter
> rolls for technical elections to Foundation Individual Members. It
> was never strictly required by policy to join the foundation if you
> only wanted to contribute code and had no interest in voting, which
> is not an entirely uncommon case for new contributors. Due to
> previous technical limitations in our systems we still forced new
> contributors to join, because that was the easiest way at the time
> to be relatively certain who was qualified to participate in
> technical elections. Now that we have a mechanism for verifying
> membership on demand when validating nominations and generating
> voter rolls, we have made the step of joining the foundation
> optional (though still very much recommended once you reach the
> point as a contributor where you want to participate in community
> governance processes).
>
> [1] https://docs.openstack.org/infra/manual/developers.html#account-setup
> [2] 
> https://docs.openstack.org/infra/manual/developers.html#eligibility-to-vote-in-elections
> [3] https://www.openstack.org/legal/technical-committee-member-policy/
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

[openstack-dev] [all] New code contributors no longer forced to join the foundation

[Jeremy Stanley]

Due to improvements in the OpenStack Foundation member directory and
our technical election tooling, it is no longer necessary to join
the foundation as an individual member just to be able to submit
changes through Gerrit for official repositories. You do, however,
still eventually need to join if you want to be able to participate
in technical elections (as a candidate or a voter).

The Account Setup section[1] of the Developer's Guide has been
updated to reflect the new simpler process, and a separate
(optional) Eligibility to Vote in Elections section[2] has been
added. This process change significantly simplifies the onboarding
process for new code contributors by removing a very error-prone
and, for many, eyebrow-raising hurdle.

A little background: the Bylaws of the OpenStack Foundation Appendix
4 Technical Committee Member Policy[3] (section 3b) limits voter
rolls for technical elections to Foundation Individual Members. It
was never strictly required by policy to join the foundation if you
only wanted to contribute code and had no interest in voting, which
is not an entirely uncommon case for new contributors. Due to
previous technical limitations in our systems we still forced new
contributors to join, because that was the easiest way at the time
to be relatively certain who was qualified to participate in
technical elections. Now that we have a mechanism for verifying
membership on demand when validating nominations and generating
voter rolls, we have made the step of joining the foundation
optional (though still very much recommended once you reach the
point as a contributor where you want to participate in community
governance processes).

[1] https://docs.openstack.org/infra/manual/developers.html#account-setup
[2] 
https://docs.openstack.org/infra/manual/developers.html#eligibility-to-vote-in-elections
[3] https://www.openstack.org/legal/technical-committee-member-policy/
-- 
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] [nova] [docs] Ideal landing page

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-07 17:07:37 -0400:
> The integration of all the manual docs, plus all of our native docs
> trying to get restructured a bit, has left us with a first order mess
> when it comes to our front page (and the Table of Contents in the
> sidebar) - https://docs.openstack.org/nova/latest/
> 
> I started trying to pull things out of the sidebar TOC by creating some
> interior landing pages for Contributors and a Deep Dive Technical
> Reference. In staring at what was left on the page for a good hour today
> I came up with the following ideal front page outline.
> 
> https://etherpad.openstack.org/p/ideal-nova-docs-landing-page
> 
> This probably turns into 3 additional patches on topic:bp/doc-migration
> * For Users
> * For Operators
> * Index page smooth over
> 
> The original docs spec didn't really separate out users / operators as
> target audiences. None of this will involve moving subpages around (so

End-user content goes in /user. Operator content goes in /admin.  See
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change
for details.

> no additional redirects), it will just be a couple of sections and
> landing documents where appropriate.
> 
> Please chime in if you have opinions. Otherwise I'm going to start
> writing the rest of this tomorrow to try to get it all sorted for RC.
> 
> -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] [nova][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2017-08-07 14:04:33 -0700:
> On Wed, Aug 2, 2017, at 01:44 PM, Clark Boylan wrote:
> > On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
> > > On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > > > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > > >> Now that Stephen Finucane is back from enjoying his youth and 
> > > >> gallivanting all over Europe, and we talked about a few things in IRC 
> > > >> this morning on the docs migration for Nova, I wanted to dump my 
> > > >> concerns here for broader consumption.
> > > >>
> > > >> 1. We know we have to fix a bunch of broken links by adding in 
> > > >> redirects 
> > > >> [1] which sdague started here [2]. However, that apparently didn't 
> > > >> catch 
> > > >> everything, e.g. [3], so I'm concerned we're missing other broken 
> > > >> links. 
> > > >> Is there a way to find out?
> > > > 
> > > > The infra team can generate lists of 404 urls fairly easily on the docs
> > > > server. This won't show you everything but will show you what urls
> > > > people are finding/using that 404.
> > > 
> > > If we could get a weekly report of 404 urls posted somewhere public,
> > > that would be extremely useful, because the easy ones based on git
> > > renames are done, and everything else is going to require human
> > > inspection to figure out what the right landing target is.
> > > 
> > 
> > I've pushed https://review.openstack.org/#/c/490175/ which will generate
> > a report each day for roughly the last day's worth of 404s. You should
> > be able to see them at https://docs.openstack.org/404s once the change
> > merges and the cron job fires.
> > 
> > You can see what that will look like (from my test runs) at
> > http://paste.openstack.org/show/617322/. Note that this isn't a complete
> > file because paste.openstack.org truncated it but you'll get the full
> > data from the wbeserver once this change merges.
> 
> http://files.openstack.org/docs-404s/ is now live (note it moved to
> http://files.openstack.org/docs-404s because that is where we are
> hosting raw bits of utility info for this hosting service). The current
> content there was just generated by running the scripts manually, but it
> should update daily at 0700UTC going forward.
> 
> Hope this helps,
> Clark
> 

Thanks Clark, that's going to be really useful.

Doug

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

Re: [openstack-dev] [neutron][FFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports

[Kevin Benton]

I think this is okay. It's been a long standing bug and the patch has is
very close to ready.

On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan 
wrote:

>
> Hi PTL/all,I would like to request an exception for inclusion of
> https://bugs.launchpad.net/neutron/+bug/1583694for Pike.
>
> This fix contained two patches one for server side and the other for the
> agent side.
>
> The server side patch had already merged, but the agent side patch is yet to 
> merge but gone through
> multiple reviews.
> I would request to consider the agent side patch for the Feature Freeze 
> Exception.
>
> The RFE: https://bugs.launchpad.net/neutron/+bug/1583694
> The agent side patch: https://review.openstack.org/#/c/437986/  (FFE required)
>
> The server side patch that already merged: 
> https://review.openstack.org/#/c/466434/  (Patch already merged).
> Best regards,
> Swaminathan Vasudevan
>
>
> __
> 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][FFE]Allow DVR for E/W while leaving N/S centralized Edit

[Kevin Benton]

Based on feedback from Brian, this patch is close to ready so we should be
able to land it. It also proposes a limited risk to existing deployments
not using the new agent mode.

On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan 
wrote:

>
>
>
> Hi PTL/all,
> I would like to request an exception for inclusion of 
> https://bugs.launchpad.net/neutron/+bug/1667877.
> This fix addresses providing option for the customers to configure a new 
> agent-type for centralizing the
> floatingip in the absence of external network connectivity.
>
>
> The RFE: https://bugs.launchpad.net/neutron/+bug/1667877
> Patch under review: https://review.openstack.org/#/c/485333/
>
> Best regards,
> Swaminathan Vasudevan
>
>
> __
> 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] [nova] [docs] Ideal landing page

[Sean Dague]

The integration of all the manual docs, plus all of our native docs
trying to get restructured a bit, has left us with a first order mess
when it comes to our front page (and the Table of Contents in the
sidebar) - https://docs.openstack.org/nova/latest/

I started trying to pull things out of the sidebar TOC by creating some
interior landing pages for Contributors and a Deep Dive Technical
Reference. In staring at what was left on the page for a good hour today
I came up with the following ideal front page outline.

https://etherpad.openstack.org/p/ideal-nova-docs-landing-page

This probably turns into 3 additional patches on topic:bp/doc-migration
* For Users
* For Operators
* Index page smooth over

The original docs spec didn't really separate out users / operators as
target audiences. None of this will involve moving subpages around (so
no additional redirects), it will just be a couple of sections and
landing documents where appropriate.

Please chime in if you have opinions. Otherwise I'm going to start
writing the rest of this tomorrow to try to get it all sorted for RC.

-Sean

-- 
Sean Dague
http://dague.net

__
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][docs] Concerns with docs migration

[Clark Boylan]

On Wed, Aug 2, 2017, at 01:44 PM, Clark Boylan wrote:
> On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
> > On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > >> Now that Stephen Finucane is back from enjoying his youth and 
> > >> gallivanting all over Europe, and we talked about a few things in IRC 
> > >> this morning on the docs migration for Nova, I wanted to dump my 
> > >> concerns here for broader consumption.
> > >>
> > >> 1. We know we have to fix a bunch of broken links by adding in redirects 
> > >> [1] which sdague started here [2]. However, that apparently didn't catch 
> > >> everything, e.g. [3], so I'm concerned we're missing other broken links. 
> > >> Is there a way to find out?
> > > 
> > > The infra team can generate lists of 404 urls fairly easily on the docs
> > > server. This won't show you everything but will show you what urls
> > > people are finding/using that 404.
> > 
> > If we could get a weekly report of 404 urls posted somewhere public,
> > that would be extremely useful, because the easy ones based on git
> > renames are done, and everything else is going to require human
> > inspection to figure out what the right landing target is.
> > 
> 
> I've pushed https://review.openstack.org/#/c/490175/ which will generate
> a report each day for roughly the last day's worth of 404s. You should
> be able to see them at https://docs.openstack.org/404s once the change
> merges and the cron job fires.
> 
> You can see what that will look like (from my test runs) at
> http://paste.openstack.org/show/617322/. Note that this isn't a complete
> file because paste.openstack.org truncated it but you'll get the full
> data from the wbeserver once this change merges.

http://files.openstack.org/docs-404s/ is now live (note it moved to
http://files.openstack.org/docs-404s because that is where we are
hosting raw bits of utility info for this hosting service). The current
content there was just generated by running the scripts manually, but it
should update daily at 0700UTC going forward.

Hope this helps,
Clark

__
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][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

[Matt Riedemann]

On 8/7/2017 2:50 PM, Kendall Nelson wrote:

Hello Everyone :)

A quick reminder that we are in the last days for PTL candidate 
announcements.



If you want to stand for PTL, don't delay, follow the instructions at 
[1] to make sure the community knows your intentions.



Make sure your candidacy has been submitted to the openstack/election 
repository and approved by election officials.



Election statistics[2]:


This means that with approximately 2.5 days left more than 27% of 
projects will be deemed leaderless.  In this case the TC will be bound 
by [3].



Thank you,


-Kendall Nelson (diablo_rojo)


[1]http://governance.openstack.org/election/#how-to-submit-your-candidacy

[2] Assuming the open reviews below are validated

https://review.openstack.org/#/q/is:open+project:openstack/election

[3] 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html









__
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



Despite mikal flaming up the twitter, I'll post something for Nova PTL 
in the next day or so. I had mentioned intentions in the nova meeting a 
couple of weeks ago basically saying I'd be happy to do it again for 
Queens unless someone else was thinking about doing it and wanted to 
talk first - not that anyone has to talk to me about it to nominate 
themselves.


Also, I've been kind of sort of distracted by this whole release 
candidate thing going on right now...


--

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] Is shade (and os_client_config) thread safe?

[Joshua Harlow]

Hi there folks,

I'm doing various scans of our clouds here at godaddy and using shade to 
do some of the calls.


Though when I do stuff like the following sometimes it has issues...

http://paste.openstack.org/show/617712/

Typically this causes the following error:

Traceback (most recent call last):
  File "tools/fetch_flavors.py", line 72, in 
main()
  File "tools/fetch_flavors.py", line 61, in main
results.append(fut.result())
  File 
"/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/_base.py", 
line 422, in result

return self.__get_result()
  File 
"/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/thread.py", 
line 62, in run

result = self.fn(*self.args, **self.kwargs)
  File "tools/fetch_flavors.py", line 24, in extract_cloud
client = shade.openstack_cloud(cloud=cloud_name)
  File 
"/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/__init__.py", 
line 106, in openstack_cloud

return OpenStackCloud(cloud_config=cloud_config, strict=strict)
  File 
"/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/openstackcloud.py", 
line 156, in __init__

self.image_api_use_tasks = cloud_config.config['image_api_use_tasks']
KeyError: 'image_api_use_tasks'

Though if I add a lock around the following then things go better:

with SHADE_LOCK:
client = shade.openstack_cloud(cloud=cloud_name)

So that makes me wonder, is ummm, this library (or one of its 
dependencies not thread-safe?); has anyone else seen similar things, 
perhaps they've already been fixed?


-Josh

__
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] ETSI NFV - OpenStack workshop in Denver

[Ildiko Vancsa]

Hi All,

I would like to draw your attention to a co-located event during the upcoming 
OpenStack PTG in Denver. The event will take place in the OpenStack PTG venue 
(Renaissance Hotel, Denver) at 2pm - 5pm on Tuesday (Sept. 12).

The workshop intends to provide a forum to identify and discuss the common use 
cases and tasks between OpenStack and ETSI NFV and take these items to the next 
level. The co-located workshop will be a working event to discuss the gaps and 
requirements on both sides in details and work on the technical solutions and 
next steps.

You can find more details and planned agenda on the following etherpad: 
https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver

Please add your name to the etherpad if you intend to join. If you have any 
questions or comments feel free to add them to the etherpad or reply to this 
mail thread.

Thanks and Best Regards,
Ildikó



__
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. Docs due to the docs re-org - See 
http://lists.openstack.org/pipermail/openstack-dev/2017-July/119221.html
1.1. Ironic - 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:doc-migration
1.2. ironic-inspector - 
https://review.openstack.org/#/q/status:open+project:openstack/ironic-inspector+branch:master+topic:doc-migration
1.3. bifrost: 
https://review.openstack.org/#/q/status:open+project:openstack/bifrost+branch:master+topic:doc-migration
2. Booting from volume:
2.1. Functional tests: https://review.openstack.org/#/c/473717/
3. Rolling upgrades:
3.1. admin documentation: https://review.openstack.org/#/c/416565/
4. Driver composition:
4.1. upgrade docs (generic part): https://review.openstack.org/486696
5. Physnet awareness:
5.1. Refactoring: 
https://review.openstack.org/#/q/topic:refactor-vif-attach-mixin
6. IPA API versioning:
6.1. ironic part: https://review.openstack.org/#/c/364861/
6.2. IPA part: https://review.openstack.org/#/c/364834/


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 31 Jul 2017 and 07 Aug 2017)
- Ironic: 250 bugs (-7) + 257 wishlist items (-2). 29 new (-1), 197 in progress 
(-10), 0 critical, 32 high (+2) and 30 incomplete (-1)
- Inspector: 13 bugs + 28 wishlist items. 2 new (-1), 11 in progress (+1), 0 
critical, 3 high (+1) and 3 incomplete
- Nova bugs with Ironic tag: 19 (+1). 0 new, 0 critical, 1 high

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/
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- local boot with partition images: TODO 
https://bugs.launchpad.net/ironic/+bug/1531149
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO

Essential Priorities


Generic boot-from-volume (TheJulia, dtantsur)
-
- BFV Meetings on hold until September.
- specs and blueprints:
- 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/volume-connection-information.html
- code: https://review.openstack.org/#/q/topic:bug/1526231
- 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/boot-from-volume-reference-drivers.html
- code: https://review.openstack.org/#/q/topic:bug/1559691
- https://blueprints.launchpad.net/nova/+spec/ironic-boot-from-volume
- code: 
https://review.openstack.org/#/q/topic:bp/ironic-boot-from-volume
- status as of 07 Aug 2017:
- Patch/note tracking etherpad: https://etherpad.openstack.org/p/Ironic-BFV
Ironic Patches:
https://review.openstack.org/#/c/479326/ - BFV deploy follow-up - 
MERGED
https://review.openstack.org/#/c/466568/ - devstack testing guide - 
MERGED
https://review.openstack.org/#/c/473717/ - functional tests
Project-Config:
https://review.openstack.org/#/c/490710/ - moving the experimental 
job to the check queue MERGED
- Not required for Pike:
- Nova:
https://review.openstack.org/#/c/468353 - Ironic: Get IP address 
for volume connector

Rolling upgrades and grenade-partial (rloo, jlvillal)
-
- spec approved; code patches: 
https://review.openstack.org/#/q/topic:bug/1526283
- status as of most recent weekly meeting:
- last big code patch MERGED: 'Add new dbsync command with first online 
data migration': https://review.openstack.org/#/c/408556/
- Testing work: done as per spec, but rloo wants to ask vasyl whether we 
can improve. grenade test will do upgrade so we have old API sending requests 
to old and/or new conductor, but rloo doesn't think there is anything to 
control -which- conductor handles the request, so what if old conductor handles 
all the requests?
- should add 'ironic-dbsync online_data_migrations' call to grenade 
multinode test, but can't because grenade multinode test doesn't upgrade all 
services :-(
- but it should be added to the regular grenade, right?
- to address restarting services after unpinning, spec ready for reviews: 
'SIGHUP restarts services with updated configs': 
https://review.openstack.org/474309
- next patch ready for reviews: Rolling upgrade procedure documentation: 
https://review.openstack.org/#/c/416565/
- TheJulia to update 

[openstack-dev] [all][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announceme

[Kendall Nelson]

Hello Everyone :)

A quick reminder that we are in the last days for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your candidacy has been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:

This means that with approximately 2.5 days left more than 27% of projects
will be deemed leaderless.  In this case the TC will be bound by [3].

Thank you,


-Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy

[2] Assuming the open reviews below are validated

  https://review.openstack.org/#/q/is:open+project:openstack/election


[3]
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
__
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] [python-openstacksdk] Status of python-openstacksdk project

[Monty Taylor]

On 08/07/2017 11:55 AM, Boden Russell wrote:


On 8/4/17 1:26 PM, Boris Pavlovic wrote:


That's not going to work for dozens of OpenStack projects. It's just
won't scale. Every project should maintain plugin for their project. And
it should be enough to say "pip install python-client" that
extend the Core OpenStack python client and adds support of new commands.

The whole core part should be only about how to make plugins interface
in such way that it's easy to extend and provide to end user nice user
experience from both side (shell & python) and nice and stable interface
for client developers .



I echo Boris's point; if the client side isn't pluggable and extendable
(in a reusable fashion), then how can we build a consistent CLI for
users of our APIs that do support pluggable (potentially out-of-tree)
extensions (ex: neutron)?


I think we're missing each other here.

Nothing about the SDK not having plugins will have anything to do with 
OSC plugins. OSC will still totally have plugins.


But OpenStack is a piece of cloud software that has a REST API that 
includes service and version discovery components that work the same 
across all of the sub-projects. There is nothing about any of the 
services that makes it valuable to have a separate library to consume 
it. In fact, if you look at our current python libraries you would think 
that our APIs are much more different than they actually are.



It's a concern with the current trajectory of OSC/SDK and one I
mentioned on the ML last week [1].

If we're going to reevaluate this client side "plumbing", I truly hope
we take into consideration how our users are interfacing with the CLI,
which today, includes the ability to handle API resource extensions in
the classic python client, but not in OSC.


Nothing about this is about OSC. There is no reason to not support all 
of the available API surface directly in the SDK. If the availability of 
the API in question can be discovered via a discovery/extension 
mechanism, then it can be supported. If it CAN'T- then the user isn't 
going to be able to use such a feature sanely anyway and we need to 
address that so that our users have a good experience.


Long story short - OpenStack is the thing this is a client for. It needs 
to support all of OpenStack - and it doesn't need to support things that 
are not OpenStack.



As per the bug/RFE linked in [1], I'm willing to throw some code down to
help make this happen; it's just not clear who the right team is to
queue this discussion/code up with.


If neutronclient could support doing [1] without plugins, then I see no 
reason we can't support doing is without plugins as well. Let's make a 
plan and get it done- I agree with you that supporting your use case is 
important.




[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.html

__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Matt Riedemann]

On 8/3/2017 1:39 PM, Boden Russell wrote:

I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.

For details, go directly to [1].
For a summary read on...


For OpenStack APIs that support extensions (ex [2]), the classic
python-client CLIs worked "out of the box" for extensions
adding attributes to existing RESTful resources.

For example, your project has a neutron plugin that adds a 'my_bool'
boolean attribute to 'network' resources that can be set via POST/PUT
and is returned with GET. This just works with the python-neutronclient
CLI without any client-side code changes.


However, with OSC resource attributes must be added directly/statically
to the sdk's resource and then consumed in the client; the support does
not come "for free" in the CLI. While this is fine for stadium projects
(they can contribute directly to the sdk/client), non-stadium projects
have no viable option to plugin/extend the CLI today for this type of
API extension mechanism.

With the phasing out of the python clients, a number of our users will
be left without a CLI to interface with these extensions.

I'd like to try and close this gap in Queens and welcome discussion in [1].

Thanks


[1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
[2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions

__
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



There is nothing like this for Nova so I'm not sure why Nova should be 
involved here. We dropped all support for extending the API via 
stevedore extension loading in Pike [1]. The virt drivers don't extend 
the REST API either.


[1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike

--

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] [tripleo][qa] Enabling elastic-recheck for tripleo job

[Paul Belanger]

On Mon, Aug 07, 2017 at 10:34:59AM -0700, Emilien Macchi wrote:
> On Mon, Aug 7, 2017 at 9:18 AM, Paul Belanger  wrote:
> > I've just pushed up a change to puppet-elastic_recheck[1] to update the jobs
> > regex for elastic-recheck to start tracking tripleo.  What this means, is 
> > now
> > the elasticRecheck bot will start leaving comments on reviews once it 
> > matches a
> > failure in knows about.
> 
> Really cool, thanks.
> Note we have an etherpad to track old queries in logstash:
> https://etherpad.openstack.org/p/tripleo-ci-logstash-queries
> I know it's not the best way to handle it and we should use more
> elastic-recheck, but we can also re-use some queries if needed and
> remove this etherpad, with this move to elastic-recheck.

Yes, once we have the current elastic-recheck bugs commenting on tripleo
reviews, we should migrated any existing logstash queries into it.

__
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] [kolla][PTL][elections] Candidacy for Kolla PTL

[Richard Wellum]

+1

Rich Wellum

On Wed, Aug 2, 2017 at 2:44 PM Michał Jastrzębski  wrote:

> Hello everyone,
>
> Once more unto the breach dear friends! I would like to run for PTL again
> for
> Queens. Pike was very exciting release for Kolla. With strong focus on
> Kolla-Kubernetes, Kolla-Ansible getting more and more production
> deployments
> and Kolla images being successfully consumed by project outside of Kolla
> like TripleO or OpenStack-Helm, I think this was quite a success for us.
>
> We managed to improve one of biggest pain points we saw in Kolla - gates.
> We
> still have lengths to go, but progress is significant.
>
> I'd love to help our community to make Queens even better. We have several
> exiting features in our plates, like automated push mechanism for images or
> orchestration layer for kolla-kubernetes.
>
> We also need to focus on another big pain point of Kolla - documentation.
>
> I would like us to strengthen cooperation with Kubernetes community and I'm
> strong believer that best bridge between communities is built on top of
> common
> technical issues and mutual help. I think Kolla-Kubernetes naturally helps
> with this cooperation and we can use it even more.
>
> Per request, I also add small haiku to my nomination;)
>
> Glues Stack together
> Project by great people made
> Queens approaching soon
>
> Regards,
> Michal inc0 Jastrzebski
>
> __
> 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] placement/resource providers update 29

[Ed Leafe]

On Jul 24, 2017, at 5:05 AM, Chris Dent  wrote:
> 
> I guess the code that Ed's working on at
> 
>https://review.openstack.org/#/c/484949
> 
> need to zero out VCPU etc in the extra specs so that the eventual
> allocation record is created in 484935 is correct?

That’s what I thought, too, but apparently [0] we need both in Pike. The 
zeroing out can’t happen until Queens.

[0] https://review.openstack.org/#/c/484949/2/nova/virt/ironic/driver.py@471

-- 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] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Emilien Macchi]

On Mon, Aug 7, 2017 at 9:15 AM, Doug Hellmann  wrote:
> Kendall & Thierry, what do we need to do to reserve that room if we
> can't find space in another team room?

Worst case, we can use a slot from TripleO - this topic is also
critical to us and I think we can make our schedule to have one free
room during the 2 and a half days that we have.
Just let me know.
-- 
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] [neutron] RC1 week

[Armando M.]

Hi neutrinos,

Today RC week starts [0] and I have prepared release patch [1]. For the
project you're liasion, please review the patch for accuracy and make sure
we tag RC1/create a stable branch with the git commit hash you are OK with.

Many thanks,
Armando

[0] https://releases.openstack.org/pike/schedule.html#p-rc1
[1] https://review.openstack.org/#/c/491560/1
__
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] [neutron] no CI and upgrades meetings this week

[Ihar Hrachyshka]

Hi,

we are in pre-release mode, and some of active participants will not
be able to join those meetings, so we will cancel them this week.

Thanks, and see you all next week.
Ihar

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

Re: [openstack-dev] [tripleo][qa] Enabling elastic-recheck for tripleo job

[Emilien Macchi]

On Mon, Aug 7, 2017 at 9:18 AM, Paul Belanger  wrote:
> I've just pushed up a change to puppet-elastic_recheck[1] to update the jobs
> regex for elastic-recheck to start tracking tripleo.  What this means, is now
> the elasticRecheck bot will start leaving comments on reviews once it matches 
> a
> failure in knows about.

Really cool, thanks.
Note we have an etherpad to track old queries in logstash:
https://etherpad.openstack.org/p/tripleo-ci-logstash-queries
I know it's not the best way to handle it and we should use more
elastic-recheck, but we can also re-use some queries if needed and
remove this etherpad, with this move to elastic-recheck.
-- 
Emilien Macchi

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

Re: [openstack-dev] [all][ptl][tc] IMPORTANT upcoming change to technical elections

[Ken'ichi Ohmichi]

Hi Clark,

Thanks for your support, that works for me :-)

Thanks

---

2017-08-07 10:10 GMT-07:00 Clark Boylan :
> On Mon, Aug 7, 2017, at 10:01 AM, Ken'ichi Ohmichi wrote:
>> Hi
>>
>> My name is on the nonmembers list and I guess that could be because of
>> "Current Member Level: Speaker", not "Current Member Level: Foundation
>> Member".
>> Can I know how to change this member level?
>>
>> Thanks
>> Ken'ichi Ohmichi
>>
>
> If you login to your foundation profile there should be a button that
> says "Make me a foundation member" or similar. There are more details on
> that process in the answer for
> https://ask.openstack.org/en/question/56720/cannot-store-contact-information-when-updating-info-in-openstack-gerrit/.
>
> Clark
>
> __
> 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] [requirements][ptls] HELP! Thawing the requirements repo

[Armando M.]

On 6 August 2017 at 23:33, Akihiro Motoki  wrote:

> 2017-08-07 11:59 GMT+09:00 Tony Breeds :
> > Hi All,
> > So as you all know we've frozen the requirements repo and it will
> > stay frozen until after all the cycle-with-milestones projects have
> > stable/pike branches.  That's pretty normal.
> >
> > The last couple of cycles we've seen issues with projects that crate
> > stable/pike branches *after* we've thawed/re-opened requirements repo
> > for $next_release.
> >
> > What happens is those projects are still stabilising for pike but
> > getting requirements updates for queens.  When they *do* branch for pike
> > they quickly get a proposal-bot change which seems to take things
> > backwards.  This bad for (at least) a couple of reasons.
> >
> > 1. Those projects are testing against the wrong requirements
> > 2. You end up with a patch release for $project that radically changes
> > the requirements for $project.
>
> Yeah, totally agree the above.
>
> >
> > So I need some help identifying which projects are going to fall into
> > this scenario.  The easy to identify ones are cycle-trailing and we can
> > easily cope with that by as there are only 4 of them.  My instinct tells
> > me that many of the neutron (stadium?) and horizon-plugin projects will
> > fall into this boat.
>
> I think neutron stadium and horizon plugin projects with
> cycle-with-intermediary are potentially affected.
> They tends to ship a final release (and cut a stable branch if necessary).
>
> I think we can easily list such projects for official projects.
> It is not easy to do it for hosted projects as we don't know their
> release models.
> Do we want to take care of hosted projects?
>
>
> The following is about official projects.
>
> According to the release repo, there is no *official* neutron stadium
> projects with cycle-with-intermediary release model.
> networking-hyperv (of the winstackers project) adopts
> cycle-with-intermediary model and it looks affected.
>
> Grepping the release deliverables, *official* horizon plugin projects
> with cycle-with-intermediary models are:
>
> $ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
> | grep -v cycle-with-milestones | cut -d : -f 1
> deliverables/pike/cloudkitty-dashboard.yaml
> deliverables/pike/ironic-ui.yaml
> deliverables/pike/karbor-dashboard.yaml
> deliverables/pike/magnum-ui.yaml
> deliverables/pike/manila-ui.yaml
> deliverables/pike/monasca-ui.yaml
> deliverables/pike/senlin-dashboard.yaml
> deliverables/pike/solum-dashboard.yaml
> deliverables/pike/tacker-horizon.yaml
> deliverables/pike/vitrage-dashboard.yaml
> deliverables/pike/watcher-dashboard.yaml
> deliverables/pike/zun-ui.yaml
>
>
> In addition, regarding neutron stadium projects and horizon plugin
> projects,
> they also need to update the branch (from master to stable/pike) of
> neutron or horizon repo
> as they installs neutron or horizon using tox_install.sh
> (in addition to the branch of requirements repo).
> This needs to happen just after stable/pike branch of neutron or
> horizon is created.
>

The switch to cycle-with-milestone [1] for all projects under neutron
governance (except neutron-lib and ovsdbapp that are libraries) was done
with the explicit intent of avoiding the overdue cut of stable branches for
the current release, which may lead to the exact problem that Tony stated
here.

[1] https://review.openstack.org/#/c/437699/


>
> Thanks,
> Akihiro
>
> > Once we know the scope of the affected projects we can work out how to
> > thaw the requirements repo with minimum impact.  The alternative is to
> > have the requirements repo frozen for > 1 month which no one wants.
> >
> > 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
>
__
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][ptl][tc] IMPORTANT upcoming change to technical elections

[Clark Boylan]

On Mon, Aug 7, 2017, at 10:01 AM, Ken'ichi Ohmichi wrote:
> Hi
> 
> My name is on the nonmembers list and I guess that could be because of
> "Current Member Level: Speaker", not "Current Member Level: Foundation
> Member".
> Can I know how to change this member level?
> 
> Thanks
> Ken'ichi Ohmichi
> 

If you login to your foundation profile there should be a button that
says "Make me a foundation member" or similar. There are more details on
that process in the answer for
https://ask.openstack.org/en/question/56720/cannot-store-contact-information-when-updating-info-in-openstack-gerrit/.

Clark

__
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][ptl][tc] IMPORTANT upcoming change to technical elections

[Ken'ichi Ohmichi]

Hi

My name is on the nonmembers list and I guess that could be because of
"Current Member Level: Speaker", not "Current Member Level: Foundation
Member".
Can I know how to change this member level?

Thanks
Ken'ichi Ohmichi

---


2017-08-03 8:07 GMT-07:00 Doug Hellmann :
>
>> On Aug 2, 2017, at 10:53 PM, Jeremy Stanley  wrote:
>>
>> On 2017-07-17 16:17:00 + (+), Jeremy Stanley wrote:
>>> If you want to run or vote in upcoming elections for PTL and TC,
>>> make sure your Foundation Individual Membership is active and has at
>>> least one Email address which matches an Email address in your
>>> Gerrit account: log in at https://www.openstack.org/profile/ and
>>> check that it says "Current Member Level: Foundation Member" near
>>> the top and that at least one of the Primary, Second or Third Email
>>> Address fields contains an address which matches at least one of the
>>> entries available in the Preferred Email drop-down at
>>> https://review.openstack.org/#/settings/contact (case sensitivity
>>> doesn't matter but they at least need to be spelled the same).
>>>
>>> If you're an "extra-ATC" and don't have a Gerrit account (this is
>>> common for translators on the I18n team) then you still need to be a
>>> Foundation Member to participate in technical elections and should
>>> make sure your member profile includes the Email address listed for
>>> you on your team's page at
>>> https://governance.openstack.org/tc/reference/projects/ .
>> [...]
>>
>> For those who haven't double-checked their memberships, I am
>> attaching a list of OpenStack Foundation Individual Member IDs and
>> names for contributors to official deliverable repositories between
>> 2016-09-17 and the present (members.txt.gz, 2315 entries in total,
>> these should be eligible to vote in elections for projects to which
>> they contributed if a runoff is held). I'm also attaching a list of
>> the names of contributors over the same time period who could not be
>> automatically matched up to foundation membership profiles
>> (nonmembers.txt.gz, 291 entries in total).
>>
>> If you want to vote in upcoming elections and your membership isn't
>> lining up with your contributor account/addresses (that is to say,
>> your name is in the attached nonmembers.txt.gz file) then please
>> follow the quoted instructions above from my earlier message as soon
>> as possible.
>>
>> Should you have any trouble reading the attached compressed lists,
>> you can also view them in a browser at the following URLs:
>>
>>members.txt - http://paste.openstack.org/raw/617357/
>>
>>nonmembers.txt - http://paste.openstack.org/raw/617358/
>>
>
> I had a quick look at that nonmembers.txt list and noticed several 
> long-standing members of our community are included. PLEASE EVERYONE go check 
> your settings so you are not left out of this election.
>
> Doug
>
>> --
>> Jeremy Stanley
>> __
>> 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] Functional job failure rate at 100%

[Ihar Hrachyshka]

On Mon, Aug 7, 2017 at 2:52 AM, Jakub Libosvar  wrote:
> Hi all,
>
> as per grafana [1] the functional job is broken. Looking at logstash [2]
> it started happening consistently since 2017-08-03 16:27. I didn't find
> any particular patch in Neutron that could cause it.
>
> The culprit is that ovsdb starts misbehaving [3] and then we retry calls
> indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
> a bug [4] and started investigation, I'll update my findings there.
>
> I think at this point there is no reason to run "recheck" on your patches.
>
> Thanks,
> Jakub
>
> [1]
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
> [2] http://bit.ly/2vdKMwy
> [3]
> http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> [4] https://bugs.launchpad.net/neutron/+bug/1709032

Considering all the instability of the job we see lately (this bug
being the latest hit, but we also have bug
https://bugs.launchpad.net/neutron/+bug/1707933, close release, and no
significant resources on digging the issue, I propose to temporarily
disable the job: https://review.openstack.org/#/c/491548/. I also
suggest our mighty leadership to harness awareness of the issue and
rally troops to get it solved.

(to reply to Kevin's request in IRC) To recap what happened with
timeout bug: https://bugs.launchpad.net/neutron/+bug/1707933, it
popped up ~ month ago in master, but it hits Ocata branch too (so it's
either a recent backport, or some external dependency). The way it
happens is one of test worker (almost always running a
FirewallTestCase test case) dies in the middle of run (you can see
'Killed' message in console log, and most of the times, you can also
see the job taking ~2h and the last test worker dying with
'inprogress' state). The first hypothesis was that some (other?) test
case calls execute(['kill', ...]) with the worker PID. To check that,
Jakub proposed https://review.openstack.org/#/c/487065/ and rechecked
for a while until the bug was triggered in the gate. The collected log
suggested that kill was NOT called with the PID. The next step could
be catching all os.kill() calls in all functional tests and logging
their arguments somewhere (with call stacks). We were thinking of
mocking os.kill, replacing it with a function that would log and pass
it to the original implementation, but didn't have time for that so
far.

Regards,
Ihar

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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Boden Russell]

On 8/4/17 1:26 PM, Boris Pavlovic wrote:
> 
> That's not going to work for dozens of OpenStack projects. It's just
> won't scale. Every project should maintain plugin for their project. And
> it should be enough to say "pip install python-client" that
> extend the Core OpenStack python client and adds support of new commands. 
> 
> The whole core part should be only about how to make plugins interface
> in such way that it's easy to extend and provide to end user nice user
> experience from both side (shell & python) and nice and stable interface
> for client developers . 


I echo Boris's point; if the client side isn't pluggable and extendable
(in a reusable fashion), then how can we build a consistent CLI for
users of our APIs that do support pluggable (potentially out-of-tree)
extensions (ex: neutron)?

It's a concern with the current trajectory of OSC/SDK and one I
mentioned on the ML last week [1].

If we're going to reevaluate this client side "plumbing", I truly hope
we take into consideration how our users are interfacing with the CLI,
which today, includes the ability to handle API resource extensions in
the classic python client, but not in OSC.

As per the bug/RFE linked in [1], I'm willing to throw some code down to
help make this happen; it's just not clear who the right team is to
queue this discussion/code up with.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.html

__
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] [docs] Updating the docs team mission statement

[Petr Kovar]

Hi all,

With the core docs suite moving from openstack-manuals to individual
project repos as per
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
it's also time to update the docs team mission statement from
https://governance.openstack.org/tc/reference/projects/documentation.html.

What are everybody's thoughts on what should the new mission statement
say now that most OpenStack docs maintenance is in the hands of project
teams?

One idea is for the docs team to act as a focused group of editors and
maintain a common set of guidelines, recommended practices (style
guidelines come to mind, for instance), and requirements (such as a common
docs and publishing structure shared across projects).

Other ideas, thoughts, or comments?

Based on the feedback from the community, we plan to update
https://governance.openstack.org/tc/reference/tags/docs_follows-policy.html
too.

Thanks,
pk

__
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][qa] Enabling elastic-recheck for tripleo job

[Paul Belanger]

Greetings,

I've just pushed up a change to puppet-elastic_recheck[1] to update the jobs
regex for elastic-recheck to start tracking tripleo.  What this means, is now
the elasticRecheck bot will start leaving comments on reviews once it matches a
failure in knows about.

The goal here is to better inform tripleo developers of the reasons of job
failures in an effort to find patterns / make fixes. From a developers POV, the
only difference you'll see if the elasticRecheck bot leaving a comment on your
patch when it finds a failure, if that does happen. Please take a moment to look
at the launchpad bug / logstash query.  

At the moment we are tracking:
  Bug 1708704 - yum client: [Errno 256] No more mirrors to try[2]

We have setup AFS mirrors to better help with yum failures, so I'd like to make
sure all jobs are properly setup to use it.

[1] https://review.openstack.org/491535
[2] http://status.openstack.org/elastic-recheck/index.html#1708704

__
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] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-04 19:34:25 
+:
> Hi all,
> 
> We had a couple of discussions with the Oslo team related to implement
> Pluggable drivers for oslo.config[0] and use those feature to implement
> support to protect plaintext secret on configuration files[1].
> 
> In another hand, due the containerized support on OpenStack services, we
> have a community effort to implement a k8s ConfigMap support[2][3], which
> might make us step back and consider how secret management will work, since
> the config data will need to go into the configmap *before* the container
> is launched.
> 
> So, I would like to see what the community think. Should we continue
> working on that pluggable drivers and protect plain text secrets support
> for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss
> that feature?
> 
> Thanks for the feedback in advance.
> 
> Cheers,
> 
> [0] https://review.openstack.org/#/c/454897/
> [1] https://review.openstack.org/#/c/474304/
> [2]
> https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> [3] https://kubernetes.io/docs/
> 
> tasks/configure-pod-container/configmap/
> 
> [4] https://etherpad.openstack.org/p/oslo-ptg-queens

I've added some of the deployment project tags to the subject line to
expand the audience for this discussion.

We're trying to decide what to do about space at the PTG for this
conversation. My Monday-Wednesday are completely booked, so I was
hoping we could do it Thursday. The Oslo team won't have a room then, so
we need to either find space in another room or reserve one of the extra
rooms mentioned on the schedule [1].

Kendall & Thierry, what do we need to do to reserve that room if we
can't find space in another team room?

Before we meet in Denver, it would be very useful to have some documents
describing the end-to-end processes teams foresee using for managing
secrets.

Doug

[1] 
https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true

__
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] [keystone][api] Backwards incompatible changes based on config

[Lance Bragstad]

It sounds like there isn't any major objection to moving forward with a
fix and getting this into Pike. I would be inclined to say the
discussion here has elevated that priority since missing Pike would
expose the 204 -> 403 in an official release.


On 08/07/2017 03:54 AM, Chris Dent wrote:
> On Fri, 4 Aug 2017, Lance Bragstad wrote:
>> On 08/04/2017 03:45 PM, Kristi Nikolla wrote:
>>> Therefore the call which now returns a 403 in master, returned a 2xx in
>>> Ocata. So we would be fixing something which is broken on master rather
>>> than changing a ‘contract’.
>>
>> Good call - with that in mind I would be inclined to say we should fix
>> the issue in Pike that way we keep the 204 -> 204 behavior the same
>> across releases. But I'll defer to someone from the API WG just to make
>> sure.
>
> I think that's fair. Given that you're not doing microversions and
> you aren't inclined to commit to CD, it's a pragmatic solution to
> mis-functionality that was introduced between code releases.
>
> It also sounds like an edge case where it's very unlikely that
> there's extant client code that is relying on that 403 to make
> decisions on next steps.
>
> The interop guideline is intentionally very strict and detailed, to
> make it clear how much you need to think about to really do it well,
> but in many cases should be considered as a tool for evaluating the
> extent of the damage a change might cause, not the law.
>
> Especially if you haven't got microversions available.
>
>
>
> __
> 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



signature.asc
Description: OpenPGP 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] [neutron] Bug deputy report

[Jakub Libosvar]

Hi all,

I was bug deputy for the last week and as I'm not gonna attend meeting
today, I'm sending a report here:

There weren't that many urgent things reported last week. Here are some
bugs that needs more eyes:

 - https://bugs.launchpad.net/neutron/+bug/1708030 - failure in
functional tests, has a patch ready

 - https://bugs.launchpad.net/neutron/+bug/1708133 - has a patch for
review but will probably need somebody involved in quotas and policies

 - https://bugs.launchpad.net/neutron/+bug/1708463 - alembic migration
script failure


A failure from the weekend:

 - https://bugs.launchpad.net/neutron/+bug/1709032 - currently failing
in 100%, I was looking at it today but I still don't understand what
causes it.


Cheers,
Jakub

__
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] [elections][shade] PTL candidacy for Queens

[Monty Taylor]

I would like to be the PTL of the shade project for another cycle.

Over the past few years the shade project has grown from a utility 
library containing some logic needed by the Infrastructure team and 
Ansible for interacting with OpenStack clouds to a rich SDK that serves 
the general needs of humans who want to use OpenStack.


This past cycle we (mostly) accomplished two main goals that were not 
exciting features but which are immensely important nonetheless. We 
ported our unittests to use requests-mock instead of mocking out 
individual python client libraries, and we replaced our use of the 
python client libraries with direct REST calls based on keystoneauth. 
This was rather mind-numbing and I fear we may have eaten the brains of 
a few wonderful contributors - but it means that our dependency chain is 
much slimmer so inclusion in distros and alongside apps should be less 
costly.


We still need to finish converting the last keystoneclient calls and to
transition the Ironic calls. TheJulia did WAY too good of a job writing 
tests when implemeting Ironic support originally, so it may take a 
little while to finish that one.


Over the next cycle we need to update our REST layer to incorporate the 
recent changes made in keystoneauth related to service and version 
discovery. This largely means removing code, which is always pleasant. 
Once that's done we'll be in a position to start using microversions as 
appropriate.


Glance has landed experimental support for the new Image upload process, 
and we need to add detection and implementation of that to our Image 
upload system so that we'll use it when it's available.


There is some very important work we need to do deep in the guts related 
to caching and batching of calls. We have a system for this that is 
designed to ensure that large-scale systems such as Nodepool can operate 
effectively, but it's proving costly for smaller users and needs to be 
optimized.


I recently suggested merging the work of the python-openstacksdk team 
into shade. If we decide as a larger OpenStack community that this is a 
direction we want to go, we'll need to do a decent amount of plumbing to 
ensure that's as smooth as possible for both sets of users.


Finally, I think if we don't make some forward progress on the oaktree 
gRPC federation API that samueldmq will be very unhappy with me. We've 
been explicitly putting off working on that to ensure we get the 
RESTification work done. This next cycle I expect to make real progress 
on that so that we can at least have a proof point to look at so we can 
discuss a real thing rather than a theory.


I'm proud of what we've done so far, and I think there is a ton we can 
continue to do to serve OpenStack End Users well.


Thank you for your consideration,
Monty

__
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] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

[Along Meng]

>From the log info,It shows that your 'node' maybe is not the valid str.
You can show the node name via 'print node' and try to call
str(node).encode('utf-8')
, identify does it can goes well.

2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
str(node).encode('utf-8')
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils UnicodeDecodeError:
'ascii' codec can't decode byte 0xde in position 4: ordinal not in
range(128)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils



On Sat, Aug 5, 2017 at 7:16 PM, Yaguang Tang  wrote:

> Hi gnocchi devs,
>
> I have an issue when using gnocchi 4.0, the storage backend is ceph, and
> tooz coordination is redis. currently  gnocchi api in apache wsgi mode,
> only one controller node running gnocchi-metricd & gnocchi-statsd daemon.
> the error log of gnocchi-metricd is as follow.
>
>
>
> 2017-08-05 18:14:18.643 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
> storage backend use 'cradox' python library
> 2017-08-05 18:14:18.654 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
> storage backend use 'cradox' python library
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils [-] Unhandled
> exception
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils Traceback (most
> recent call last):
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/cotyledon/_utils.py", line 84, in
> exit_on_exception
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils yield
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/cotyledon/_service.py", line 139, in
> _run
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.run()
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 120, in run
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
> self._configure()
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 87, in
> wrapped_f
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
> r.call(f, *args, **kw)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 177, in call
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
> fut.result()
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line 396,
> in result
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
> self.__get_result()
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 159, in call
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils result =
> fn(*args, **kwargs)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 193, in _configure
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.GROUP_ID,
> partitions=200)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tooz/coordination.py", line 284, in
> join_partitioned_group
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
> partitioner.Partitioner(self, group_id)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tooz/partitioner.py", line 45, in
> __init__
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
> partitions=self.partitions)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tooz/hashring.py", line 47, in __init__
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
> self.add_nodes(set(nodes))
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
> "/usr/lib/python2.7/site-packages/tooz/hashring.py", line 71, in add_nodes
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
> str(node).encode('utf-8')
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils UnicodeDecodeError:
> 'ascii' codec can't decode byte 0xde in position 4: ordinal not in
> range(128)
> 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
>
> Is this a config issue or bug ? any tips or help is much appreciated :-)
>
>
> --
> Tang Yaguang
>
>
>
>
> __
> 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]The principle of restrict the scope of returned events

[Along Meng]

OK，thanks @gord

Look forward to other people's suggestion.

On Sat, Aug 5, 2017 at 12:12 AM, gordon chung  wrote:

> hi,
>
> i think this is best to ask this on mailing list. to be honest, i do not
> work on Panko much anymore. feel free to propose something if it doesn't
> meet your requirements.
>
> On 04/08/17 10:59 AM, Along Meng wrote:
> > HI, gord
> >
> > https://review.openstack.org/#/c/218706
> >
> > As the above patch you submitted shows that: ceilometer will restricts
> > the scope of returned events. if admin role,
> > user is allowed to query all events which have traits.project_id
> > value*that match it's own project*OR any event without any project_id
> trait.
> >
> > I think if admin role, user is allowed to query all events *no matter
> the *
> > *traits.project_id value match it's own project or not *is more property.
> >
> > So, I wonder to know why we designed the principle like your patch's
> > commit-message shows.
> > Thanks
> >
> > MengAlong
>
> --
> 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] [kuryr] No weekly IRC meeting today

[Antoni Segura Puimedon]

HI Kuryrs!

Since most of the people are on PTO today, we'll skip the weekly IRC
meeting and hold it next week. I don't have PTO, so if there's
anything you want to discuss, you are very welcome to come to
#openstack-kuryr

Regards,

Toni

__
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] support for various glance image reference formats - do we need them all?

[Pavlo Shchelokovskyy]

Hi all,

currently our GlanceImageService seems to support several ways of defining
a reference to glance image:

1) simple image UUID [0]
2) image UUID prefixed with 'glance://' protocol [1] (well, actually
anything starting with 'glance://' and ending with '/')
3) full REST path to the image (as in
http:///v2/images/),
also used to extract the glance API address [2]

Support for #3 must surely be removed, as we are moving to API endpoint
discovery from keystone catalog.
Besides I am pretty sure this code path can not actually be reached
currently, as the 'is_glance_image' will ignore such image refs and return
False for those [3], and 'get_image_service' would also not return the
GlanceImageService instance for such image refs [4].
Hence the question - if it is unusable anyway now, should we execute the
standard deprecation process when removing support for it or just remove
right away?

As for the #1 and #2 I do not see any big difference between those, and
proposed deprecating and eventually removing support for #2 ('glance://'
scheme) as part of [5]. Two people in review already raised a concern about
removing such support.

Thus I'd like to ask a broader audience - do we need support for glance
image references in 'glance://*' form? Is it actually used somewhere?
What are the benefits of having it besides simple UUID?

[0]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n149
[1]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n155
[2]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n160
[3]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n208
[4]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/image_service.py#n267
[5] https://review.openstack.org/#/c/467728

Cheers,

-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
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] [keystone][api] Backwards incompatible changes based on config

[Sean McGinnis]

On Mon, Aug 07, 2017 at 07:33:04AM -0500, Dean Troyer wrote:
> On Mon, Aug 7, 2017 at 4:00 AM, Chris Dent  wrote:
> > Many deployments are several months behind. If _all_ (or even many)
> > deployments are that far behind, maybe we could consider saving ourselves
> > some pain?
> 
> I would agree with this when we get some solid feedback on the impact.
> We started with CD as one of the fundamental
> constraints^H^H^H^H^Hgoals and to drop it should be a deliberate
> decision.

Did we ever state that goal somewhere?


__
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] [keystone][api] Backwards incompatible changes based on config

[Dean Troyer]

On Mon, Aug 7, 2017 at 4:00 AM, Chris Dent  wrote:
> Many deployments are several months behind. If _all_ (or even many)
> deployments are that far behind, maybe we could consider saving ourselves
> some pain?

I would agree with this when we get some solid feedback on the impact.
We started with CD as one of the fundamental
constraints^H^H^H^H^Hgoals and to drop it should be a deliberate
decision.

In addition to direct deployments, I found things like this [0] in a
quick search for who is publicly saying they (still) do CD, it is a
category I had not considered before and makes me think that this kind
of decision has a wider impact range than we may be aware of.

Looking in https://www.openstack.org/analytics for the 2017 User
Survey shows no production deployments on "trunk" but of course that
doesn't mean there are none.  I wonder if deployments using CD are (or
have now) fallen behind similarly to what we know to be the case with
deployments on releases, only maybe not quite as far?

dt

[0] 
https://devops.com/automic-empowers-cloud-continuous-delivery-openstack-integration/

-- 

Dean Troyer
dtro...@gmail.com

__
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][bifrost] Unable to Enroll Inventory

[Mark Goddard]

Hi Aimee,

I suspect the reason that ansible is owned by root in your setup is that
you ran scripts/env-setup.sh using sudo. Could you paste the errors seen
when running without sudo?

Mark

On 3 August 2017 at 23:09, Aimee Ukasick 
wrote:

> Thanks Mark for pointing me in the right direction! It turned out to
> be a permissions issue with the local Ansible installation.
>
> I started over with a new user (stack, passwordless sudo) and decided
> to use the bifrost's env-setup script, which I was not able to run
> unless prefaced with sudo.
>
>
> stack@ubuntu-jumphost:~/bifrost$ sudo bash ./scripts/env-setup.sh
>
> stack@ubuntu-jumphost:~/bifrost$ source env-vars
>
> stack@ubuntu-jumphost:~/bifrost$ echo $PATH
> /home/stack/.local/bin:/home/stack/bin:/home/stack/.local/
> bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/
> sbin:/bin:/usr/games:/usr/local/games:/snap/bin
>
> stack@ubuntu-jumphost:~/bifrost/playbooks$ which ansible
> /home/stack/.local/bin/ansible
> stack@ubuntu-jumphost:~/bifrost/playbooks$ ansible-playbook - -i
> inventory/target install.yaml -e staging_drivers_include=true
> Traceback (most recent call last):
>   File "/home/stack/.local/bin/ansible-playbook", line 44, in 
> import ansible.constants as C
> ImportError: No module named ansible.constants
>
> stack@ubuntu-jumphost:~/bifrost/playbooks$ ansible --version
> Traceback (most recent call last):
>   File "/home/stack/.local/bin/ansible", line 44, in 
> import ansible.constants as C
> ImportError: No module named ansible.constants
>
> The ~/.local/bin/ansible folder was owned by root:root as was
> ~/.ansible. Once I changed the ownership to stack:stack, ansible
> worked as expected. I was able to run the ansible-playbook command
> without prefacing it with sudo. So I had a successful installation. Do
> you know why the bifrost env-setup.sh installed ansible with root
> ownership in my ~/.local directory? Is that the default Ansible
> behavior?  Is the expectation that I switch to root to install/run
> bifrost?
>
>
> I was able to enroll my servers without a hitch.
>
> Friday I plan to deploy - hopefully I've identified and fixed all the
> kinks on my system.
>
>
> Thanks again for your help!
>
> aimee
> irc:aimeeu
>
>
>
> On Thu, Aug 3, 2017 at 3:27 AM, Mark Goddard  wrote:
> > Hi Aimee,
> >
> > My guess is that your error is due to your use of sudo when running
> > ansible-playbook.
>
> __
> 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][Nova] Editing flavor causing instance flavor display error

[Rob Cresswell (rcresswe)]

I’m planning on putting up a patch for this today. My proposal is to add a 
setting that disables it by default, then add a big warning side on the setting 
documentation and release notes. Anyone who then explicitly enables it will see 
the warning. Beyond that, we can deprecate it this cycle, but won’t be able to 
drop it until the R release.

Rob

__
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] No meeting today - 08/7/2017

[Renat Akhmerov]

Hi,

We decided to cancel today’s Mistral meeting.

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] [neutron] Functional job failure rate at 100%

[Jakub Libosvar]

Hi all,

as per grafana [1] the functional job is broken. Looking at logstash [2]
it started happening consistently since 2017-08-03 16:27. I didn't find
any particular patch in Neutron that could cause it.

The culprit is that ovsdb starts misbehaving [3] and then we retry calls
indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
a bug [4] and started investigation, I'll update my findings there.

I think at this point there is no reason to run "recheck" on your patches.

Thanks,
Jakub

[1]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
[2] http://bit.ly/2vdKMwy
[3]
http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
[4] https://bugs.launchpad.net/neutron/+bug/1709032

__
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 32

[Balazs Gibizer]

Hi,

Here is the status update / focus setting mail about notification work
for week 32.

Bugs

[Low] https://bugs.launchpad.net/nova/+bug/1696152 nova notifications
use nova-api as binary name instead of nova-osapi_compute
Agreed not to change the binary name in the notifications. Instead we
make an enum for that name to show that the name is intentional.
The patch was split to two parts:
* https://review.openstack.org/#/c/487126 rename binary to source in
versioned notifications
* https://review.openstack.org/#/c/476538 Use enum value instead of
string service name

[Medium] https://bugs.launchpad.net/nova/+bug/1699115 api.fault
notification is never emitted
Still no response on the ML thread about the way forward.
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118639.html

[High] https://bugs.launchpad.net/nova/+bug/1706563
TestRPC.test_cleanup_notifier_null fails with timeout
[High] https://bugs.launchpad.net/nova/+bug/1685333 Fatal Python error:
Cannot recover from stack overflow. - in py35 unit test job
The first bug is just a duplicate of the second. It seems the TetRPC
test suite has a way to end up in an infinite recusion.
I don't know about a way to reproduce it localy or to change the gate 
env so that python prints out the full stack trace to see where the 
problematic call is. Also adding extra log messages won't help as a 
timed out test doesn't have the log messages printed to the logs. So 
this bug is pretty stuck.



Versioned notification transformation
-
Thanks to Matt we have the Queens bp open 
https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-queens
Open patches needs to retargeted to this bp as soon as master is open 
for Queens.


Searchlight integration
---
I opened a follow up bp for Queens: 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight-queens
I left it in drafting state as I expect the Searchlight team to come 
back with some feedback and / or extra needs.


Small improvements
--
These improvements are test and doc generation only so probably not
affected by the FF.

* https://review.openstack.org/#/c/428199/ Improve assertJsonEqual
error reporting.

* https://review.openstack.org/#/q/topic:refactor-notification-samples
Factor out duplicated notification sample data
This is a start of a longer patch series to deduplicate notification
sample data. The third patch already shows how much sample data can be
deleted from nova tree. We added a minimal hand rolled json ref
implementation to notification sample test as the existing python json
ref implementations are not well maintained.


Weekly meeting
--
As nothing important is going on right now in the subteam so I'm 
planning to not having a meeting this week either. Please disagree in a 
reply if you have items to discuss.


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] [nova][searchlight] status of an instance on the REST API and in the instance notifications

[Balázs Gibizer]

> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: July 26, 2017 03:23
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][searchlight] status of an instance on the
> REST API and in the instance notifications
> 
> On 7/19/2017 10:54 AM, Balazs Gibizer wrote:
> > On Wed, Jul 19, 2017 at 5:38 PM, McLellan, Steven
> >  wrote:
> >> Thanks Balazs for noticing and replying to my message!
> >>
> >> The Status field is quite important to us since it's the indicator of
> >> VM state that Horizon displays most prominently and the most simple
> >> description of whether a VM is currently usable or not without having
> >> to parse the various _state fields. If we can't get this change added
> >> in Pike I'll probably implement a simplified version of the mapping in
> >> [2], but it would be really good to get it into the notifications in
> >> Pike if possible. I understand though that this late in the cycle it
> >> may not be possible.
> >
> > I can create a patch to add the status to the instance notifications but
> > I don't know if nova cores accept it for this late in Pike.
> > @Cores: Do you?
> >
> > Cheers,
> > gibi
> 
> It's probably too late to be dealing with this right now in Pike. I'd
> like to defer this to Queens where we can refactor the REST API common
> view code into a better place where it could be re-used with the
> notifications code if this is something we're going to add to the
> versioned notifications, and it's probably easy enough to do that.

I opened a bp for Queens [1].
@Searchlight folks: please check it and come back with feedback and additional 
requirements.

Cheers,
gibi
[1] 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight-queens

> 
> --
> 
> 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 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] [keystone][api] Backwards incompatible changes based on config

[Chris Dent]

On Fri, 4 Aug 2017, Joshua Harlow wrote:

Any idea of who are these deployers? I think I knew once who they might have 
been but I'm not really sure anymore. Are they still doing this (and can 
afford doing it)? Why don't we hear more about them? I'd expect that 
deployers (and there associated developer army) that are trying to do this 
would be the *most* active in IRC and in the mailing list yet I don't really 
see any such activity (which either means we never break them, which seems 
highly unlikely, or that they don't communicate through the normal channels, 
ie they go through some vendor, or that they just flat out don't exist 
anymore).


I'd personally really like to know how they do it (especially if they do not 
have an associated developer army)... Because they have always been a pink 
elephant that I've heard exists 'somewhere' and they manage to make this all 
work 'somehow'.


I'd like to know this too. As Sean M says, we frequently make
compromises to support CD. In a sort of platonic sense, it is a
great goal, but it would be a lot easier to achieve if it had
participation from the people doing it.

Many deployments are several months behind. If _all_ (or even many)
deployments are that far behind, maybe we could consider saving ourselves
some pain?

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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

[Chris Dent]

On Fri, 4 Aug 2017, Lance Bragstad wrote:

On 08/04/2017 03:45 PM, Kristi Nikolla wrote:

Therefore the call which now returns a 403 in master, returned a 2xx in
Ocata. So we would be fixing something which is broken on master rather
than changing a ‘contract’.


Good call - with that in mind I would be inclined to say we should fix
the issue in Pike that way we keep the 204 -> 204 behavior the same
across releases. But I'll defer to someone from the API WG just to make
sure.


I think that's fair. Given that you're not doing microversions and
you aren't inclined to commit to CD, it's a pragmatic solution to
mis-functionality that was introduced between code releases.

It also sounds like an edge case where it's very unlikely that
there's extant client code that is relying on that 403 to make
decisions on next steps.

The interop guideline is intentionally very strict and detailed, to
make it clear how much you need to think about to really do it well,
but in many cases should be considered as a tool for evaluating the
extent of the damage a change might cause, not the law.

Especially if you haven't got microversions available.

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

Re: [openstack-dev] Tracing (all the places)

[vin...@vn.fujitsu.com]

> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: Friday, 04 August, 2017 11:12
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] Tracing (all the places)
> 
> vin...@vn.fujitsu.com wrote:
> > Hello harlowja,
> >
> > I'm really happy to see that you are back in this `tracing` topic [and 
> > @boris-42
> (too)].
> 
> We never left, haha, but ya, I can say (and probably boris would agree)
> that trying to get OSprofiler started and integrated somewhat 'burned'
> both of us (it involved a ton of convincing people of the value of it,
> when I had more hoped that the value of it was obvious). But I'm glad
> that people are starting to realize its value (even if they have to be
> told and educated by google or other companies that have been doing this
> for a long time).
> 
> >
> > Last week, we saw that Rajul proposed 02 new blueprint in OSprofiler [1] 
> > and [2].
> > Besides, some other blueprints are being implemented in OSprofiler
> > such as overhead control [3] and OpenTracing compatible [4] [5]
> > (Uber Jaeger [6] is one of OpenTracing compatible tracer out there).
> >
> > For OpenTracing part, I have a PoC to make OSprofiler compatible with
> > OpenTracing specification at [5]. You can take a look at it this time too.
> > However, this time, I focus on reporting span/trace to other destinations
> > (rather than current drivers for OSprofiler[7]).
> >
> > OpenTracing API is changing a little bit fast for now, therefore, some APIs 
> > will be
> deprecated soon.
> > I had some discussions with OpenTracing community about some trouble when
> making OSprofiler
> > compatible with OpenTracing API.
> 
> Ya I expected this, opentracing also I think has a python
> client/wrapper(?), have you looked at what this offers (last time I
> checked most of opentracing was just a bunch of wrappers actually, and
> not much actually code that did anything unique)?
> 

Wrapper? Yes and No :D
If you look to the code, OpenTracing is just an interface and other new tracers 
should
follow it to implement. However, with OpenTracing, user can use any tracers that
`OpenTracing compatible` without modify a bunch of instrumented code.
Just change the name of tracer that you want to use.

For example, change tracer from Jaeger to LightStep.

With Jaeger:
opentracing.tracer = jeager_client.Config().config.initialize_tracer()

With lightstep:
opentracing.tracer = lightstep.Tracer(
component_name='your_microservice_name',
access_token='{your_access_token}')

Very simple (but not enough) :D


Jaeger client: https://github.com/uber/jaeger-client-python
LightStep: https://github.com/lightstep/lightstep-tracer-python

> >
> > For OpenStack part, last cycle, Performance team and other OpenStack 
> > developers
> added
> > OSprofiler support for many other projects (Nova, Magnum, Ironic, Zun ...)
> > and Panko, Aodh, Swift are on the way.
> 
> Yippe, now the bigger questions is where are all the UIs visualizing the
> traces (I know boris had https://boris-42.github.io/ngk.html but there
> has to be something nicer that perhaps the OpenTracing community has for
> a UI, ideally not a java monster like Zipkin, ha). Any thoughts there?
> 

With the UI, you can see the example with OSprofiler ouput that I redirect to
Jaeger here: 
https://tovin07.github.io/opentracing/jaeger-openstack-image-list.png

> >
> > At last, hope you will join us (again) in OpenStack `tracing` things.
> 
> We shall see :-P
> 
> >
> > [1] 
> > https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection
> > [2] 
> > https://blueprints.launchpad.net/osprofiler/+spec/tail-based-coherent-sampling
> > [3] 
> > https://blueprints.launchpad.net/osprofiler/+spec/osprofiler-overhead-control
> > [4] https://blueprints.launchpad.net/osprofiler/+spec/opentracing-compatible
> > [5] https://review.openstack.org/#/c/480018/
> > [6] http://jaeger.readthedocs.io/en/latest/architecture/
> > [7] https://github.com/openstack/osprofiler/tree/master/osprofiler/drivers
> >
> > Best regards,
> >
> > Vinh Nguyen Trong
> > PODC – Fujitsu Vietnam Ltd.
> 
> ___
> ___
> 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][tripleo-heat-template] how to get interface name from network name in service profile

[Zenghui Shi]

Thanks for the pointer Saravanan!
@Dan, would you mind if I continue the patch work at
https://review.openstack.org/#/c/383516/?

Cheers!
zenghui

On Wed, Aug 2, 2017 at 1:33 PM, Saravanan KR  wrote:

> On Wed, Aug 2, 2017 at 5:21 AM, Zenghui Shi  wrote:
> >
> > On Wed, 2 Aug 2017 at 02:34 Ben Nemec  wrote:
> >>
> >>
> >>
> >> On 07/25/2017 09:53 PM, Zenghui Shi wrote:
> >> > Hi,
> >> >
> >> > Could anyone shed some light on how to get the physical interface name
> >> > (e.g eth0) from network name (e.g PublicNetwork, ExternalNetwork) in
> >> > tripleo-heat-template service profile ?
> >> >
> >> > for example:
> >> >
> >> > I want to add a service profile under puppet/services/time/ptp.pp
> where
> >> > it uses 'PtpInterface' as a parameter to get physical interface name
> >> > (please refer to below piece of code), but I'd like to expose a more
> >> > user friendly parameter like NetworkName(e.g. provision network,
> >> > external network etc) instead of 'PtpInterface' and retrieve the
> actual
> >> > physical interface name from the NetworkName where the physical
> >> > interface is connected to, is there any possible way to do this ?
> >>
> >> I don't think there is.  In many cases the templates don't even know the
> >> name of the physical device on which the network will be running.  A
> >> simple example would be when a user uses the nicX abstraction to specify
> >> interfaces in their net-iso templates.  That doesn't get mapped to an
> >> actual interface name until os-net-config runs, and the results of that
> >> run are not available to the templates.
> >
> >
> > Thanks Ben!
> >
> > I'm also thinking if it makes sense to have a way in template or target
> > nodes to re-use the results of os-net-config for services which are
> bonded
> > to certain interfaces, or re-implement the os-net-config logic in
> template
> > to get the physical interface name. The latter one will be a repetitive
> work
> > of os-net-config.
>
> This patch [1] has been started by Dan Sneddon to provide the nic
> number to name mapping by providing an extra option "--interfaces" to
> os-net-config command. May this could be reused to get the mapping.
>
> Regards,
> Saravanan KR
>
> [1] https://review.openstack.org/#/c/383516/
>
> >
> > Cheers!
> > Zenghui
> >>
> >>
> >> >
> >> > 
> >> > parameters:
> >> > [...]
> >> >PtpInterface:  #  ---> change this parameter to PtpNetwork
> >> >  default: eth0
> >> >  description: PTP interfaces name.
> >> >  type: string
> >> >
> >> > resources:
> >> >RoleParametersValue
> >> >  type: OS::Heat::Value
> >> >  properties:
> >> >type: json
> >> >value: # ---> add logic to get real interface name
> >> > from PtpNetwork
> >> >  map_replace:
> >> >- map_replace:
> >> >  - tripleo::profile::base::time::ptp::ptp4l_interface:
> >> > PtpInterface
> >> >  - values: {get_param: [RoleParameters]}
> >> >- values:
> >> >PtpInterface: {get_param: PtpInterface}
> >> >
> >> > outputs:
> >> >role_data:
> >> >  description: Role ptp using commposable services.
> >> >  value:
> >> >service_name: ptp
> >> >config_settings:
> >> >  map_merge:
> >> >- get_attr: [RoleParametersValue, value]
> >> > [...]
> >> > 
> >> >
> >> > Thanks!
> >> > zenghui
> >> >
> >> >
> >> >
> >> > 
> __
> >> > 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 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] [Docs][Elections] PTL candidacy for Queens

[Chason]

Hello everyone,

I would like to announce my candidacy for Documentation PTL (Queens).

First of all, I wish to introduce myself briefly. I have been working on the 
bugs
of openstack-manuals project since the Liberty release. And the most I fixed is
the bugs of the Install Guide. In my opinion, Openstack is not very friendly 
with
new hand. If they install their first openstack environment according to our 
Install
Guide which may not be very accurate, she or he would be in a mess. I will 
continue
to focus on document bugs whether as a reviewer or PTL.

In this cycle, Alex( asettle) has coordinated the doc migration work [1]. I 
wish to
take this opportunity to thank all members of the OpenStack community who 
partcipated
in this work. We cannot achieve such seriously bug stuff without your 
cooperation. :) 

As you can see, we removed several guides from openstack-manuals project. There 
are
still many things [2] we have not yet to accomplished after the doc migration.
Some of these problems we already have solutions. But the others need to be 
discussed.
We are welcome everyone to join in our discussion[3]. It would be wonderful if 
you can
give us some ideas!

If I am elected PTL of the Documentation project, my focuses for the coming 
release
are to grow the Documentation team, keep the accuracy of documents, and work 
closely
with other projects to help them imporve documents.

Thanks for your consideration, and I am looking forward to work together with 
all of
you on getting the OpenStack documents to the next stage.

Cheers,

Chason

Email: chason.c...@foxmail.com
IRC: chason
Launchpad: chen-xing

[1] https://etherpad.openstack.org/p/doc-migration-tracking
[2] https://etherpad.openstack.org/p/doc-future-problems
[3] https://etherpad.openstack.org/p/denver-doc-PTG


__
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] [requirements][ptls] HELP! Thawing the requirements repo

[Akihiro Motoki]

2017-08-07 11:59 GMT+09:00 Tony Breeds :
> Hi All,
> So as you all know we've frozen the requirements repo and it will
> stay frozen until after all the cycle-with-milestones projects have
> stable/pike branches.  That's pretty normal.
>
> The last couple of cycles we've seen issues with projects that crate
> stable/pike branches *after* we've thawed/re-opened requirements repo
> for $next_release.
>
> What happens is those projects are still stabilising for pike but
> getting requirements updates for queens.  When they *do* branch for pike
> they quickly get a proposal-bot change which seems to take things
> backwards.  This bad for (at least) a couple of reasons.
>
> 1. Those projects are testing against the wrong requirements
> 2. You end up with a patch release for $project that radically changes
> the requirements for $project.

Yeah, totally agree the above.

>
> So I need some help identifying which projects are going to fall into
> this scenario.  The easy to identify ones are cycle-trailing and we can
> easily cope with that by as there are only 4 of them.  My instinct tells
> me that many of the neutron (stadium?) and horizon-plugin projects will
> fall into this boat.

I think neutron stadium and horizon plugin projects with
cycle-with-intermediary are potentially affected.
They tends to ship a final release (and cut a stable branch if necessary).

I think we can easily list such projects for official projects.
It is not easy to do it for hosted projects as we don't know their
release models.
Do we want to take care of hosted projects?


The following is about official projects.

According to the release repo, there is no *official* neutron stadium
projects with cycle-with-intermediary release model.
networking-hyperv (of the winstackers project) adopts
cycle-with-intermediary model and it looks affected.

Grepping the release deliverables, *official* horizon plugin projects
with cycle-with-intermediary models are:

$ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
| grep -v cycle-with-milestones | cut -d : -f 1
deliverables/pike/cloudkitty-dashboard.yaml
deliverables/pike/ironic-ui.yaml
deliverables/pike/karbor-dashboard.yaml
deliverables/pike/magnum-ui.yaml
deliverables/pike/manila-ui.yaml
deliverables/pike/monasca-ui.yaml
deliverables/pike/senlin-dashboard.yaml
deliverables/pike/solum-dashboard.yaml
deliverables/pike/tacker-horizon.yaml
deliverables/pike/vitrage-dashboard.yaml
deliverables/pike/watcher-dashboard.yaml
deliverables/pike/zun-ui.yaml


In addition, regarding neutron stadium projects and horizon plugin projects,
they also need to update the branch (from master to stable/pike) of
neutron or horizon repo
as they installs neutron or horizon using tox_install.sh
(in addition to the branch of requirements repo).
This needs to happen just after stable/pike branch of neutron or
horizon is created.

Thanks,
Akihiro

> Once we know the scope of the affected projects we can work out how to
> thaw the requirements repo with minimum impact.  The alternative is to
> have the requirements repo frozen for > 1 month which no one wants.
>
> 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