[openstack-dev] [stable][kolla] tagging newton EOL

[Jeffrey Zhang]

hi stable team,

Kolla project is ready for Newton EOL.  Since kolla-ansible is split from
kolla since ocata cycle, so there is not newton branch in kolla-ansible.
please make following repo EOL

openstack/kolla

Thanks a lot.

-- 
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] [tripleo] roadmap on containers workflow

[Emilien Macchi]

On Wed, Apr 11, 2018 at 3:38 PM, Steve Baker  wrote:
>
> - If agreed, we'll create a new Ansible role called 
> ansible-role-container-registry
> that for now will deploy exactly what we have in TripleO, without extra
> feature.
>
> +1
>

A bit of progress today, I prototyped an Ansible role for that purpose:
https://github.com/EmilienM/ansible-role-container-registry

The next step is, I'm going to investigate if we can deploy Docker and
Docker Distribution (to deploy the registry v2) via the existing composable
services in THT by using external_deploy_tasks maybe (or another interface).
The idea is really to have the registry ready before actually deploying the
undercloud containers, so we can modify them in the middle (run
container-check in our case).
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] CI / Tempest Sprint 11 Summary

[Matt Young]

Greetings,

The TripleO squads for CI and Tempest have just completed Sprint 11.  The
following is a summary of activities during this sprint.  The newly formed
Tempest Squad has completed its first sprint.  Details on the team
structure can be found in the spec [1].

Sprint 11 Epic (CI Squad): Upgrades
Epic Card: https://trello.com/c/8pbRwBps/549-upstream-upgrade-ci

This is the second sprint that the team focused on CI for upgrades.  We
expect additional sprints will be needed focused on upgrades, and have a
number of backlog tasks remaining as well [2]

We did the following:
* Prune and remove old / irrelevant jobs from CI
* Assess the current state of existing jobs to determine status and issues.
* Ensure the reproducer script enabling the correct branches of
tripleo-upgrade
* Implement “Keystone Only” CI job.  This is a minimal deployment with the
smallest set of services (keystone + deps) in play.
   * tripleo-ci-centos-7-scenario000-multinode-oooq-container-updates
* Consolidate  docker namespaces between docker.io, rdoproject.org


Sprint 11 Epic (Tempest Squad): Containerize Tempest
Epic Card: https://trello.com/c/066JFJjf/537-epic-containerize-tempest


As noted above, this is the first sprint for the newly formed Tempest
Squad.  The work was a combination of the sprint epic and team members’
pre-existing work that is nearing completion.

We did the following:
* Fix tempest plugins upgrade issue (RHOS 10>11>12>13)
* Switch to stestr to run tempest beginning with queens
* Move neutron CLI calls to openstack CLI
* Containerize tempest on featureset027 (UC idempotency)

We made progress on the following, but work remains and continues in Sprint
12
* Refactor validate-tempest CI role for UC and containers (reviews in
flight)
* Updates to ansible-role-openstack-certification playbook & CI jobs that
use it.
* Upstream documentation covering above work

Note:
We have added a new trello board [2] to archive completed sprint cards.
Previously we were archiving (trello operation) the cards, making it
difficult to analyze/search the past.

Ruck and Rover

Each sprint two of the team members assume the roles of Ruck and Rover
(each for half of the sprint).
* Ruck is responsible to monitoring the CI, checking for failures, opening
bugs, participate on meetings, and this is your focal point to any CI
issues.
* Rover is responsible to work on these bugs, fix problems and the rest of
the team are focused on the sprint. For more information about our
structure, check [1]

Ruck & Rover (Sprint 11), Etherpad [4]:
* Arx Cruz (arxcruz)
* Rafael Folco (rfolco)

Two issues in particular where substantial time was spent were:

http://bugs.launchpad.net/bugs/1757556 (SSH timeouts)
https://bugs.launchpad.net/tripleo/+bug/1760189 (AMQP issues)

The full list of bugs open or worked on were:

https://bugs.launchpad.net/tripleo/+bug/1763009
https://bugs.launchpad.net/tripleo/+bug/1762419
https://bugs.launchpad.net/tripleo/+bug/1762351
https://bugs.launchpad.net/tripleo/+bug/1761171
https://bugs.launchpad.net/tripleo/+bug/1760189
https://bugs.launchpad.net/bugs/1757556
https://bugs.launchpad.net/tripleo/+bug/1759868
https://bugs.launchpad.net/tripleo/+bug/1759876
https://bugs.launchpad.net/tripleo/+bug/1759583
https://bugs.launchpad.net/tripleo/+bug/1758143
https://bugs.launchpad.net/tripleo/+bug/1757134
https://bugs.launchpad.net/tripleo/+bug/1755485
https://bugs.launchpad.net/tripleo/+bug/1758932
https://bugs.launchpad.net/tripleo/+bug/1751180

If you have any questions and/or suggestions, please contact us in #tripleo

Thanks,

Matt

[1]
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/ci-team-structure.html
[2]
https://trello.com/b/U1ITy0cu/tripleo-and-rdo-ci?menu=filter=label:upgrades

[3] https://trello.com/b/BjcIIp0f/tripleo-and-rdo-ci-archive
[4] https://review.rdoproject.org/etherpad/p/ruckrover-sprint11
__
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] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Sean McGinnis]

On Fri, Apr 13, 2018 at 02:46:59PM -0500, Sean McGinnis wrote:
> Hello teams,
> 
> I am following up on some recently announced changes regarding governed
> projects and tagging rights. See [1] for background.
> 

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


__
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] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Sean McGinnis]

Hello teams,

I am following up on some recently announced changes regarding governed
projects and tagging rights. See [1] for background.

It was mostly followed before that when a project came under official
governance that all tagging and releases would then move to using the
openstack/releases repo and associated automation. It was not officially stated
until recently that this was one of the steps of coming under governance, so
there were a few projects that became official but that continued to do their
own releases.

We've cleaned up most projects' rights to push tags, but for the ones listed
here we waited:

- rally
- dragflow
- ec2-api
- networking-powervm
- nova-powervm
- yaql

We would like to finish cleaning up the ACLs for these, but I wanted to check
with the teams to make sure there wasn't a reason why these repos had continued
tagging separately. Please let me know, either here or in the
#openstack-release channel, if there is something we are overlooking.

Thanks for your attention.

---
Sean (smcginnis)

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

[openstack-dev] [keystone] Keystone Team Update - Week of 9 April 2018

[Lance Bragstad]

# Keystone Team Update - Week of 9 April 2018

## News

This week was another quiet week with our primary focus being
specification reviews. We did reach consensus on the application
credentials specification [0], which landed on Tuesday. Even though it
hasn't landed yet, there's been a bunch of good discussion on the
cross-project default roles specification, which is shaping up nicely [1].

Keystonemiddleware is now officially VMT managed [2], meaning
keystonemiddleware is treated as more of a first class citizen when
dealing with vulnerabilities. This effort has been underway for over a
year and it finally became official this week.

[0] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html
[1] https://review.openstack.org/#/c/523973/
[2] https://review.openstack.org/#/c/555934/

## Open Specs

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

No new specifications were proposed this week, but there are several
that still need reviews. Specifically default roles [3], unified limits
[4][5] and JWT [6]. Those specifications would really benefit from some
more eyes. If you have questions, let us know in IRC and we can discuss it.

[3] https://review.openstack.org/#/c/523973/
[4] https://review.openstack.org/#/c/540803/
[5] https://review.openstack.org/#/c/549766/
[6] https://review.openstack.org/#/c/541903/

## Recently Merged Changes

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

We merged 6 changes this week. Mainly dealing with PTI changes, updated
pysaml2 requirements, and a bug fix or two.

## Changes that need Attention

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

There are 51 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. Please have a look if you
have time. If you're curious about what to review or have questions
about a change, please stop by #openstack-keystone or check out the
priorities in Trello [7].

[7] https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap

## Bugs

There are a total of 127 bugs open against openstack/keystone, with a
pretty even distribution ranging from High through Undecided. If you see
something that interests you, please don't hesitate to communicate it
with us. We do set aside time every week during office hours to help
wrangle bugs.

Total: 127
High (14): https://bit.ly/2v7yedC
Medium (33): https://bit.ly/2qvb23L
Low (32): https://bit.ly/2JEjoyJ
Wishlist (32): https://bit.ly/2JFGa9c
Undecided (16): https://bit.ly/2qsSjXe

## Milestone Outlook

Next Friday is specification proposal freeze. Our next deadline is June
8th, which is specification freeze. We should be focused on finishing up
our specification reviews so that we can get implementations moving for
the release.

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


## Shout-outs

Big thanks to Gage and Kristi for the work they did to get
keystonemiddleware VMT managed! This took a long time and it easily
could have been dropped. Thanks for pushing this forward!

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

Re: [openstack-dev] [nova] [placement] placement update 18-15

[Jay Pipes]

On 04/13/2018 09:57 AM, Chris Dent wrote:

# Questions

* Is anyone already on the hook to implement the multiple member_of
   support described by this spec ammendment:
   https://review.openstack.org/#/c/555413/ ?


I got this. Should have code up today for it.

Best,
-jay

__
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] Zuul job definitions and the branches attribute

[Clark Boylan]

Hello everyone,

Nova recently discovered that if you use the job.branches attribute in job 
definitions the results may not be as expected, particularly if you are porting 
jobs from openstack-zuul-jobs into your project repos.

The problem is the openstack-zuul-jobs project is "branchless", it only has a 
master branch. This means for jobs defined in that repo to restrict running 
jobs against certain branches it used the job.branches attribute. When ported 
to "branched" repos like Nova this job.branches attribute has a slightly 
different behavior and it applies the config on the current branch to all 
branches matching job.branches.

In the Nova case this meant the stable/queens job definition was being applied 
to the master job definition for the job with the same name. Instead the 
job.branches attribute should be dropped and you should use the per branch job 
definition to control branch specific attributes. If you want to stop running a 
job on a branch delete the job's definition from that branch.

TL;DR if you have job definitions that have a branches attribute like Nova did 
[0], you should consider removing that and use the per branch definitions to 
control where and when jobs run.

[0] 
https://git.openstack.org/cgit/openstack/nova/tree/.zuul.yaml?id=cb6c8ca1a7a5abc4d0079e285f877c18c49acaf2#n99

If you have any questions feel free to reach out to the infra team either here 
or on IRC.

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-dev] [neutron] [release]

[Miguel Lavalle]

Hi everybody,

This message is to announce that effective now Akihiro Amotoki has accepted
to be the new Neutron liaison with the Release team. As such, Akihiro will
be responsible for coordinating the releases of Neutron project and the
Neutron Stadium projects, starting with the upcoming Rocky-1 release

I also want to take this opportunity to thank Armando Migliaccio for the
support he has provided over the past few cycles releasing Neutron to the
community. This is only a tiny fraction of the many great contributions
that Armando has made to OpenStack over many years. Thank you and good luck!


Best regards

Miguel
__
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] Recap of Python 3 testing session at PTG

[Thiago da Silva]

On Fri, Apr 13, 2018 at 9:37 AM, Victor Stinner  wrote:

> 2018-04-13 15:07 GMT+02:00 Thomas Goirand :
> > BTW, any progress on upstream Swift WRT Py3 support?
>
> There is a voting Python 3.4 gate which runs 902 unit tests. The
> Python 2.7 gate runs 5,902 unit tests. I compute that 15% of unit
> tests pass on Python 3.4.
>
> I tested locally with Python 3.5 (tox -e py35): 876 tests pass on
> Python 3.5, 57 skipped and 1 failure:
> "FAIL: test_get_logger_sysloghandler_plumbing
> (test.unit.common.test_utils.TestUtils)"
>
There's been some continued effort to port Swift to py3. Our current goal
has been to focus on running the proxy under py3, this way we could start
also running Swift's functional test. Once proxy server and unit/functional
tests have been ported, we could shift focus to account, container, object
servers and finally to background daemons. So yes, there's still a lot of
work to do, but we are making progress.

Thiago

>
> Victor
>
> __
> 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] [Mistral]I think Mistral need K8S action

[Dougal Matthews]

On 13 April 2018 at 05:47, Renat Akhmerov  wrote:

> Hi,
>
> I completely agree with you that having such an action would be useful.
> However, I don’t think this kind of action should be provided by Mistral
> out of the box. Actions and triggers are integration pieces for Mistral and
> are natively external to Mistral code base. In other words, this action can
> be implemented anywhere and plugged into a concrete Mistral installation
> where needed.
>
> As a home for this action I’d propose 'mistral-extra’ repo where we are
> planning to move OpenStack actions and some more.
> Also, if you’d like to contribute you’re very welcome.
>

I would recommend developing actions for K8s somewhere externally, then
when mistral-extra is ready we can move them over. This is the approach
that I took for the Ansible actions[1] and they will likely be one of the
first additions to mistral-extra.

[1]: https://github.com/d0ugal/mistral-ansible-actions



>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> On 13 Apr 2018, 09:18 +0700, 홍선군 , wrote:
>
> Hello  Mistral team.
>
> I'm doing some work on the K8S but I observed that there is only Docker's
> action in Mistral.
>
> I would like to ask Mistral Team, why there is no K8S action in the
> mistral.
>
> I think it would be useful in Mistral.
>
> If you feel it's necessary, could I add K8S action to mistral?
>
>
>
> Regards,
>
> Xian Jun Hong
>
>
> __
> 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] [nova] Rocky forum topics brainstorming

[melanie witt]

+openstack-operators (apologies that I forgot to add originally)

On Mon, 9 Apr 2018 10:09:12 -0700, Melanie Witt wrote:

Hey everyone,

Let's collect forum topic brainstorming ideas for the Forum sessions in
Vancouver in this etherpad [0]. Once we've brainstormed, we'll select
and submit our topic proposals for consideration at the end of this
week. The deadline for submissions is Sunday April 15.

Thanks,
-melanie

[0] https://etherpad.openstack.org/p/YVR-nova-brainstorming


Just a reminder that we're collecting forum topic ideas to propose for 
Vancouver and input from operators is especially important. Please add 
your topics and/or comments to the etherpad [0] and we'll submit 
proposals before the Sunday deadline.


Thanks all,
-melanie




__
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] Removing networking-mlnx from Debian?

[Moshe Levi]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Friday, April 13, 2018 3:08 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] Removing networking-mlnx from Debian?
> 
> On 2018-04-13 13:49:47 +0200 (+0200), Thomas Goirand wrote:
> > Is networking-mlnx actively maintained? It doesn't look like it to me,
> > there's still no Queens release.
> 
> It looks like they were merging changes to master and backporting to
> stable/queens as recently as three weeks ago, but I agree they don't seem
> to have tagged their 9.0.0 release yet. They're not part of any official 
> project
> though, so it's hard to guess what their release timeframe might be.
> 
> > It also fails to build in Debian, with apparently no Python 3 support.
> [...]
> 
> Right, from what I can see they're not testing Python 3 support for their
> changes, not even in a non-voting capacity.
Yes, How can we add python3 job in zuul for testing it?

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

Re: [openstack-dev] Removing networking-mlnx from Debian?

[Moshe Levi]

Hi Thomas,

Networking-mlnx is still maintained. 
We will fix all the issues next week and I will create a tag for it.  

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: Friday, April 13, 2018 2:50 PM
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] Removing networking-mlnx from Debian?
> 
> Hi,
> 
> Is networking-mlnx actively maintained? It doesn't look like it to me, there's
> still no Queens release. It also fails to build in Debian, with apparently no
> Python 3 support.
> 
> Without any reply from an active maintainer, I'll ask for this package to be
> removed from Debian.
> 
> Please let me know,
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C7cb48464a3b24d0fc10
> e08d5a134b5a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6365
> 92171104919078=BFuUnC5qJWNm0J7WPZtosLJeuww%2BVwc4s%2Bu
> rIaF3jbQ%3D=0
__
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] [cyborg] Initiate the discussion for FPGA reconfigurability

[Jay Pipes]

Hi Li, please do remember to use a [cyborg] topic marker in your subject 
line. (I've added one). Comments inline.


On 04/12/2018 11:08 PM, Li Liu wrote:

Hi Team,

While wrapping up spec for FPGA programmability, I think we still miss 
the reconfigurability part of Accelerators


For instance, in the FPGA case, after the bitstream is loaded, a user 
might still need to tune the clock frequency, VF numbers, do reset, etc.


When you say "user" above, are you referring to a normal unprivileged 
user or are you referring to a privileged user like an admin or MANO system?


I'm not entirely sure why an unprivileged user would need to change the 
clock frequency or VF numbers for the FPGA, so I presume you are 
referring to a privileged user (admin)?


These reconfigurations can be arbitory. Unfortunately, none of the APIs 
we have right can handle them properly.


I suggest having another spec for a couple of new APIs dedicated 
to reconfiguring accelerators.


1. A rest API
2. A driver API


If my presumption from above is correct -- that you are referring to 
privileged users (and not the unprivileged users that are spinning up 
workloads that utilize the FPGA) -- then I believe a non-REST API is 
appropriate. REST APIs are typically more appropriate when trying 
provide a publicly-accessible endpoint for unprivileged users to perform 
actions against something. It's also easier to modify a driver API vs a 
REST API due to not having to be as concerned about backwards 
compatibility and things like microversions.


Best,
-jay

I want to gather more ideas from you guys especially from our vendor 
folks :)




--
Thank you

Regards

Li Liu


__
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] [placement] placement update 18-15

[Chris Dent]

This is an "expand" update, meaning I've searched out new stuff to
add to lists. New stuff is added to the end of lists (of specs and
other).

# Most Important

Forbidden traits are now in the runway (until April 26th). Nested
providers on allocation candidates (and associated changes related
to nested representations) are key to many things. Consumer
generations is actively underway.

# What's Changed

Handling in the report client to fail over when an expected
micorvesrion is not there and a 406 is returned, has been removed.
We now expect placement to be upgraded first and for the report
client to be able to expect a certain minimum version.

The functional test for the report client has moved out of the
placement namespace.

Spec for consumer generations merged. Spec for mirror host
aggregates to placement merged. Error codes for placement API spec
merged.

An #openstack-placement IRC channel has been created. Please join if
you are tracking or working on placement related activity.

# Questions

* Is anyone already on the hook to implement the multiple member_of
  support described by this spec ammendment:
  https://review.openstack.org/#/c/555413/ ?

# Bugs

* Placement related bugs not yet in progress:  https://goo.gl/TgiPXb
14, -1 on last week
* In progress placement bugs: https://goo.gl/vzGGDQ
13, +0 on last week

# Specs

(new(ly discovered) things are added at the end of this list)

Some of these look like they could be abandoned. Others are hanging
around for a long time because it seems we struggle to make progress
on things related to representing complex architectures with nested
providers. Apparently a hard problem.

* https://review.openstack.org/#/c/549067/
   VMware: place instances on resource pool
   (using update_provider_tree)

* https://review.openstack.org/#/c/552924/
  Proposes NUMA topology with RPs

* https://review.openstack.org/#/c/544683/
  Account for host agg allocation ratio in placement

* https://review.openstack.org/#/c/552927/
  Spec for isolating configuration of placement database
  (This has a strong +2 on it but needs one more.)

* https://review.openstack.org/#/c/552105/
  Support default allocation ratios

* https://review.openstack.org/#/c/438640/
  Spec on preemptible servers

* https://review.openstack.org/#/c/556873/
Handle nested providers for allocation candidates

* https://review.openstack.org/#/c/557065/
Proposes Multiple GPU types

* https://review.openstack.org/#/c/555081/
Standardize CPU resource tracking

* https://review.openstack.org/#/c/502306/
Network bandwidth resource provider

* https://review.openstack.org/#/c/509042/
Propose counting quota usage from placement

* https://review.openstack.org/#/c/560174/
  Add history behind nullable project_id and user_id

* https://review.openstack.org/#/c/559466/
  Return resources of entire trees in Placement

* https://review.openstack.org/#/c/560974/
  Numbered request groups use different providers


* Main Themes

## Update Provider Tree

The main body of this work has been merged. There are some tweaks
and cleanups at

https://review.openstack.org/#/q/topic:bp/update-provider-tree

as well as some related work:

* https://review.openstack.org/#/c/560444/
  libvirt using update provider tree

## Nested providers in allocation candidates

Representing nested provides in the response to GET
/allocation_candidates is required to actually make use of all the
topology that update provider tree will report. That work is in
progress at:

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

## Mirror nova host aggregates to placement

This makes it so some kinds of aggregate filtering can be done
"placement side" by mirroring nova host aggregates into placement
aggregates.

 
https://review.openstack.org/#/q/topic:bp/placement-mirror-host-aggregates

## Forbidden Traits

A way of expressing "I'd like resources that do _not_ have trait X".
This is ready for review:

   https://review.openstack.org/#/q/topic:bp/placement-forbidden-traits

(This is in the current runway and already has one +2 across the 4
patches.)

## Consumer Generations

This allows multiple agents to "safely" update allocations for a
single consumer. The spec for this has merged and code is in
progress:

https://review.openstack.org/#/q/topic:bp/add-consumer-generation

We had some extensive discussion in IRC on how to manage data in the
face of three (somewhat conflicting) data models and flows in each
of the microversions associated with PUT /allocations/{consumer_id}.

# Extraction

Small bits of work on extraction continue on the
bp/placement-extract topic:

 https://review.openstack.org/#/q/topic:bp/placement-extract

The spec for optional database handling got some nice support
but needs more attention:

  

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

[Dan Smith]

>> global ironic
>> if ironic is None:
>> ironic = importutils.import_module('ironicclient')

I believe ironic was an early example of a client library we hot-loaded,
and I believe at the time we said this was a pattern we were going to
follow. Personally, I think this makes plenty of sense and I think that
even moving things like the python-libvirt load out to something like
this to avoid hyperv people having to nuke it from requirements makes
sense.

> I have a pretty strong dislike for this mechanism.  For one thing, I'm
> frustrated when I can't use hotkeys to jump to an ironicclient method
> because my IDE doesn't recognize that dynamic import.  I have to go look
> up the symbol some other way (and hope I'm getting the right one).  To
> me (with my bias as a dev rather than a deployer) that's way worse than
> having the 704KB python-ironicclient installed on my machine even though

This seems like a terrible reason to make everyone install ironicclient
(or the z/vm client) on their systems at runtime.

--Dan

__
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] z/VM introducing a new config driveformat

[Dan Smith]

> for the run_validation=False issue, you are right, because z/VM driver
> only support config drive and don't support metadata service ,we made
> bad assumption and took wrong action to disabled the whole ssh check,
> actually according to [1] , we should only disable
> CONF.compute_feature_enabled.metadata_service but keep both
> self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
> order to make config drive test validation take effect, our CI will
> handle that

Why don't you support the metadata service? That's a pretty fundamental
mechanism for nova and openstack. It's the only way you can get a live
copy of metadata, and it's the only way you can get access to device
tags when you hot-attach something. Personally, I think that it's
something that needs to work.

> For the tgz/iso9660 question below, this is because we got wrong info
> from low layer component folks back to 2012 and after discuss with
> some experts again, actually we can create iso9660 in the driver layer
> and pass down to the spawned virtual machine and during startup
> process, the VM itself will mount the iso file and consume it, because
> from linux perspective, either tgz or iso9660 doesn't matter , only
> need some files in order to transfer the information from openstack
> compute node to the spawned VM.  so our action is to change the format
> from tgz to iso9660 and keep consistent to other drivers.

The "iso file" will not be inside the guest, but rather passed to the
guest as a block device, right?

> For the config drive working mechanism question, according to [2] z/VM
> is Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2
> hypervisor, there is no file system in z/VM hypervisor (I omit too
> much detail here) , so we can't do something like linux operation
> system to keep a file as qcow2 image in the host operating system,

I'm not sure what the type-1-ness has to do with this. The hypervisor
doesn't need to support any specific filesystem for this to work. Many
drivers we have in the tree are type-1 (xen, vmware, hyperv, powervm)
and you can argue that KVM is type-1-ish. They support configdrive.

> what we do is use a special file pool to store the config drive and
> during VM init process, we read that file from special device and
> attach to VM as iso9660 format then cloud-init will handle the follow
> up, the cloud-init handle process is identical to other platform

This and the previous mention of this sort of behavior has me
concerned. Are you describing some sort of process that runs when the
instance is starting to initialize its environment, or something that
runs  *inside* the instance and thus functionality that has to exist in
the *image* to work?

--Dan

__
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] Recap of Python 3 testing session at PTG

[Victor Stinner]

2018-04-13 15:07 GMT+02:00 Thomas Goirand :
> BTW, any progress on upstream Swift WRT Py3 support?

There is a voting Python 3.4 gate which runs 902 unit tests. The
Python 2.7 gate runs 5,902 unit tests. I compute that 15% of unit
tests pass on Python 3.4.

I tested locally with Python 3.5 (tox -e py35): 876 tests pass on
Python 3.5, 57 skipped and 1 failure:
"FAIL: test_get_logger_sysloghandler_plumbing
(test.unit.common.test_utils.TestUtils)"

Victor

__
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] Recap of Python 3 testing session at PTG

[Thomas Goirand]

On 04/13/2018 02:48 PM, Thomas Goirand wrote:
> On 03/17/2018 09:34 AM, Emilien Macchi wrote:
>> ## Challenges
>>
>> - Some services aren't fully Python 3
> 
> To my experience switching everything to Py3 in Debian, the only issues
> were:
> 
> - manila-ui
> - networking-mlnx

Of course, I also forgot Swift, which isn't Py3 ready. But that's so
famous that I didn't mention it.

BTW, any progress on upstream Swift WRT Py3 support?

Cheers,

Thomas Goirand (zigo)

__
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] Recap of Python 3 testing session at PTG

[Victor Stinner]

2018-04-13 14:48 GMT+02:00 Thomas Goirand :
> On 03/17/2018 09:34 AM, Emilien Macchi wrote:
>> ## Challenges
>>
>> - Some services aren't fully Python 3
>
> To my experience switching everything to Py3 in Debian, the only issues
> were:
>
> - manila-ui
> - networking-mlnx

What about swift?

Victor

__
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] [cinder][nova] RBD multi-attach

[Eric Harney]

On 04/12/2018 10:25 PM, 李俊波 wrote:
> Hello Nova, Cinder developers,
> 
>  
> 
> I would like to ask you a question concerns a Cinder patch [1].
> 
>  
> 
> In this patch, it mentioned that RBD features were incompatible with
> multi-attach, which disabled multi-attach for RBD. I would like to know
> which RBD features that are incompatible?
> 
>  
> 
> In the Bug [2], yao ning also raised this question, and in his envrionment,
> it proved that they did not find ant problems when enable this feature.
> 
>  
> 
> So, I also would like to know which features in ceph will make this feature
> unsafe? 
> 
>  
> 
> [1] https://review.openstack.org/#/c/283695/
> 
> [2] https://bugs.launchpad.net/cinder/+bug/1535815
> 
>  
> 
>  
> 
> Best wishes and Regards
> 
> junboli
> 
>  

Hi,

As noted in the comment in the code [1] -- the exclusive lock feature
must be disabled.  However, this feature is required for RBD mirroring
[2], which will be the basis of Cinder volume replication for RBD.

We are currently prioritizing completing support for replication over
multi-attach for this driver, since there is more demand for that
feature.  After that, we will look more at multi-attach and how to let
deployers choose to enable replication or multi-attach.

[1]
https://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/drivers/rbd.py?id=d1bae7462e3bc#n485

[2]
http://docs.ceph.com/docs/master/rbd/rbd-mirroring/#enable-image-journaling-support

Thanks,
Eric

__
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] Recap of Python 3 testing session at PTG

[Thomas Goirand]

On 03/17/2018 09:34 AM, Emilien Macchi wrote:
> ## Challenges
> 
> - Some services aren't fully Python 3

To my experience switching everything to Py3 in Debian, the only issues
were:

- manila-ui
- networking-mlnx

The Melanox driver will probably be dropped from Debian, so the only
collateral is manila-ui, which is being worked on upstream.

The other one that isn't Py3 ready *in stable* is trove-dashboard. I
have sent backport patches, but they were not approved because of the
stable gate having issues:
https://review.openstack.org/#/c/554680/
https://review.openstack.org/#/c/554681/
https://review.openstack.org/#/c/554682/
https://review.openstack.org/#/c/554683/

The team had plans to make this pass (by temporarily fixing the gate)
but so far, it hasn't happened. On the packaging level, this wont be an
issue for Rocky, and for Queens (which you probably don't care about),
you could just add these patches at the packaging level.

I hope this helps,
Cheers,

Thomas Goirand (zigo)

__
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] Removing networking-mlnx from Debian?

[Jeremy Stanley]

On 2018-04-13 13:49:47 +0200 (+0200), Thomas Goirand wrote:
> Is networking-mlnx actively maintained? It doesn't look like it to
> me, there's still no Queens release.

It looks like they were merging changes to master and backporting to
stable/queens as recently as three weeks ago, but I agree they don't
seem to have tagged their 9.0.0 release yet. They're not part of any
official project though, so it's hard to guess what their release
timeframe might be.

> It also fails to build in Debian, with apparently no Python 3
> support.
[...]

Right, from what I can see they're not testing Python 3 support for
their changes, not even in a non-voting capacity.
-- 
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

[openstack-dev] Removing networking-mlnx from Debian?

[Thomas Goirand]

Hi,

Is networking-mlnx actively maintained? It doesn't look like it to me,
there's still no Queens release. It also fails to build in Debian, with
apparently no Python 3 support.

Without any reply from an active maintainer, I'll ask for this package
to be removed from Debian.

Please let me know,
Cheers,

Thomas Goirand (zigo)

__
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] [Cyborg] Initiate the discussion for FPGA reconfigurability

[Li Liu]

Hi Team,

While wrapping up spec for FPGA programmability, I think we still miss the
reconfigurability part of Accelerators

For instance, in the FPGA case, after the bitstream is loaded, a user might
still need to tune the clock frequency, VF numbers, do reset, etc. These
reconfigurations can be arbitory. Unfortunately, none of the APIs we have
right can handle them properly.

I suggest having another spec for a couple of new APIs dedicated to
reconfiguring accelerators.

1. A rest API
2. A driver API

I want to gather more ideas from you guys especially from our vendor folks
:)
__
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][Deployers] Optional, platform specific, dependancies in requirements.txt

[Chen CH Ji]

https://blueprints.launchpad.net/nova/+spec/optional-requirements-packages
is the one I created
I agree with you tend to think it's a specless blueprint unless someone
want a spec on it

And I saw there are a set of more discussions in the ML so again agree that
let's  watch and see what's really need to be changed then update blueprint

Thanks for your info and support

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eric Fried 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/12/2018 08:43 PM
Subject:Re: [openstack-dev] [Nova][Deployers] Optional, platform
specific, dependancies in requirements.txt



+1

This sounds reasonable to me.  I'm glad the issue was raised, but IMO it
shouldn't derail progress on an approved blueprint with ready code.

Jichen, would you please go ahead and file that blueprint template (no
need to write a spec yet) and link it in a review comment on the bottom
zvm patch so we have a paper trail?  I'm thinking something like
"Consistent platform-specific and optional requirements" -- that leaves
us open to decide *how* we're going to "handle" them.

Thanks,
efried

On 04/12/2018 04:13 AM, Chen CH Ji wrote:
> Thanks for Michael for raising this question and detailed information
> from Clark
>
> As indicated in the mail, xen, vmware etc might already have this kind
> of requirements (and I guess might be more than that) ,
> can we accept z/VM requirements first by following other existing ones
> then next I can create a BP later to indicate this kind
> of change request by referring to Clark's comments and submit patches to
> handle it ? Thanks
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
> Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On
> 4/11/2018 5:09 PM, Michael Still wrote: >Matt Riedemann ---04/12/2018
> 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: >
>
> From: Matt Riedemann 
> To: openstack-dev@lists.openstack.org
> Date: 04/12/2018 08:46 AM
> Subject: Re: [openstack-dev] [Nova][Deployers] Optional, platform
> specific, dependancies in requirements.txt
>
> 
>
>
>
> On 4/11/2018 5:09 PM, Michael Still wrote:
>>
>>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_523387=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=CNosrTHnAR21zOI52fnDRfTqu2zPiAn2oW9f67Qijo4=
 proposes

> adding a z/VM specific
>> dependancy to nova's requirements.txt. When I objected the counter
>> argument is that we have examples of windows specific dependancies
>> (os-win) and powervm specific dependancies in that file already.
>>
>> I think perhaps all three are a mistake and should be removed.
>>
>> My recollection is that for drivers like ironic which may not be
>> deployed by everyone, we have the dependancy documented, and then loaded
>> at runtime by the driver itself instead of adding it to
>> requirements.txt. This is to stop pip for auto-installing the dependancy
>> for anyone who wants to run nova. I had assumed this was at the request
>> of the deployer community.
>>
>> So what do we do with z/VM? Do we clean this up? Or do we now allow
>> dependancies that are only useful to a very small number of deployments
>> into requirements.txt?
>
> As Eric pointed out in the review, this came up when pypowervm was added:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_438119_5_requirements.txt=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=iyKxF-CcGAFmnQs8B7d5u2zwEiJqq8ivETmrgB77PEg=

>
> And you're asking the same questions I did in there, which was, should
> it go into test-requirements.txt like oslo.vmware and
> python-ironicclient, or should it go under [extras], or go into
> requirements.txt like os-win (we also have the xenapi library now too).
>
> I don't really think all of these optional packages should be in
> requirements.txt, but we should just be consistent with whatever we do,
> be that test-requirements.txt or [extras]. I remember caring more about
> this back in my rpm packaging days when we actually tracked what was in
> requirements.txt to base what needed to go into the rpm spec, unlike
> Fedora rpm specs which just zero out requirements.txt and depend on
> their own knowledge of what needs to be 

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks for raising this question, really helpful to the enhancement of our
driver

for the run_validation=False issue, you are right, because z/VM driver only
support config drive and don't support metadata service ,we made bad
assumption
and took wrong action to disabled the whole ssh check, actually according
to [1] , we should only disable
CONF.compute_feature_enabled.metadata_service but keep
both self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
order to make config drive test validation take effect, our CI will handle
that

For the tgz/iso9660 question below, this is because we got wrong info from
low layer component folks back to 2012 and after discuss with some experts
again, actually we can create
iso9660 in the driver layer and pass down to the spawned virtual machine
and during startup process, the VM itself will mount the iso file and
consume it, because from
linux perspective, either tgz or iso9660 doesn't matter , only need some
files in order to transfer the information from openstack compute node to
the spawned VM.
so our action is to change the format from tgz to iso9660 and keep
consistent to other drivers.

For the config drive working mechanism question, according to [2] z/VM is
Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2 hypervisor,
there is no file system in z/VM
hypervisor (I omit too much detail here) , so we can't do something like
linux operation system to keep a file as qcow2 image in the host operating
system, what we do is use a
special file pool to store the config drive and during VM init process, we
read that file from special device and attach to VM as iso9660 format then
cloud-init will handle
the follow up, the cloud-init handle process is identical to other platform

Again, The tgz/iso9660 format is only because tgz format being wrongly
thought, we already have some existing customers and a public openstack
cloud [3] running on LinuxONE (system z) [4]
so config drive of z/VM driver does work and we will modify our code to be
consistent to community in our patch set

please let us know any further question, thanks

[1]
https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L68
[2]https://en.wikipedia.org/wiki/Hypervisor
[3]https://linuxone20.cloud.marist.edu/cloud/
[4]https://www.zdnet.com/article/linuxone-ibms-new-linux-mainframes/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   melanie witt 
To: openstack-dev@lists.openstack.org
Date:   04/13/2018 03:39 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config drive
format



On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote:
> The more I think about it, the more I dislike how the proposed driver
> also "lies" about it using iso9660. That's definitely wrong:
>
>          if CONF.config_drive_format in ['iso9660']:
>              # cloud-init only support iso9660 and vfat, but in z/VM
>              # implementation, can't link a disk to VM as iso9660 before
> it's
>              # boot ,so create a tgz file then send to the VM deployed,
and
>              # during startup process, the tgz file will be extracted and
>              # mounted as iso9660 format then cloud-init is able to
> consume it
>              self._make_tgz(path)
>          else:
>              raise exception.ConfigDriveUnknownFormat(
>                  format=CONF.config_drive_format)

I've asked for more information on the review about how this works -- is
it the z/VM library that extracts the tarball and mounts it as iso9660
before the guest boots or is it expected that the guest is running some
special software that will do that before cloud-init runs, or what?

I also noticed that the z/VM CI has disabled ssh validation of guests by
setting '[validation]run_validation=False' in tempest.conf [0]. This
means we're unable to see the running guest successfully consume the
config drive using this approach. This is the tempest test that verifies
functionality when run_validation=True [1].

I think we need to understand more about how this config drive approach
is supposed to work and be able to see running instances successfully
start up using it in the CI runs.

-melanie

[0]
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tempest_blob_master_tempest_scenario_test-5Fserver-5Fbasic-5Fops.py=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=d9VEfLe0LqlPnfL0F0DwKa5iNpsRfDQKiobInGR02lc=0X5hrQ3zh7vwq7wJJAbox4M_4p0myAC1zehbbxYGNF8=





__
OpenStack Development Mailing List 

[openstack-dev] [tc] Technical Committee Status update, April 13th

[Thierry Carrez]

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of currently-considered changes at:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923


== Recently-approved changes ==

* Official projects should not keep tagging rights [1]
* Add vulnerability:managed tag to keystonemiddleware

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

We just entered election season, which is usually a calmer period when
it comes to changes. The main change this week is a change to new
project requirements setting an early expectation that official projects
will have to drop direct tagging (or branching) rights in their Gerrit
ACLs once they are made official, as those actions will be handled by
the Release Management team through the openstack/releases repository:

https://governance.openstack.org/tc/reference/new-projects-requirements.html


== Election season ==

We are renewing 7 seats from the Technical Committee's 13 seats.
Nomination period runs until EOD, Tuesday April 17th. We only have 5
candidates so far, so if you're interested in tackling OpenStack
governance issues and helping stewarding our community, please consider
running ! You can find details on the process at:

http://lists.openstack.org/pipermail/openstack-dev/2018-April/129260.html


== Voting in progress ==

Having only 3 weeks between TC election and summit makes it difficult to
plan travel and content for that Summit for new members. A TC charter
change was proposed to move the date to 6 weeks before Summit instead.
As all charter changes this one will require at least 9 TC members to
approve it, and it is still short of a couple of votes. Please see:

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

We have a proposal up to update the OpenStack Project Testing Interface
(PTI) info around docs job to match the current state of the art. It is
still short of a couple of votes, but shall be approved soon. Please see:

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


== Under discussion ==

The discussion on the review proposing the split of the kolla-kubernetes
deliverable out of the Kolla team has slowed down this week. Current
consensus seems to be that we should proceed with the proposed change,
if that is the will of the Kolla PTL. The resulting Kolla-K8s (or
Koltes) team might want to decide on their PTL first, though. We also
still need to have a larger discussion around Kolla team governance:
would it be better to go all the way into splitting Kolla from its
deployment mechanisms, and therefore also split Kolla and Kolla-Ansible?
If you have an opinion on that, please chime in on the review or the ML
thread:

https://review.openstack.org/#/c/552531/
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html

The discussion around the proposed Adjutant project team addition also
slowed down as we entered election season. At this point the discussion
is expected to restart after the election, and culminate in a Forum
session in Vancouver where we hope teh various involved patries will be
able to discuss more directly. You can jump in the discussion here:

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


== TC member actions/focus/discussions for the coming week(s) ==

Election season, with encouragements to new leaders to step up and run
for election, followed by a short campaigning period, should be the
focus of next week.

We'll also start preparing the joint Board+TC+UC+Staff meeting by asking
the broader community what topics should be on the agenda.


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

Feel free to add your own office hour conversation starter at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

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