[openstack-dev] [glance][oslo][requirements] oslo.serialization fails with glance

[Matthew Thode]

https://review.openstack.org/531788 is the review we are seeing it in,
but 2.22.0 failed as well.

I'm guessing it was introduced in either

https://github.com/openstack/oslo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8
or
https://github.com/openstack/oslo.serialization/commit/cdb2f60d26e3b65b6370f87b2e9864045651c117
-- 
Matthew Thode


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] [oslo][oslo.log] JSON logs are missing the request ID

[Saverio Proto]

> I don't think this is a configuration problem.
> 
> Which version of the oslo.log library do you have installed?

Hello Doug,

I use the Ubuntu packages, at the moment I have this version:

python-oslo.log   3.16.0-0ubuntu1~cloud0

thank you

Saverio

__
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] [tc] Community Goals for Rocky

[Lance Bragstad]

On 01/12/2018 11:09 AM, Tim Bell wrote:
> I was reading a tweet from Jean-Daniel and wondering if there would be an 
> appropriate community goal regarding support of some of the later API 
> versions or whether this would be more of a per-project goal.
>
> https://twitter.com/pilgrimstack/status/951860289141641217
>
> Interesting numbers about customers tools used to talk to our @OpenStack APIs 
> and the Keystone v3 compatibility:
> - 10% are not KeystoneV3 compatible
> - 16% are compatible
> - for the rest, the tools documentation has no info
>
> I think Keystone V3 and Glance V2 are the ones with APIs which have moved on 
> significantly from the initial implementations and not all projects have been 
> keeping up.
Yeah, I'm super interested in this, too. I'll be honest I'm not quite
sure where to start. If the tools are open source we can start
contributing to them directly.
>
> Tim
>
> -Original Message-
> From: Emilien Macchi 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Friday, 12 January 2018 at 16:51
> To: OpenStack Development Mailing List 
> Subject: Re: [openstack-dev] [all] [tc] Community Goals for Rocky
>
> Here's a quick update before the weekend:
> 
> 2 goals were proposed to governance:
> 
> Remove mox
> https://review.openstack.org/#/c/532361/
> Champion: Sean McGinnis (unless someone else steps up)
> 
> Ensure pagination links
> https://review.openstack.org/#/c/532627/
> Champion: Monty Taylor
> 
> 2 more goals are about to be proposed:
> 
> Enable mutable configuration
> Champion: ChangBo Guo
> 
> Cold upgrades capabilities
> Champion: Masayuki Igawa
> 
> 
> Thanks everyone for your participation,
> We hope to make a vote within the next 2 weeks so we can prepare the
> PTG accordingly.
> 
> On Tue, Jan 9, 2018 at 10:37 AM, Emilien Macchi  
> wrote:
> > As promised, let's continue the discussion and move things forward.
> >
> > This morning Thierry brought the discussion during the TC office hour
> > (that I couldn't attend due to timezone):
> > 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t2018-01-09T09:18:33
> >
> > Some outputs:
> >
> > - One goal has been proposed so far.
> >
> > Right now, we only have one goal proposal: Storyboard Migration. There
> > are some concerns about the ability to achieve this goal in 6 months.
> > At that point, we think it would be great to postpone the goal to S
> > cycle, continue the progress (kudos to Kendall) and fine other goals
> > for Rocky.
> >
> >
> > - We still have a good backlog of goals, we're just missing champions.
> >
> > https://etherpad.openstack.org/p/community-goals
> >
> > Chris brought up "pagination links in collection resources" in api-wg
> > guidelines theme. He said in the past this goal was more a "should"
> > than a "must".
> > Thierry mentioned privsep migration (done in Nova and Zun). (action,
> > ping mikal about it).
> > Thierry also brought up the version discovery (proposed by Monty).
> > Flavio proposed mutable configuration, which might be very useful for 
> operators.
> > He also mentioned that IPv6 support goal shouldn't be that far from
> > done, but we're currently lacking in CI jobs that test IPv6
> > deployments (question for infra/QA, can we maybe document the gap so
> > we can run some gate jobs on ipv6 ?)
> > (personal note on that one, since TripleO & Puppet OpenStack CI
> > already have IPv6 jobs, we can indeed be confident that it shouldn't
> > be that hard to complete this goal in 6 months, I guess the work needs
> > to happen in the projects layouts).
> > Another interesting goal proposed by Thierry, also useful for
> > operators, is to move more projects to assert:supports-upgrade tag.
> > Thierry said we are probably not that far from this goal, but the
> > major lack is in testing.
> > Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
> > of projects don't use it anymore already).
> >
> > With that said, let's continue the discussion on these goals, see
> > which ones can be actionable and find champions.
> >
> > - Flavio asked how would it be perceived if one cycle wouldn't have at
> > least one community goal.
> >
> > Thierry said we could introduce multi-cycle goals (Storyboard might be
> > a good candidate).
> > Chris and Thierry thought that it would be a bad sign for our
> > community to not have community goals during a cycle, "loss of
> > momentum" eventually.
> >
> >
> > Thanks for reading so far,
> >
> > On Fri, Dec 15, 2017 at 9:07 AM, Emilien 

Re: [openstack-dev] [tc][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Kendall Nelson]

I think this is a great idea!

This would really help with getting more eyes on StoryBoard. I think a lot
of people haven't touched it much in the last year or two and aren't aware
of all of its capabilities at this point and this would be a great way to
get people up to speed.

This use case (cross project efforts) is also what StoryBoard was built for
after all :)

If anyone has questions about StoryBoard or feedback, please join our
channel #storyboard!

Thanks Doug!

-Kendall (diablo_rojo)

On Fri, Jan 12, 2018 at 12:38 PM Doug Hellmann 
wrote:

> Since we are discussing goals for the Rocky cycle, I would like to
> propose a change to the way we track progress on the goals.
>
> We've started to see lots and lots of changes to the goal documents,
> more than anticipated when we designed the system originally. That
> leads to code review churn within the governance repo, and it means
> the goal champions have to wait for the TC to review changes before
> they have complete tracking information published somewhere. We've
> talked about moving the tracking out of git and using an etherpad
> or a wiki page, but I propose that we use storyboard.
>
> Specifically, I think we should create 1 story for each goal, and
> one task for each project within the goal. We can then use a board
> to track progress, with lanes like "New", "Acknowledged", "In
> Progress", "Completed", and "Not Applicable". It would be the
> responsibility of the goal champion to create the board, story, and
> tasks and provide links to the board and story in the goal document
> (so we only need 1 edit after the goal is approved). From that point
> on, teams and goal champions could collaborate on keeping the board
> up to date.
>
> Not all projects are registered in storyboard, yet. Since that
> migration is itself a goal under discussion, I think for now we can
> just associate all tasks with the governance repository.
>
> It doesn't look like changes to a board trigger any sort of
> notifications for the tasks or stories involved, but that's probably
> OK. If we really want notifications we can look at adding them as
> a feature of Storyboard at the board level.
>
> How does this sound as an approach? Does anyone have any reservations
> about using storyboard this way?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [qa][neutron][octavia][horizon][networking-l2gw] Renaming tox_venvlist in Zuul v3 run-tempest

[Paul Belanger]

On Fri, Jan 12, 2018 at 05:13:28PM +0100, Andreas Jaeger wrote:
> The Zuul v3 tox jobs use "tox_envlist" to name the tox environment to
> use, the tempest run-tempest role used "tox_venvlist" with an extra "v"
> in it. This lead to some confusion and a wrong fix, so let's be
> consistent across these jobs.
> 
> I've just pushed changes under the topic tox_envlist to sync these.
> 
> To have working jobs, I needed the usual rename dance: Add the new
> variable, change the job, remove the old one.
> 
> Neutron, octavia, horizon, networking-l2gw team, please review and merge
> the first one quickly.
> 
> https://review.openstack.org/#/q/topic:tox_envlist
> 
++

Agree, in fact it would be good to see what would need to change with our
existing run-tox role and have tempest consume it directly over using its own
tasks for running tox.

__
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] [storyboard] need help figuring out how to use auth with storyboard client

[Jeremy Stanley]

On 2018-01-12 15:57:44 -0500 (-0500), Doug Hellmann wrote:
> The storyboard client docs mention an "access token" [1] as something
> a client needs in order to create stories and make other sorts of
> changes.  They don't explain what that token is or how to get one,
> though.
> 
> Where do I get a token? How long does the token work? Can I safely
> put a token in a configuration file, or do I need to get a new one
> each time I want to do something with the client?

https://docs.openstack.org/infra/storyboard/webapi/v1.html#api
suggests that logging in and going to
https://storyboard.openstack.org/#!/profile/tokens will allow you to
issue one (with up to a 10-year expiration based on my modest
experimentation). I believe this to be the same solution we're using
to grant teh storyboard-its Gerrit plugin to update tasks/stories
from review.openstack.org.
-- 
Jeremy Stanley


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] [tc][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Sean McGinnis]

> >
> > How does this sound as an approach? Does anyone have any reservations
> > about using storyboard this way?
> 
> Sounds like a good idea, and will help to "Eat Our Own Dog Food" (if
> we want Storyboard adopted at some point).

My thoughts as well. This would be a good way to get more people exposed to
storyboard, and a way to get more runtime on storyboard, so when the time comes
to migrate away from launchpad there is a higher comfort level with the tool
and less of a chance for any surprises.

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] [storyboard] need help figuring out how to use auth with storyboard client

[Clark Boylan]

On Fri, Jan 12, 2018, at 12:57 PM, Doug Hellmann wrote:
> The storyboard client docs mention an "access token" [1] as something
> a client needs in order to create stories and make other sorts of
> changes.  They don't explain what that token is or how to get one,
> though.
> 
> Where do I get a token? How long does the token work? Can I safely
> put a token in a configuration file, or do I need to get a new one
> each time I want to do something with the client?
> 
> Doug
> 
> [1] https://docs.openstack.org/infra/python-storyboardclient/usage.html
> 

The storyboard api docs [2] point to this location under your userprofile [3], 
though it seems to not be directly linked to in the storyboard UI. And there 
are docs for managing subsequent user tokens further down in the api docs [4].

I've not used any of this so unsure how accurate it is, but hope this is enough 
to get you going with storyboardclient.

[2] https://docs.openstack.org/infra/storyboard/webapi/v1.html#api
[3] https://storyboard.openstack.org/#!/profile/tokens
[4] https://docs.openstack.org/infra/storyboard/webapi/v1.html#user-tokens

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] [tc][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Paul Belanger]

On Fri, Jan 12, 2018 at 01:11:40PM -0800, Emilien Macchi wrote:
> On Fri, Jan 12, 2018 at 12:37 PM, Doug Hellmann  wrote:
> > Since we are discussing goals for the Rocky cycle, I would like to
> > propose a change to the way we track progress on the goals.
> >
> > We've started to see lots and lots of changes to the goal documents,
> > more than anticipated when we designed the system originally. That
> > leads to code review churn within the governance repo, and it means
> > the goal champions have to wait for the TC to review changes before
> > they have complete tracking information published somewhere. We've
> > talked about moving the tracking out of git and using an etherpad
> > or a wiki page, but I propose that we use storyboard.
> >
> > Specifically, I think we should create 1 story for each goal, and
> > one task for each project within the goal. We can then use a board
> > to track progress, with lanes like "New", "Acknowledged", "In
> > Progress", "Completed", and "Not Applicable". It would be the
> > responsibility of the goal champion to create the board, story, and
> > tasks and provide links to the board and story in the goal document
> > (so we only need 1 edit after the goal is approved). From that point
> > on, teams and goal champions could collaborate on keeping the board
> > up to date.
> >
> > Not all projects are registered in storyboard, yet. Since that
> > migration is itself a goal under discussion, I think for now we can
> > just associate all tasks with the governance repository.
> >
> > It doesn't look like changes to a board trigger any sort of
> > notifications for the tasks or stories involved, but that's probably
> > OK. If we really want notifications we can look at adding them as
> > a feature of Storyboard at the board level.
> >
> > How does this sound as an approach? Does anyone have any reservations
> > about using storyboard this way?
> 
> Sounds like a good idea, and will help to "Eat Our Own Dog Food" (if
> we want Storyboard adopted at some point).
>
Agree, I've seen some downstream teams also do this with trello. If people
would like to try with Storyboard, I don't have any objections.

-Paul

__
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] [tc][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Emilien Macchi]

On Fri, Jan 12, 2018 at 12:37 PM, Doug Hellmann  wrote:
> Since we are discussing goals for the Rocky cycle, I would like to
> propose a change to the way we track progress on the goals.
>
> We've started to see lots and lots of changes to the goal documents,
> more than anticipated when we designed the system originally. That
> leads to code review churn within the governance repo, and it means
> the goal champions have to wait for the TC to review changes before
> they have complete tracking information published somewhere. We've
> talked about moving the tracking out of git and using an etherpad
> or a wiki page, but I propose that we use storyboard.
>
> Specifically, I think we should create 1 story for each goal, and
> one task for each project within the goal. We can then use a board
> to track progress, with lanes like "New", "Acknowledged", "In
> Progress", "Completed", and "Not Applicable". It would be the
> responsibility of the goal champion to create the board, story, and
> tasks and provide links to the board and story in the goal document
> (so we only need 1 edit after the goal is approved). From that point
> on, teams and goal champions could collaborate on keeping the board
> up to date.
>
> Not all projects are registered in storyboard, yet. Since that
> migration is itself a goal under discussion, I think for now we can
> just associate all tasks with the governance repository.
>
> It doesn't look like changes to a board trigger any sort of
> notifications for the tasks or stories involved, but that's probably
> OK. If we really want notifications we can look at adding them as
> a feature of Storyboard at the board level.
>
> How does this sound as an approach? Does anyone have any reservations
> about using storyboard this way?

Sounds like a good idea, and will help to "Eat Our Own Dog Food" (if
we want Storyboard adopted at some point).
-- 
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] Vancouver Summit CFP is open - what’s new

[Lauren Sell]

Hi everyone,

Today, we opened the Call for Presentations 
 for 
the Vancouver Summit , which 
will take place May 21-24. The deadline to submit your proposal is February 8th.

What’s New?
We’re focused on open infrastructure integration. The Summit has evolved over 
the years to cover more than just OpenStack, but we’re making an even bigger 
effort to attract speakers across the open infrastructure ecosystem. In 
addition to OpenStack-related sessions, we’ll be featuring the newest project 
at the Foundation -- Kata Containers -- as well as recruiting many others from 
projects like Ansible, Ceph, Kubernetes, ONAP and many more.

We’ve also organized Tracks around specific problem domains. We encourage you 
to submit proposals covering OpenStack and the “open infrastructure” tools 
you’re using, as well as the integration work needed to address these problem 
domains. We also encourage you to invite peers from other open source 
communities to come speak and collaborate. 

The Tracks are:

CI/CD 
Container Infrastructure 
Edge Computing
HPC / GPU / AI
Open Source Community
Private & Hybrid Cloud 
Public Cloud 
Telecom & NFV

Where previously we had Track Chairs, we now have Programming Committees 

 for each Track, made up of both Members and a Chair (or co-chairs). We’re also 
recruiting members and chairs from many different open source communities 
working in open infrastructure, in addition to the many familiar faces in the 
OpenStack community who will lead the effort. If you’re interested in 
nominating yourself or someone else to be a member of the Summit Programming 
Committee for a specific Track, please fill out the nomination form 
.
 Nominations will close on January 26, 2018.

Again, the deadline to submit proposals 
 is 
February 8, 2018. Please note topic submissions for the OpenStack Forum 
(planning/working sessions with OpenStack devs and operators) will open at a 
later date.

We can’t wait to see you in Vancouver! We’re working hard to make it the best 
Summit yet, and look forward to bringing together different open infrastructure 
communities to solve these hard problems together! 

Want to provide feedback on this process? Please focus discussion on the 
openstack-community mailing list, or contact me or the OpenStack Foundation 
Summit Team directly at sum...@openstack.org.

Thank you,
Lauren





__
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] [storyboard] need help figuring out how to use auth with storyboard client

[Doug Hellmann]

The storyboard client docs mention an "access token" [1] as something
a client needs in order to create stories and make other sorts of
changes.  They don't explain what that token is or how to get one,
though.

Where do I get a token? How long does the token work? Can I safely
put a token in a configuration file, or do I need to get a new one
each time I want to do something with the client?

Doug

[1] https://docs.openstack.org/infra/python-storyboardclient/usage.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] Developer Mailing List Digest January 5-12th

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2018/01/developer-mailing-list-digest-january-5-12th/

Success Bot Says

* e0ne on #openstack-horizon [0]: amotoki runs horizon with django 2.0
* tristianC on #rdo [1]: review.rdoproject.org is now running sf-2.7
* mriedem on #openstack-nova [2]: nova merged alternate hosts support for
  server build
* mriedem on #openstack-nova [3]: After a week of problems, finally got
  a volume multiattach test run to actually attach a volume to two instances
  without melting the world. \o/
* zaneb [4]: 14% reduction in Heat memory use in the TripleO gate from fixing
  https://bugs.launchpad.net/heat/+bug/1731349
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2017-12-18.log.html
[1] - http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2017-12-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-12-22.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-05.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2018-01-09.log.html

Community Summaries
===
* Technical Committee Status update [0]
* POST /api-sig/news [1]
* Release countdown [2]
* Nova placement resource provider update [3]
* Keystone team update [4]
* Nova Notification Update [5]
* TC report [6]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126178.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126147.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125996.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126179.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126188.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126025.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126082.html


Community Goals for Rocky
=
So far one goal has been proposed by Kendall Nelson for migrating to
Storyboard. It was agreed to postpone the goal until the S cycle, as it could
take longer than six months to achieve. There is a good backlog of goals [0],
just no champions. It'll be bad for momentum if we have a cycle with no
community wide goal.

[0] - https://etherpad.openstack.org/p/community-goals

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126090.html

PTG Post-lunch Presentations

Feedback received from past PTG session(s) was the lack of situational
awareness and missed opportunity for "global" communication at the event. In
Dublin we'd used the end of the lunch break to for communications that could be
interesting to OpenStack upstream developers and project team members. The idea
is not to find a presentation for everyday, but if we find content that is
generally useful. Interesting topics include general guidance to make the most
of the PTG weeks (good Monday content), development tricks, code review
etiquette, new library features you should adopt, lightning talks (good Friday
content). We'd like to keep the slot under 20 minutes. If you have ideas please
fill out this etherpad [0] in a few weeks.

[0] - https://etherpad.openstack.org/p/dublin-PTG-postlunch

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126102.html


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

[openstack-dev] [tc][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Doug Hellmann]

Since we are discussing goals for the Rocky cycle, I would like to
propose a change to the way we track progress on the goals.

We've started to see lots and lots of changes to the goal documents,
more than anticipated when we designed the system originally. That
leads to code review churn within the governance repo, and it means
the goal champions have to wait for the TC to review changes before
they have complete tracking information published somewhere. We've
talked about moving the tracking out of git and using an etherpad
or a wiki page, but I propose that we use storyboard.

Specifically, I think we should create 1 story for each goal, and
one task for each project within the goal. We can then use a board
to track progress, with lanes like "New", "Acknowledged", "In
Progress", "Completed", and "Not Applicable". It would be the
responsibility of the goal champion to create the board, story, and
tasks and provide links to the board and story in the goal document
(so we only need 1 edit after the goal is approved). From that point
on, teams and goal champions could collaborate on keeping the board
up to date.

Not all projects are registered in storyboard, yet. Since that
migration is itself a goal under discussion, I think for now we can
just associate all tasks with the governance repository.

It doesn't look like changes to a board trigger any sort of
notifications for the tasks or stories involved, but that's probably
OK. If we really want notifications we can look at adding them as
a feature of Storyboard at the board level.

How does this sound as an approach? Does anyone have any reservations
about using storyboard this way?

Doug

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

[openstack-dev] [keystone] Keystone Team Update - Week of 8 January 2018

[Colleen Murphy]

# Keystone Team Update - Week of 8 January 2018

## News

### PTG

We're still brainstorming for the PTG. If you have any topic
proposals, please add them to the etherpad[1]. We'll need to
coordinate with other teams to schedule discussion time on our major
cross-project topics, especially unified limits and policy changes.

### Scope types ambiguity

In the keystone and policy meetings Lance highlighted a number of APIs
that could have different behaviors depending on whether the requester
uses the new system scope or a project scope, for example in the
projects API[2]. Keystone currently doesn't treat these scopes
differently, but we'll be marking and tracking APIs and policies that
need to have this addressed. It's likely that we'll have to help other
projects deal with such ambiguous APIs in the future as well.

[1] https://etherpad.openstack.org/p/keystone-rocky-ptg
[2] 
https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py@32

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 16 changes this week. Many of these were organizational
changes to our api-ref from our Outreachy intern, Suramya, who has
been helping us make our api-ref more consistent. We've also merged
some more of Lance's system-scope changes, though those are still
making their way through the gate.

## Changes that need Attention

Search query: https://goo.gl/h9knRA

There are 79 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Among these are a
number of fixes for the api-ref and several changes to add the
scope_types option to our policies.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Our feature freeze is in two weeks. Please help review changes for
system-scope, application credentials, and unified limits so we can
meet this deadline.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [network-ovn] SNAT traffic in OVN.

[wenran xiao]

Hi all,
Networking-ovn will support distributed floating IP, how about the snat
traffic? Will in every compute node or not?
Any suggestions are welcomed.
__
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] [tc] Community Goals for Rocky

[Tim Bell]

I was reading a tweet from Jean-Daniel and wondering if there would be an 
appropriate community goal regarding support of some of the later API versions 
or whether this would be more of a per-project goal.

https://twitter.com/pilgrimstack/status/951860289141641217

Interesting numbers about customers tools used to talk to our @OpenStack APIs 
and the Keystone v3 compatibility:
- 10% are not KeystoneV3 compatible
- 16% are compatible
- for the rest, the tools documentation has no info

I think Keystone V3 and Glance V2 are the ones with APIs which have moved on 
significantly from the initial implementations and not all projects have been 
keeping up.

Tim

-Original Message-
From: Emilien Macchi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, 12 January 2018 at 16:51
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [all] [tc] Community Goals for Rocky

Here's a quick update before the weekend:

2 goals were proposed to governance:

Remove mox
https://review.openstack.org/#/c/532361/
Champion: Sean McGinnis (unless someone else steps up)

Ensure pagination links
https://review.openstack.org/#/c/532627/
Champion: Monty Taylor

2 more goals are about to be proposed:

Enable mutable configuration
Champion: ChangBo Guo

Cold upgrades capabilities
Champion: Masayuki Igawa


Thanks everyone for your participation,
We hope to make a vote within the next 2 weeks so we can prepare the
PTG accordingly.

On Tue, Jan 9, 2018 at 10:37 AM, Emilien Macchi  wrote:
> As promised, let's continue the discussion and move things forward.
>
> This morning Thierry brought the discussion during the TC office hour
> (that I couldn't attend due to timezone):
> 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t2018-01-09T09:18:33
>
> Some outputs:
>
> - One goal has been proposed so far.
>
> Right now, we only have one goal proposal: Storyboard Migration. There
> are some concerns about the ability to achieve this goal in 6 months.
> At that point, we think it would be great to postpone the goal to S
> cycle, continue the progress (kudos to Kendall) and fine other goals
> for Rocky.
>
>
> - We still have a good backlog of goals, we're just missing champions.
>
> https://etherpad.openstack.org/p/community-goals
>
> Chris brought up "pagination links in collection resources" in api-wg
> guidelines theme. He said in the past this goal was more a "should"
> than a "must".
> Thierry mentioned privsep migration (done in Nova and Zun). (action,
> ping mikal about it).
> Thierry also brought up the version discovery (proposed by Monty).
> Flavio proposed mutable configuration, which might be very useful for 
operators.
> He also mentioned that IPv6 support goal shouldn't be that far from
> done, but we're currently lacking in CI jobs that test IPv6
> deployments (question for infra/QA, can we maybe document the gap so
> we can run some gate jobs on ipv6 ?)
> (personal note on that one, since TripleO & Puppet OpenStack CI
> already have IPv6 jobs, we can indeed be confident that it shouldn't
> be that hard to complete this goal in 6 months, I guess the work needs
> to happen in the projects layouts).
> Another interesting goal proposed by Thierry, also useful for
> operators, is to move more projects to assert:supports-upgrade tag.
> Thierry said we are probably not that far from this goal, but the
> major lack is in testing.
> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
> of projects don't use it anymore already).
>
> With that said, let's continue the discussion on these goals, see
> which ones can be actionable and find champions.
>
> - Flavio asked how would it be perceived if one cycle wouldn't have at
> least one community goal.
>
> Thierry said we could introduce multi-cycle goals (Storyboard might be
> a good candidate).
> Chris and Thierry thought that it would be a bad sign for our
> community to not have community goals during a cycle, "loss of
> momentum" eventually.
>
>
> Thanks for reading so far,
>
> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi  
wrote:
>> On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi  
wrote:
>> [...]
>>> Suggestions are welcome:
>>> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
>>> goal XYZ for Rocky
>>> - on Gerrit in openstack/governance like Kendall did.
>>
>> Just a fresh reminder about Rocky goals.
>> A few questions that we can ask 

[openstack-dev] [qa][neutron][octavia][horizon][networking-l2gw] Renaming tox_venvlist in Zuul v3 run-tempest

[Andreas Jaeger]

The Zuul v3 tox jobs use "tox_envlist" to name the tox environment to
use, the tempest run-tempest role used "tox_venvlist" with an extra "v"
in it. This lead to some confusion and a wrong fix, so let's be
consistent across these jobs.

I've just pushed changes under the topic tox_envlist to sync these.

To have working jobs, I needed the usual rename dance: Add the new
variable, change the job, remove the old one.

Neutron, octavia, horizon, networking-l2gw team, please review and merge
the first one quickly.

https://review.openstack.org/#/q/topic:tox_envlist

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


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

Re: [openstack-dev] [all] [tc] Community Goals for Rocky

[Emilien Macchi]

Here's a quick update before the weekend:

2 goals were proposed to governance:

Remove mox
https://review.openstack.org/#/c/532361/
Champion: Sean McGinnis (unless someone else steps up)

Ensure pagination links
https://review.openstack.org/#/c/532627/
Champion: Monty Taylor

2 more goals are about to be proposed:

Enable mutable configuration
Champion: ChangBo Guo

Cold upgrades capabilities
Champion: Masayuki Igawa


Thanks everyone for your participation,
We hope to make a vote within the next 2 weeks so we can prepare the
PTG accordingly.

On Tue, Jan 9, 2018 at 10:37 AM, Emilien Macchi  wrote:
> As promised, let's continue the discussion and move things forward.
>
> This morning Thierry brought the discussion during the TC office hour
> (that I couldn't attend due to timezone):
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t2018-01-09T09:18:33
>
> Some outputs:
>
> - One goal has been proposed so far.
>
> Right now, we only have one goal proposal: Storyboard Migration. There
> are some concerns about the ability to achieve this goal in 6 months.
> At that point, we think it would be great to postpone the goal to S
> cycle, continue the progress (kudos to Kendall) and fine other goals
> for Rocky.
>
>
> - We still have a good backlog of goals, we're just missing champions.
>
> https://etherpad.openstack.org/p/community-goals
>
> Chris brought up "pagination links in collection resources" in api-wg
> guidelines theme. He said in the past this goal was more a "should"
> than a "must".
> Thierry mentioned privsep migration (done in Nova and Zun). (action,
> ping mikal about it).
> Thierry also brought up the version discovery (proposed by Monty).
> Flavio proposed mutable configuration, which might be very useful for 
> operators.
> He also mentioned that IPv6 support goal shouldn't be that far from
> done, but we're currently lacking in CI jobs that test IPv6
> deployments (question for infra/QA, can we maybe document the gap so
> we can run some gate jobs on ipv6 ?)
> (personal note on that one, since TripleO & Puppet OpenStack CI
> already have IPv6 jobs, we can indeed be confident that it shouldn't
> be that hard to complete this goal in 6 months, I guess the work needs
> to happen in the projects layouts).
> Another interesting goal proposed by Thierry, also useful for
> operators, is to move more projects to assert:supports-upgrade tag.
> Thierry said we are probably not that far from this goal, but the
> major lack is in testing.
> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
> of projects don't use it anymore already).
>
> With that said, let's continue the discussion on these goals, see
> which ones can be actionable and find champions.
>
> - Flavio asked how would it be perceived if one cycle wouldn't have at
> least one community goal.
>
> Thierry said we could introduce multi-cycle goals (Storyboard might be
> a good candidate).
> Chris and Thierry thought that it would be a bad sign for our
> community to not have community goals during a cycle, "loss of
> momentum" eventually.
>
>
> Thanks for reading so far,
>
> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi  wrote:
>> On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi  wrote:
>> [...]
>>> Suggestions are welcome:
>>> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
>>> goal XYZ for Rocky
>>> - on Gerrit in openstack/governance like Kendall did.
>>
>> Just a fresh reminder about Rocky goals.
>> A few questions that we can ask ourselves:
>>
>> 1) What common challenges do we have?
>>
>> e.g. Some projects don't have mutable configuration or some projects
>> aren't tested against IPv6 clouds, etc.
>>
>> 2) Who is willing to drive a community goal (a.k.a. Champion)?
>>
>> note: a Champion is someone who volunteer to drive the goal, but
>> doesn't commit to write the code necessarily. The Champion will
>> communicate with projects PTLs about the goal, and make the liaison if
>> needed.
>>
>> The list of ideas for Community Goals is documented here:
>> https://etherpad.openstack.org/p/community-goals
>>
>> Please be involved and propose some ideas, I'm sure our community has
>> some common goals, right ? :-)
>> Thanks, and happy holidays. I'll follow-up in January of next year.
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [all] [tc] Community Goals for Rocky

[Emilien Macchi]

On Fri, Jan 12, 2018 at 1:27 AM, ChangBo Guo  wrote:
> Yeah, help means  to be the "Champion" for me :-)

That's very cool, if you can write a proposal in governance, similar
to https://review.openstack.org/#/c/532361/ (Example with Sean).

The community will vote on which goals we take for Rocky.

Please let us know if you need any help,
Thanks!

> 2018-01-12 14:22 GMT+08:00 Emilien Macchi :
>>
>> On Thu, Jan 11, 2018 at 9:59 PM, ChangBo Guo  wrote:
>> > I would like to help the goal - enable mutable configuration, would like
>> > to
>> > post a patch for that later.
>>
>> are you interested to be the "Champion" for this goal?
>>
>> >
>> > 2018-01-10 2:37 GMT+08:00 Emilien Macchi :
>> >>
>> >> As promised, let's continue the discussion and move things forward.
>> >>
>> >> This morning Thierry brought the discussion during the TC office hour
>> >> (that I couldn't attend due to timezone):
>> >>
>> >>
>> >> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t2018-01-09T09:18:33
>> >>
>> >> Some outputs:
>> >>
>> >> - One goal has been proposed so far.
>> >>
>> >> Right now, we only have one goal proposal: Storyboard Migration. There
>> >> are some concerns about the ability to achieve this goal in 6 months.
>> >> At that point, we think it would be great to postpone the goal to S
>> >> cycle, continue the progress (kudos to Kendall) and fine other goals
>> >> for Rocky.
>> >>
>> >>
>> >> - We still have a good backlog of goals, we're just missing champions.
>> >>
>> >> https://etherpad.openstack.org/p/community-goals
>> >>
>> >> Chris brought up "pagination links in collection resources" in api-wg
>> >> guidelines theme. He said in the past this goal was more a "should"
>> >> than a "must".
>> >> Thierry mentioned privsep migration (done in Nova and Zun). (action,
>> >> ping mikal about it).
>> >> Thierry also brought up the version discovery (proposed by Monty).
>> >> Flavio proposed mutable configuration, which might be very useful for
>> >> operators.
>> >> He also mentioned that IPv6 support goal shouldn't be that far from
>> >> done, but we're currently lacking in CI jobs that test IPv6
>> >> deployments (question for infra/QA, can we maybe document the gap so
>> >> we can run some gate jobs on ipv6 ?)
>> >> (personal note on that one, since TripleO & Puppet OpenStack CI
>> >> already have IPv6 jobs, we can indeed be confident that it shouldn't
>> >> be that hard to complete this goal in 6 months, I guess the work needs
>> >> to happen in the projects layouts).
>> >> Another interesting goal proposed by Thierry, also useful for
>> >> operators, is to move more projects to assert:supports-upgrade tag.
>> >> Thierry said we are probably not that far from this goal, but the
>> >> major lack is in testing.
>> >> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
>> >> of projects don't use it anymore already).
>> >>
>> >> With that said, let's continue the discussion on these goals, see
>> >> which ones can be actionable and find champions.
>> >>
>> >> - Flavio asked how would it be perceived if one cycle wouldn't have at
>> >> least one community goal.
>> >>
>> >> Thierry said we could introduce multi-cycle goals (Storyboard might be
>> >> a good candidate).
>> >> Chris and Thierry thought that it would be a bad sign for our
>> >> community to not have community goals during a cycle, "loss of
>> >> momentum" eventually.
>> >>
>> >>
>> >> Thanks for reading so far,
>> >>
>> >> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi 
>> >> wrote:
>> >> > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi 
>> >> > wrote:
>> >> > [...]
>> >> >> Suggestions are welcome:
>> >> >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
>> >> >> goal XYZ for Rocky
>> >> >> - on Gerrit in openstack/governance like Kendall did.
>> >> >
>> >> > Just a fresh reminder about Rocky goals.
>> >> > A few questions that we can ask ourselves:
>> >> >
>> >> > 1) What common challenges do we have?
>> >> >
>> >> > e.g. Some projects don't have mutable configuration or some projects
>> >> > aren't tested against IPv6 clouds, etc.
>> >> >
>> >> > 2) Who is willing to drive a community goal (a.k.a. Champion)?
>> >> >
>> >> > note: a Champion is someone who volunteer to drive the goal, but
>> >> > doesn't commit to write the code necessarily. The Champion will
>> >> > communicate with projects PTLs about the goal, and make the liaison
>> >> > if
>> >> > needed.
>> >> >
>> >> > The list of ideas for Community Goals is documented here:
>> >> > https://etherpad.openstack.org/p/community-goals
>> >> >
>> >> > Please be involved and propose some ideas, I'm sure our community has
>> >> > some common goals, right ? :-)
>> >> > Thanks, and happy holidays. I'll follow-up in January of next year.
>> >> > --
>> >> > Emilien Macchi
>> >>
>> >>
>> >>
>> >> --
>> >> Emilien Macchi

[openstack-dev] [horizon][trunk][ngdetails] Trunk admin panel and changes related to ngdetails patches

[Lajos Katona]

Hi Horizon Team

I read the meeting log 
(http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-01-10-20.00.log.html) 
and if I understand well the proposal is to merge part of the ngdetails 
patches 
(https://review.openstack.org/#/q/topic:bug/1681627+(status:open) ) in 
Queens, and address the remaining issues in Rocky, am I right?


Could you help me to find a way to proceed with the remaining trunk 
related patches which are dependent on the above patches

(https://review.openstack.org/#/q/project:openstack/horizon+status:open+AND+owner:%22Lajos+Katona+%253Clajos.katona%2540ericsson.com%253E%22).

What do you think, shall I remove the dependency for ngdetails fix and 
add TODOs or similar to the code or wait for and help Shu with his work?


Thanks in advance for the help.

Regards
Lajos

__
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.log] JSON logs are missing the request ID

[Doug Hellmann]

Excerpts from Saverio Proto's message of 2018-01-12 09:17:55 +0100:
> > Which service's logs are missing the request_id?
> > 
> If I look at neutron-server logs with my current setup I get two files:
> 
> neutron-server.log
> neutron-server.json
> 
> the standard log file has in all neutron.wsgi lines information like:
> 
>  neutron.wsgi [req-4fda8017-50c7-40eb-9e7b-710e7fba0d01
> 97d349b9499b4bd29c5e167c65ca1fb3 d447c836b6934dfab41a03f1ff96d879 - - -]
> 
> where req-UUID is the request ID, and the other two values are the user
> UUID and the keystone project UUID.
> 
> when I look at the same line in the JSON output this information is missing.
> 
> I am starting neutron-server with the command line option
> --log-config-append=/etc/neutron/logging.neutron-server.conf
> 
> where the conf file looks like
> 
> [loggers]
> keys = root, neutron
> 
> [handlers]
> keys = logfile, jsonfile, null
> 
> [formatters]
> keys = context, json, default
> 
> [logger_root]
> level = WARNING
> handlers = null
> 
> [logger_neutron]
> level = INFO
> handlers = logfile, jsonfile
> qualname = neutron
> 
> [handler_logfile]
> class = handlers.WatchedFileHandler
> args = ('/var/log/neutron/neutron-server.log',)
> formatter = context
> 
> [handler_jsonfile]
> level = INFO
> class = handlers.WatchedFileHandler
> args = ('/var/log/neutron/neutron-server.json',)
> formatter = json
> 
> [handler_null]
> class = logging.NullHandler
> formatter = default
> args = ()
> 
> [formatter_context]
> class = oslo_log.formatters.ContextFormatter
> 
> [formatter_json]
> class = oslo_log.formatters.JSONFormatter
> 
> [formatter_default]
> format = %(message)s
> 
> 
> I had a look at nova-api and I have the same problem. Anyway in my
> Kibana I never so a req-UUID what so ever, so this looks like a problem
> with all the openstack services.
> 
> Is it a problem with my logging configuration ?
> 
> thank you
> 
> Saverio
> 

I don't think this is a configuration problem.

Which version of the oslo.log library do you have installed?

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] [all][tc] Clarifying testing recommendation for interop programs

[Doug Hellmann]

Excerpts from Luigi Toscano's message of 2018-01-12 10:49:55 +0100:
> On Thursday, 11 January 2018 23:52:00 CET Matt Riedemann wrote:
> > On 1/11/2018 10:36 AM, Colleen Murphy wrote:
> > > 1) All trademark-related tests should go in the tempest repo, in
> > > accordance
> > > 
> > > with the original resolution. This would mean that even projects that
> > > have
> > > never had tests in tempest would now have to add at least some of
> > > their
> > > black-box tests to tempest.
> > > 
> > > The value of this option is that centralizes tests used for the Interop
> > > program in a location where interop-minded folks from the QA team can
> > > control them. The downside is that projects that so far have avoided
> > > having a dependency on tempest will now lose some control over the
> > > black-box tests that they use for functional and integration that would
> > > now also be used for trademark certification.
> > > There's also concern for the review bandwidth of the QA team - we can't
> > > expect the QA team to be continually responsible for an ever-growing list
> > > of projects and their trademark tests.
> > 
> > How many tests are we talking about for designate and heat? Half a
> > dozen? A dozen? More?
> > 
> > If it's just a couple of tests per project it doesn't seem terrible to
> > have them live in Tempest so you get the "interop eye" on reviews, as
> > noted in your email. If it's a considerable amount, then option 2 seems
> > the best for the majority of parties.
> 
> I would argue that it does not scale; what if some test is taken out from the 
> interoperability, and others are added? It would mean moving tests from one 
> repository to another, with change of paths. I think that the solution 2, 
> where the repository where a test belong and the functionality of a test are 
> not linked, is better.
> 
> Ciao

How often do the interop test suites change in that way?

Doug

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

[openstack-dev] [nova] [placement] resource providers update 18-02

[Chris Dent]

Resource provider and placement 18-02. Getting a bit more warmed up
here, so should be more stuff from more places.

# Most Important

Completing alternate hosts and exposing the basic nested resource
providers functionality is what matters. We've reached that stage in
the cycle where at least some interesting ideas, inspired by current
work, need to be pushed off to Rocky.

Speaking of Rocky, the etherpad for PTG topics is underway at

https://etherpad.openstack.org/p/nova-ptg-rocky

In typical fashion there's plenty of stuff on there related to
placement already, but there's likely plenty more to talk about. If you
have something, even if it is tentative, add it. The list will get
more structured closer to the PTG.

As we approach the end of the cycle finding and fixing bugs ought to
become the focus.

# What's Changed

Eric gave a nice summary of this week's scheduler meeting in
yesterday's Nova team meeting. It's worth reading:


http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-01-11-14.01.log.html#l-74

# Help Wanted

There are a fair few unstarted bugs related to placement that could do
with some attention. Here's a handy URL: https://goo.gl/TgiPXb

# Main Themes

## Nested Providers

The nested provider work is proceeding along two main courses: getting
the ProviderTree on the nova side gathering and syncing all the
necessary information, and enabling nested provider searching when
requesting /allocation_candidates. Both of these are within the same
topic:

   https://review.openstack.org/#/q/topic:bp/nested-resource-providers

We've identified the need to handle conflicts responses (409) in a more
generic fashion in the ProviderTree. The new plan is, when a conflict
is caused by mismatched generations, reset and reload the entire tree
rather than attempting to resync at a granular level.

# Alternate Hosts

The last piece of the puzzle, changing the RPC interface, is pending:

https://review.openstack.org/#/q/topic:bp/return-alternate-hosts

Some issues with resizes and interaction with the CachingScheduler
have been addressed.

Related to this, exploration has started on limiting the number of
responses that the scheduler will request when requesting hosts (some
of which will become alternates):

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

## Misc Traits, Shared, Etc Cleanups

There's a stack of code that fixes up a lot of things related to
traits, sharing providers, test additions and fixes to those tests. At
the moment the changes are in a bug topic:

https://review.openstack.org/#/q/topic:bug/1702420

# Other

* Extract instance allocation removal code
  https://review.openstack.org/#/c/513041/

* Sending global request ids from nova to placement
  https://review.openstack.org/#/q/topic:bug/1734625

* VGPU suppport
  https://review.openstack.org/#/q/topic:bp/add-support-for-vgpu

* Use traits with ironic
  https://review.openstack.org/#/q/topic:bp/ironic-driver-traits

* Move api schemas to own dir
  https://review.openstack.org/#/c/528629/

* request limit /allocation_candidate WIP
  https://review.openstack.org/#/c/531517/

* Update resources once in update available resources
  https://review.openstack.org/#/c/520024/
  (This ought, when it works, to help address some performance
  concerns with nova making too many requests to placement)

* Fix resource provider delete
  https://review.openstack.org/#/c/529519/

* spec: treat devices as generic resources
  https://review.openstack.org/#/c/497978/
  This is a WIP and will need to move to Rocky

* log options at DEBUG when starting wsgi app
  https://review.openstack.org/#/c/519462/

* Support aggregate affinity filters/weighers
  https://review.openstack.org/#/q/topic:bp/aggregate-affinity
  A rocky targeted improvement to affinity handling

* Move placement body samples in docs to own dir
  https://review.openstack.org/#/c/529998/

* Improved functional test coverage for placement
  https://review.openstack.org/#/q/topic:bp/placement-test-enhancement

* Functional tests for traits api
  https://review.openstack.org/#/c/524094/

* Functional test improvements for resource class
  https://review.openstack.org/#/c/524506/

* annotate loadapp() (for placement wsgi app) as public
  https://review.openstack.org/#/c/526691/

* Remove microversion fallback code from report client
  https://review.openstack.org/#/c/528794/

* Document lack of side-effects in AllocationList.create_all()
  https://review.openstack.org/#/c/530997/

* Fix documentation nits in set_and_clear_allocations
  https://review.openstack.org/#/c/531001/

* WIP: SchedulerReportClient.set_aggregates_for_provider
  https://review.openstack.org/#/c/532995/
  This is likely for rocky as it depends on changing the api for
  aggregates handling on the placement side to accept and provide
  a generation

* Naming update cn to rp (for clarity)
  https://review.openstack.org/#/c/529786/

* Add functional test for two-cell scheduler behaviors
  

[openstack-dev] [tc] Technical Committee Status update, January 12th

[Thierry Carrez]

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker

If you are working on something (or plan to work on something)
governance-related that is not reflected on the tracker yet, please feel
free to add to it !


== Recently-approved changes ==

* Upgrade assertion tags only apply to services [1][2]
* Retired repo: ceilometerclient
* New repo: charm-interface-designate
* Goal updates: magnum, manila

[1] https://review.openstack.org/#/c/528745/
[2] https://review.openstack.org/#/c/531395/

Only significant change beyond repository housekeeping and goal
completion updates this week is the merging of the new wording to limit
upgrade assertion tags to OpenStack "services". This is now reflected in
the corresponding tags:

*
https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html
*
https://governance.openstack.org/tc/reference/tags/assert_supports-accessible-upgrade.html
*
https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html
*
https://governance.openstack.org/tc/reference/tags/assert_supports-zero-downtime-upgrade.html


== Rocky goals ==

Goal proposal season is in full swing in preparation for the start of
the Rocky cycle. Two new goals have already been proposed:

* Remove mox: https://review.openstack.org/532361
* Ensure pagination links: https://review.openstack.org/532627

Emilien started a new thread detailing other candidates:

http://lists.openstack.org/pipermail/openstack-dev/2018-January/126090.html

There are good candidates there, but we need someone willing to champion
them before we can consider them for approval.


== Under discussion ==

The discussion started by Graham Hayes to clarify how the testing of
interoperability programs should be organized in the age of add-on
trademark programs is still going on. The TC is interested in more input
from the Interop WG and the QA team, to select an option that would work
for both those groups. Colleen posted a write-up that is a great
introduction to the topic if you're interested in chiming in:

https://review.openstack.org/521602
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126146.html

Matt Treinish proposed an update to the Python PTI for tests to be
specific and explicit. Wider community input is still needed on that
topic. Please review at:

https://review.openstack.org/519751


== TC member actions for the coming week(s) ==

Looking for a volunteer to drive the proposal to update to the Python
PTI for tests to be specific and explicit to some closure. This likely
involves posting a new thread on the ML to gather wider community input
on the topic.

We'd also like to get to a set of proposed goals to choose from, as the
Rocky cycle will start with master branching a couple of weeks from now.

Finally, we should be thinking about topics that would make good
post-lunch presentations at the PTG in Dublin:

http://lists.openstack.org/pipermail/openstack-dev/2018-January/126102.html


== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on
#openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

For the coming week, I expect continued discussions on the stuck
changes, as well as Rocky goals.

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Luigi Toscano]

On Thursday, 11 January 2018 23:52:00 CET Matt Riedemann wrote:
> On 1/11/2018 10:36 AM, Colleen Murphy wrote:
> > 1) All trademark-related tests should go in the tempest repo, in
> > accordance
> > 
> > with the original resolution. This would mean that even projects that
> > have
> > never had tests in tempest would now have to add at least some of
> > their
> > black-box tests to tempest.
> > 
> > The value of this option is that centralizes tests used for the Interop
> > program in a location where interop-minded folks from the QA team can
> > control them. The downside is that projects that so far have avoided
> > having a dependency on tempest will now lose some control over the
> > black-box tests that they use for functional and integration that would
> > now also be used for trademark certification.
> > There's also concern for the review bandwidth of the QA team - we can't
> > expect the QA team to be continually responsible for an ever-growing list
> > of projects and their trademark tests.
> 
> How many tests are we talking about for designate and heat? Half a
> dozen? A dozen? More?
> 
> If it's just a couple of tests per project it doesn't seem terrible to
> have them live in Tempest so you get the "interop eye" on reviews, as
> noted in your email. If it's a considerable amount, then option 2 seems
> the best for the majority of parties.

I would argue that it does not scale; what if some test is taken out from the 
interoperability, and others are added? It would mean moving tests from one 
repository to another, with change of paths. I think that the solution 2, 
where the repository where a test belong and the functionality of a test are 
not linked, is better.

Ciao
-- 
Luigi



__
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] [tc] Community Goals for Rocky

[ChangBo Guo]

Yeah, help means  to be the "Champion" for me :-)

2018-01-12 14:22 GMT+08:00 Emilien Macchi :

> On Thu, Jan 11, 2018 at 9:59 PM, ChangBo Guo  wrote:
> > I would like to help the goal - enable mutable configuration, would like
> to
> > post a patch for that later.
>
> are you interested to be the "Champion" for this goal?
>
> >
> > 2018-01-10 2:37 GMT+08:00 Emilien Macchi :
> >>
> >> As promised, let's continue the discussion and move things forward.
> >>
> >> This morning Thierry brought the discussion during the TC office hour
> >> (that I couldn't attend due to timezone):
> >>
> >> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/
> latest.log.html#t2018-01-09T09:18:33
> >>
> >> Some outputs:
> >>
> >> - One goal has been proposed so far.
> >>
> >> Right now, we only have one goal proposal: Storyboard Migration. There
> >> are some concerns about the ability to achieve this goal in 6 months.
> >> At that point, we think it would be great to postpone the goal to S
> >> cycle, continue the progress (kudos to Kendall) and fine other goals
> >> for Rocky.
> >>
> >>
> >> - We still have a good backlog of goals, we're just missing champions.
> >>
> >> https://etherpad.openstack.org/p/community-goals
> >>
> >> Chris brought up "pagination links in collection resources" in api-wg
> >> guidelines theme. He said in the past this goal was more a "should"
> >> than a "must".
> >> Thierry mentioned privsep migration (done in Nova and Zun). (action,
> >> ping mikal about it).
> >> Thierry also brought up the version discovery (proposed by Monty).
> >> Flavio proposed mutable configuration, which might be very useful for
> >> operators.
> >> He also mentioned that IPv6 support goal shouldn't be that far from
> >> done, but we're currently lacking in CI jobs that test IPv6
> >> deployments (question for infra/QA, can we maybe document the gap so
> >> we can run some gate jobs on ipv6 ?)
> >> (personal note on that one, since TripleO & Puppet OpenStack CI
> >> already have IPv6 jobs, we can indeed be confident that it shouldn't
> >> be that hard to complete this goal in 6 months, I guess the work needs
> >> to happen in the projects layouts).
> >> Another interesting goal proposed by Thierry, also useful for
> >> operators, is to move more projects to assert:supports-upgrade tag.
> >> Thierry said we are probably not that far from this goal, but the
> >> major lack is in testing.
> >> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
> >> of projects don't use it anymore already).
> >>
> >> With that said, let's continue the discussion on these goals, see
> >> which ones can be actionable and find champions.
> >>
> >> - Flavio asked how would it be perceived if one cycle wouldn't have at
> >> least one community goal.
> >>
> >> Thierry said we could introduce multi-cycle goals (Storyboard might be
> >> a good candidate).
> >> Chris and Thierry thought that it would be a bad sign for our
> >> community to not have community goals during a cycle, "loss of
> >> momentum" eventually.
> >>
> >>
> >> Thanks for reading so far,
> >>
> >> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi 
> >> wrote:
> >> > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi 
> >> > wrote:
> >> > [...]
> >> >> Suggestions are welcome:
> >> >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
> >> >> goal XYZ for Rocky
> >> >> - on Gerrit in openstack/governance like Kendall did.
> >> >
> >> > Just a fresh reminder about Rocky goals.
> >> > A few questions that we can ask ourselves:
> >> >
> >> > 1) What common challenges do we have?
> >> >
> >> > e.g. Some projects don't have mutable configuration or some projects
> >> > aren't tested against IPv6 clouds, etc.
> >> >
> >> > 2) Who is willing to drive a community goal (a.k.a. Champion)?
> >> >
> >> > note: a Champion is someone who volunteer to drive the goal, but
> >> > doesn't commit to write the code necessarily. The Champion will
> >> > communicate with projects PTLs about the goal, and make the liaison if
> >> > needed.
> >> >
> >> > The list of ideas for Community Goals is documented here:
> >> > https://etherpad.openstack.org/p/community-goals
> >> >
> >> > Please be involved and propose some ideas, I'm sure our community has
> >> > some common goals, right ? :-)
> >> > Thanks, and happy holidays. I'll follow-up in January of next year.
> >> > --
> >> > Emilien Macchi
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > ChangBo Guo(gcb)
> > Community Director @EasyStack
> >
> > 

Re: [openstack-dev] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Thierry Carrez]

Emilien Macchi wrote:
> [...]
> This is the list of service projects that don't have the tag yet:
> aodh
> blazar
> cloudkitty
> congress
> dragonflow
> ec2api
> freezer
> karbor
> kuryr
> masakari
> mistral
> monasca
> murano
> octavia
> panko
> searchlight
> senlin
> tacker
> trove
> vitrage
> watcher
> zaqar
> zun
> 
> (I might have miss some, please fix it).

I think that misses magnum, solum (+ rally, cyborg, fuxi and maybe
tricircle). I'm not 100% sure dragonflow would count as a "service" (it
runs within neutron AFAIK).

One way to keep the goal simpler is to focus for this cycle on the main
"openstack" bucket from the OpenStack map[1]. This is where there would
be the most value to operators and users (user-facing services) and it
would represent a great first step.

That would narrow the list down to:

aodh
blazar
ec2api
freezer
karbor
magnum
masakari
mistral
murano
octavia
searchlight
senlin
solum
trove
zaqar
zun
+dragonflow?

[1] https://www.openstack.org/openstack-map

-- 
Thierry Carrez (ttx)

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

[openstack-dev] The OpenStack Magnum service whether to supports Kubernetes Cluster/Bay auto scaling

[chao . xu]

Hi，all

In Pike version, the OpenStack Magnum container service whether to supports 
Kubernetes Cluster/Bay node to auto scaling？
At present, the backend engine Swarm supports Cluster/Bay node auto scaling.


Best Regards





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

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

[Takashi Yamamoto]

On Sat, Dec 16, 2017 at 4:01 AM, Armando M.  wrote:
> Hi neutrinos,
>
> To some of you this email may not come as a surprise.

it was a surprise to me.

>
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being the
> Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core is
> a duty rather than a privilege, and I personally feel like it's way overdue
> for me to recognize on the mailing list that it's the time that I state
> officially my intention to step down due to other commitments.

it seems you have a very high standard.
i suspect many of us should resign if we all follow your standard. :-)

>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing with
> the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [kolla] Re: About maridb 10.1 on kolla

[Jeffrey Zhang]

After using RDO mariadb, i found galera is fallback from galera-25.3.20
to 25.3.16.

I am not sure what's the exact difference between these two version. But
what i found is:

> ‘SAFE TO BOOTSTRAP’ PROTECTION [1]
> Starting with provider version 3.19, Galera has an additional protection
> against attempting to boostrap the cluster using a node that may not
> have been the last node remaining in the cluster prior to cluster
shutdown.

So the question is: it is safe to fallback galera version?


[1]
http://galeracluster.com/documentation-webpages/restartingcluster.html#safe-to-bootstrap-protection

On Fri, Jan 5, 2018 at 1:15 AM, Marcin Juszkiewicz <
marcin.juszkiew...@linaro.org> wrote:

> W dniu 29.12.2017 o 07:58, Jeffrey Zhang pisze:
> > recently, a series patches about mariadb is pushed. Current issue is
> >
> > - using different mariadb binary from different repo ( from percona,
> > Mariadb official, linux distro )
> > - using different version number of mariadb ( 10.0 and 10.1 )
> >
> > To make life easier, some patches are pushed to unify all of these. Here
> > is my thought about this
> >
> > - try to bump to 10.1, which is released long time ago
> > - use mariadb binary provided by linux disto as much as possible
> >
> > So here is plan
> >
> > - trying to upgrade to mariadb 10.1 [0][1]
> > - use mariadb 10.1 provided by RDO on redhat family distro [2]
> > - use mariadb 10.0 provided by UCA on ubuntu
> >   - it is told that, it not work as excepted [3]
> >   - if this does not work. we can upgrade to mariadb 10.1 provides by
> > mariadb official on ubuntu.
> > - use mariadb 10.1 provided by os repo on Debian.
>
> How we are with testing/merging?
>
> For Debian to be deployable we need 529199 in images as rest of changes
> are kolla-ansible and can be cherry-picked before deployment.
>
>
> > [0] https://review.openstack.org/#/c/529505/ - fix kolla-ansible for
> > mariadb 10.1
>
> merged
>
> > [1] https://review.openstack.org/#/c/529199/ - Fix MariaDB bootstrap
> for 10.1 version
> > [2] https://review.openstack.org/#/c/468632/ - Consume RDO packaged
> mariadb version
>
> > [3] https://review.openstack.org/#/c/426953/ - Revert "Removed percona
> > from ubuntu repos"
>
> merged
>
> __
> 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] [oslo][oslo.log] JSON logs are missing the request ID

[Saverio Proto]

> Which service's logs are missing the request_id?
> 
If I look at neutron-server logs with my current setup I get two files:

neutron-server.log
neutron-server.json

the standard log file has in all neutron.wsgi lines information like:

 neutron.wsgi [req-4fda8017-50c7-40eb-9e7b-710e7fba0d01
97d349b9499b4bd29c5e167c65ca1fb3 d447c836b6934dfab41a03f1ff96d879 - - -]

where req-UUID is the request ID, and the other two values are the user
UUID and the keystone project UUID.

when I look at the same line in the JSON output this information is missing.

I am starting neutron-server with the command line option
--log-config-append=/etc/neutron/logging.neutron-server.conf

where the conf file looks like

[loggers]
keys = root, neutron

[handlers]
keys = logfile, jsonfile, null

[formatters]
keys = context, json, default

[logger_root]
level = WARNING
handlers = null

[logger_neutron]
level = INFO
handlers = logfile, jsonfile
qualname = neutron

[handler_logfile]
class = handlers.WatchedFileHandler
args = ('/var/log/neutron/neutron-server.log',)
formatter = context

[handler_jsonfile]
level = INFO
class = handlers.WatchedFileHandler
args = ('/var/log/neutron/neutron-server.json',)
formatter = json

[handler_null]
class = logging.NullHandler
formatter = default
args = ()

[formatter_context]
class = oslo_log.formatters.ContextFormatter

[formatter_json]
class = oslo_log.formatters.JSONFormatter

[formatter_default]
format = %(message)s


I had a look at nova-api and I have the same problem. Anyway in my
Kibana I never so a req-UUID what so ever, so this looks like a problem
with all the openstack services.

Is it a problem with my logging configuration ?

thank you

Saverio





-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
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