Re: [openstack-dev] [Senlin] [PTL] PTL nomination for Senlin

[YUAN RUIJIE]

+1
Thanks for taking up responsibility to lead the team!!!

2018-01-31 15:58 GMT+08:00 :

>
> Hi all
>
> I'd like to announce my candidacy for the PTL role of Senlin Project for
>
> Rocky cycle.
>
>
> I began to contribute to Senlin project since Mitaka and joined the team as
>
> a core reviewer in 2016.10. It is my pleasure to work with the great team
>
> to make this project better and better, and we will keep moving and look
>
> forward to push Senlin to the next level.
>
>
> As a clustering service, we already can handle some resource types like
> nova
>
> server, heat stack, NFV VDU etc. in past cycles. We also have done a lot of
>
> great works in Queue cycle, for example we finished k8s on Senlin feature's
>
> demo[1][2][3][4]. And there are still many works need to do in future.
>
>
> As a PTL in Rocky cycle, I'd like to focus on the tasks as follows:
>
>
> * Promote k8s on Senlin feature implementation and make it use in NFV
>
>   For example:
>
>   - Add ability to do actions on cluster creation/deletion.
>
>   - Add more network interfaces in drivers.
>
>   - Add kubernetes master profile, use kubeadm to setup one master node.
>
>   - Add kubernetes node profile, auto retrieve kubernetes data from master
>
> cluster.
>
> * Improve health policy to support more useful auto-healing scenario
>
> * Improve LoadBalance policy when use Octavia service driver
>
> * Improve runtime data processing inside Senlin server
>
> * A better support for EDGE-Computing unattended operation use cases[5]
>
> * A stronger team to take the Senlin project to its next level.
>
>
> Again, it is my pleasure to work with such a great team.
>
>
> Thanks
>
> XueFeng Liu
>
>
> [1]https://review.openstack.org/#/c/515321/
>
> [2]https://v.qq.com/x/page/i05125sfonh.html
>
> [3]https://v.qq.com/x/page/t0512vo6tw1.html
>
> [4]https://v.qq.com/x/page/y0512ehqiiq.html
>
> [5]https://www.openstack.org/videos/boston-2017/integration-of-enterprise-
> monitoring-product-senlin-and-mistral-for-auto-healing
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] tripleo-ci-centos-7-scenario00[1-2]-multinode-oooq-container failing

[Wesley Hayutin]

Greetings,

Jobs:
tripleo-ci-centos-7-scenario001-multinode-oooq-container
tripleo-ci-centos-7-scenario002-multinode-oooq-container

The above jobs have been failing in check and gate over the past 24 hours.
The fix is posted here [1] which reverts [2]

Thanks


[1]  https://review.openstack.org/#/c/540543/
[2] https://review.openstack.org/#/c/537375/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][requirements][FFE] Release ovsdbapp 0.9.1

[Matthew Thode]

On 18-02-02 18:02:38, Terry Wilson wrote:
> On Fri, Feb 2, 2018 at 4:30 PM, Matthew Thode  
> wrote:
> > On 18-02-02 15:59:42, Terry Wilson wrote:
> >> ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a
> >> gate-fixing one-line fix (https://review.openstack.org/#/c/537241).
> >> Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once
> >> the package is built?
> >>
> >
> > Is this just for upper-constraints.txt or for global-requirements.txt as
> > well?
> 
> A global-requirements.txt probably makes more sense since 0.9.0
> introduced the issue. I don't see any reason why someone would want to
> install it over 0.9.1. It's literally a one-line difference between
> the two.
> 

It doesn't look like there are any re-releases that'd occur because of
this, so you have my signoff.

http://codesearch.openstack.org/?q=ovsdbapp&i=nope&files=.*requirements.*&repos=

-- 
Matthew Thode (prometheanfire)


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] [release][requirements][FFE] Release ovsdbapp 0.9.1

[Terry Wilson]

On Fri, Feb 2, 2018 at 4:30 PM, Matthew Thode  wrote:
> On 18-02-02 15:59:42, Terry Wilson wrote:
>> ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a
>> gate-fixing one-line fix (https://review.openstack.org/#/c/537241).
>> Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once
>> the package is built?
>>
>
> Is this just for upper-constraints.txt or for global-requirements.txt as
> well?

A global-requirements.txt probably makes more sense since 0.9.0
introduced the issue. I don't see any reason why someone would want to
install it over 0.9.1. It's literally a one-line difference between
the two.

__
OpenStack Development Mailing 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] [Octavia] Rocky Octavia PTL candidacy

[Michael Johnson]

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Rocky. I am currently
the PTL for the Queens release series and would like to continue helping our
team provide network load balancing services for OpenStack.

For those of you that do not know me, I work for Rackspace. Prior to joining
Rackspace I worked for Hewlett-Packard for fifteen years on data center
automation, distributed network systems, embedded system design, and big data.

In the Queens release, we were able to add support for batch member updates,
QoS on the load balancer VIPs, support for Castellan, operator tooling, and
many more enhancements. Beyond that work, we laid the ground work for Rocky.

Looking forward to Rocky I expect the team to finish out some major new
features, such as Active/Active load balancers, UDP protocol support,
provider drivers, flavors, additional tempest tests and additional operator
tooling. I plan to continue working on improving our documentation,
specifically with detailed installation, high availability, and neutron-lbaas
migration guides.

Thank you for your support of Octavia during Queens and your consideration for
Rocky,

Michael Johnson (johnsom)

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

[openstack-dev] [release][ptl] Missing and old intermediary projects

[Sean McGinnis]

Hey all,

Sending this kind of late on a Friday, but I will also include this information
in the weekly countdown email. Just hoping to increase the chances of it
getting seen.

One of our release models is cycle-with-intermediary. With this type of
project, the projects are able to do full releases at any time, with the
commitment "to produce a release near the end of the 6-month development cycle
to be used with projects using the other cycle-based release models".

Ideally, this means these projects will have one or more releases during the
development cycle, and will have a final release leading up to the RC1
deadline. This "final" release is then used to cut a stable/queens branch for
the project.

Well, the RC1 milestone is coming up next Thursday, and we have a few projects
following this release model that have not done any release yet for Queens.
There are other projects that have done a Queens release, but it has been
awhile since those were done, so we're not really sure if they are intended to
be the last official release for Queens.

For those without a release - if nothing is done in time - the release team
will need to force a release off of HEAD to be able to create the stable/queens
branch.

For those with old Queens releases - unless we hear otherwise, we will need to
use the point of that last release to cut stable/queens for those repos.

The release team would rather not be the ones to decide when projects are
released, nor be the ones to decide what becomes stable/queens for these
projects. Please make every effort to release and/or branch these projects
before next Thurday's deadline.

The projects with existing but old Queens releases are:

- swift
- storlets
- monasca / monasca-log-api

The projects that have not yet done a Queens intermediary release are:

- aodh, ceilometer, panko
- heat-translator
- ironic-ui
- monasca-kibana-plugin, monasca-thresh
- murano-agent
- patrole
- tacker-horizon
- tripleo-quickstart
- zun, zun-ui

For some of these, it might make sense to switch to a different release model.
Some of the more mature ones may be better as "independent".

If you have any questions or problems that the release team can help with,
please come see us in the #openstack-release channel.

Thanks,

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

Re: [openstack-dev] [release][requirements][FFE] Release ovsdbapp 0.9.1

[Matthew Thode]

On 18-02-02 15:59:42, Terry Wilson wrote:
> ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a
> gate-fixing one-line fix (https://review.openstack.org/#/c/537241).
> Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once
> the package is built?
> 

Is this just for upper-constraints.txt or for global-requirements.txt as
well?

-- 
Matthew Thode (prometheanfire)


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] [QA] Rocky QA PTL candidacy

[Andrea Frittoli]

Dear all,

I’d like to announce my candidacy [1] for PTL of the QA Program for the
Rocky cycle.

I served as PTL for QA during the Pike and Queens cycles, and I would be
honoured to continue to do so in the next six months.

After a few years working with the OpenStack community, I continue to find
it an exceptional experience and a great opportunity for meeting and working
with great people, learning and innovating.

In the past cycle, we focused on providing good and stable interfaces in
QA projects for everyone to use. Meanwhile, we supported the OpenStack
community in the implementation of the Tempest plugin community goal.

This should mean fewer headaches for everyone with Tempest plugins,
and a bit more time for the QA team to focus on key areas like the gate
stability and bug triage.

Outside of those key areas, my priority always remains serving the
community,
by providing tools, support and advice. There are a few specific topics I
care particularly about for the Rocky cycle:

- Migration to Zuul v3: my key objective is for project teams to be able
  to migrate as effortless as possible, enjoy the benefits of Zuul v3 and
  focus on the things they want to work on.
  To achieve this the QA team will provide a good set of base jobs and
  ansible roles for everyone to re-use.
  During Queens we implemented base devstack and devstack-tempest jobs
  already; next up are multinode support and grenade, which cover most
  of the things that we do in Tempest legacy jobs today.

- Interoperability testing: with the new add-on programs, I expect that
  the teams involved will need prompt support and test reviews from the
  QA team.

- QA beyond the gate: there is a lot of quality engineering happening on
  OpenStack beyond the testing we do in the gate and I strive to ensure
  that those efforts do not happen in isolation. There is opportunity
  for sharing of ideas, tools, experiences - even beyond the OpenStack
  community, through initiatives like OpenLab and OPNVF. A QA SIG may be
  a good forum to make this happen.

- Supporting teams working on the cold upgrade goal along with the goal
  champion.

Thank you!

Andrea Frittoli (andreaf)

[1] https://review.openstack.org/#/c/540542/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][requirements][FFE] Release ovsdbapp 0.9.1

[Terry Wilson]

ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a
gate-fixing one-line fix (https://review.openstack.org/#/c/537241).
Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once
the package is built?

Terry

__
OpenStack Development Mailing 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] Gerrit User Study

[Clark Boylan]

Google is scheduling 60 minute Gerrit user research sessions to help shape the 
future of Gerrit. If you are interested in providing feedback to Gerrit as 
users this is a good opportunity to do so. More info can be found at this 
google group thread 
https://groups.google.com/forum/#!topic/repo-discuss/F_Qv1R_JtOI.

Thank you (and sorry for the spam but Gerrit is an important tool for us, your 
input is valuable),
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] Remembering Shawn Pearce (fwd)

[Jeremy Stanley]

On 2018-02-02 15:52:24 + (+), Adam Spiers wrote:
> Since git and Gerrit are at the heart of our development process,
> I am passing on this very sad news from the git / Gerrit
> communities that Shawn Pearce has passed away after an aggressive
> lung cancer.
[...]

Thanks for sending this along, Adam. Our community owes Shawn (and
his family for that matter) a great debt of gratitude, and not just
for the software he's written. Many are the times when spearce
helped me out personally over IRC with Gerrit-related issues, even
though I'm certain he could have been spending his time on more
interesting endeavors instead. He will be missed.
-- 
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] [neutron][neutron-fwaas] Request for inclusion of bug fixes in RC

[Miguel Lavalle]

Hi,

It was granted earlier today during the Neutron drivers meeting

Cheers

On Fri, Feb 2, 2018 at 12:22 AM, Sridar Kandaswamy (skandasw) <
skand...@cisco.com> wrote:

> Thanks An. The team has been working with An to review and validate these
> changes – we believe we are close to the final version and should be able
> to merge by tomorrow barring any unforeseen surprises. So pls consider
> adding these to the RC as they address some critical issues as outlined
> below.
>
> Thanks
>
> Sridar
>
> On 2/1/18, 10:12 PM, "a...@vn.fujitsu.com"  wrote:
>
> Hi,
>
> I would like to request inclusion of the following patches which
> address bugs found in our testing.
>
> https://review.openstack.org/#/c/539461/
> Addressing: https://bugs.launchpad.net/neutron/+bug/1746404
>
> 'auto_associate_default_firewall_group' got an error when new port is
> created
> We started with a CfgOpt to Disable default FWG on ports. This has
> caused issues with Conntrack so this option is being removed. Also on a
> related note, we were mistakenly applying on other ports - so tightened up
> the validation to ensure that it is a VM port.
>
> And
> https://review.openstack.org/#/c/536234/
> Addressing: https://bugs.launchpad.net/neutron/+bug/1746855
>
> FWaaS V2 failures with Ml2 is Linuxbridge or security group driver is
> iptables_hybrid
> We have failures with Linuxbridge as it is not a supported option and
> if SG uses iptables_hybrid driver - we have seen issues which possibly
> might be addressed [1], but with not enough validation we would like to
> prevent this scenario as well. With more testing and addressing any issues
> we can remove the restriction on SG with iptables_hybrid driver in the R
> release.
>
> [1] https://review.openstack.org/#/c/538154/
>
> Cheers,
> An
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] PTL candidacy

[Ben Nemec]

Hi,

I am submitting my candidacy for Oslo PTL.

I have been an Oslo core since 2014 and although my involvement in the 
project
has at times been limited by other responsibilities, I have always kept 
up on

what is going on in Oslo.

For the Rocky cycle my primary goals would be:

* Continue to maintain the stability and quality of the existing Oslo code.

* Help drive the oslo.config improvements that are underway.

* Encourage new and existing contributors to ensure the long-term health of
  the project.

I am, of course, always open to suggestions on other areas of focus for 
Oslo.


Thanks.

-Ben

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

[openstack-dev] [neutron] cycle highlights for sub-projects

[Armando M.]

Hi neutrinos,

RC1 is fast approaching and this time we can add highlights to the release
files [1]. If I can ask you anyone interested in contributing to the
highlights: please review [2].

Miguel and I will make sure they are compiled correctly. We have time until
Feb 9 to get this done.

Many thanks,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html
[2] https://review.openstack.org/#/c/540476/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Lance Bragstad]

I apologize for using the "baremetal/VM" name, but I wanted to get an
etherpad rolling sooner rather than later [0], since we're likely going
to have to decide on a new name in person. I ported the initial ideas
Colleen mentioned when she started this thread, added links to previous
etherpads from Boston and Denver, and ported some topics from the Boston
etherpads.

Please feel free to add ideas to the list or elaborate on existing ones.
Next week we'll start working through them and figure out what we want
to accomplish for the session. Once we have an official room for the
discussion, I'll add the etherpad to the list in the wiki.

[0] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg


On 02/02/2018 11:10 AM, Zane Bitter wrote:
> On 30/01/18 10:33, Colleen Murphy wrote:
>> At the last PTG we had some time on Monday and Tuesday for
>> cross-project discussions related to baremetal and VM management. We
>> don't currently have that on the schedule for this PTG. There is still
>> some free time available that we can ask for[1]. Should we try to
>> schedule some time for this?
>
> +1, I would definitely attend this too.
>
> - ZB
>
>>  From a keystone perspective, some things we'd like to talk about with
>> the BM/VM teams are:
>>
>> - Unified limits[2]: we now have a basic REST API for registering
>> limits in keystone. Next steps are building out libraries that can
>> consume this API and calculate quota usage and limit allocation, and
>> developing models for quotas in project hierarchies. Input from other
>> projects is essential here.
>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>> problem, and we'd like to guide other projects through the migration.
>> - Application credentials[4]: this main part of this work is largely
>> done, next steps are implementing better access control for it, which
>> is largely just a keystone team problem but we could also use this
>> time for feedback on the implementation so far
>>
>> There's likely some non-keystone-related things that might be at home
>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>> two for these projects? Or perhaps not dedicated days, but
>> planned-in-advance meeting time? Or should we wait and schedule it
>> ad-hoc if we feel like we need it?
>>
>> Colleen
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
>> [2]
>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
>> [3]
>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
>> [4]
>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

[openstack-dev] [oslo.config][castellan][tripleo][ptg]Protecting plain text secrets in configuration files

[Raildo Mascena de Sousa Filho]

Hello folks,

Various regulations and best practices say that passwords and other secret
values should not be stored in plain text in configuration files. There are
“secret store” services to manage values that should be kept secure.
Castellan provides an abstraction API for accessing those services. [1]
In this manner, several different management services can be supported
through a single interface. Then, we will be able to use a Castellan
reference for those secrets and store it using a proper key store backend,
currently Castellan supports Barbican and Vault as a backend, so for this
case, we should use a more light solution, such as Custodia[2], which work
as Secrets-as-a-Service API, working as a lightweight solution compared
with Barbican, besides that, Custodia have some good features like
overlayed encryption backend that can be used to store that secret.

Currently, We have that olso.config interface for pluggable drivers in
progress[3] also the Custodia backend support for Castellan.[4] We are
planning to start the Castellan driver for oslo.config as soon as we have
that interface done.

In the next few weeks, that will be the Dublin PTG and we are planning to
discuss more this topic in the Oslo session[5], so if you are interested in
discussing/contribute for this topic and you will be attending the PTG,
please add yourself as an interested person in the topic. Also, we are
planning to integrate this whole feature with Tripleo in a near feature, so
we are planning to discuss with the Tripleo team a proper way to have that
supported as well.[6]

Finally, if want to be closer to this topic, or if you want to contribute
to this feature, we are having weekly meetings on Tuesday at 1600 UTC on
#openstack-meeting-3, we will be glad to have you working with us.

[1]
https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
[2] https://custodia.readthedocs.io/en/latest/readme.html
[3] https://review.openstack.org/#/c/513844/
[4] https://review.openstack.org/#/c/515190/
[5] https://etherpad.openstack.org/p/oslo-ptg-rocky
[6] https://etherpad.openstack.org/p/tripleo-ptg-rocky
[7] https://etherpad.openstack.org/p/oslo-config-plaintext-secrets

Cheers,

-- 

Raildo mascena

Software Engineer, Identity Managment

Red Hat



TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing 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] [ptg] Dublin PTG schedule up

[Thierry Carrez]

Thierry Carrez wrote:
> The schedule for the Dublin PTG is now posted on the PTG website:
> https://www.openstack.org/ptg#tab_schedule
> 
> I'll post on this thread if anything changes, but it's pretty unlikely
> at this point.

Heads-up: the OpenStack-Helm and Watcher teams agreed to trade their
time slots. That's reflected on the published schedule now.

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] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Zane Bitter]

On 30/01/18 10:33, Colleen Murphy wrote:

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?


+1, I would definitely attend this too.

- ZB


 From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1] 
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[4] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html

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




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

Re: [openstack-dev] Remembering Shawn Pearce (fwd)

[Thierry Carrez]

Monty Taylor wrote:
> On 02/02/2018 09:52 AM, Adam Spiers wrote:
>> Dear Stackers,
>>
>> Since git and Gerrit are at the heart of our development process, I am
>> passing on this very sad news from the git / Gerrit communities that
>> Shawn Pearce has passed away after an aggressive lung cancer.
>>
>> Shawn was founder of Gerrit / JGit / libgit2 / git-gui, and the third
>> most prolific contributor to git itself.
>>
>>     https://gitenterprise.me/2018/01/30/shawn-pearce-a-true-leader/
>>     https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/
>>     https://twitter.com/cdibona/status/957822400518696960
>>    
>> https://public-inbox.org/git/CAP8UFD0aKqT5YXJx9-MqeKCKhOVGxninRf8tv30=hkgvmhg...@mail.gmail.com/T/#mf5c158c68565c1c68c80b6543966ef2cad6d151c
>>
>>    
>> https://groups.google.com/forum/#!topic/repo-discuss/B4P7G1YirdM/discussion
>>
>>
>> He is survived by his wife and two young sons.  A memorial fund has
>> been set up in aid of the boys' education and future:
>>
>> https://gitenterprise.me/2018/01/30/gerrithub-io-donations-to-shawns-family/
>>
>>
>> Thank you Shawn for enriching our lives with your great contributions
>> to the FLOSS community.
> 
> ++
> 
> OpenStack would not be where it is today without Shawn's work.

Indeed.

In open source in general, and in OpenStack in particular, we stand on
the shoulders of a multitude of giants. Shawn will be missed.

-- 
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] Remembering Shawn Pearce (fwd)

[Monty Taylor]

On 02/02/2018 09:52 AM, Adam Spiers wrote:

Dear Stackers,

Since git and Gerrit are at the heart of our development process, I am
passing on this very sad news from the git / Gerrit communities that
Shawn Pearce has passed away after an aggressive lung cancer.

Shawn was founder of Gerrit / JGit / libgit2 / git-gui, and the third
most prolific contributor to git itself.

    https://gitenterprise.me/2018/01/30/shawn-pearce-a-true-leader/
    https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/
    https://twitter.com/cdibona/status/957822400518696960

https://public-inbox.org/git/CAP8UFD0aKqT5YXJx9-MqeKCKhOVGxninRf8tv30=hkgvmhg...@mail.gmail.com/T/#mf5c158c68565c1c68c80b6543966ef2cad6d151c 


https://groups.google.com/forum/#!topic/repo-discuss/B4P7G1YirdM/discussion


He is survived by his wife and two young sons.  A memorial fund has
been set up in aid of the boys' education and future:


https://gitenterprise.me/2018/01/30/gerrithub-io-donations-to-shawns-family/ 



Thank you Shawn for enriching our lives with your great contributions
to the FLOSS community.


++

OpenStack would not be where it is today without Shawn's work.


- Forwarded message from Adam Spiers  -

Date: Fri, 2 Feb 2018 15:12:35 +
From: Adam Spiers 
To: Luca Milanesio 
Subject: Re: Fwd: Remembering Shawn Pearce

Hi Luca, that's such sad news :-(  What an incredible contribution
Shawn made to the community.  In addition to Gerrit, I use git-gui and
gitk regularly, and also my git-deps utility is based on libgit2.  I
had no idea he wrote them all, and many other things.

I will certainly donate and also ensure that the OpenStack community
is aware of the memorial fund.  Thanks a lot for letting me know!

Luca Milanesio  wrote:

Hi Adam,
you probably have received this very sad news :-(
As GerritForge we are actively supporting, contributing and promoting 
the donations to Shawn's Memorial Fund 
(https://www.gofundme.com/shawn-pearce-memorial-fund) and added a 
donation button to GerritHub.io .


Feel free to spread the sad news to the OpenStack community you are in 
touch with.

---
Luca Milanesio
GerritForge
3rd Fl. 207 Regent Street
London W1B 3HH - UK
http://www.gerritforge.com 

l...@gerritforge.com 
Tel:  +44 (0)20 3292 0677
Mob: +44 (0)792 861 7383
Skype: lucamilanesio
http://www.linkedin.com/in/lucamilanesio 



> Begin forwarded message:
> > From: "'Dave Borowitz' via Repo and Gerrit Discussion" 


> Subject: Remembering Shawn Pearce
> Date: 29 January 2018 at 15:15:05 GMT
> To: repo-discuss 
> Reply-To: Dave Borowitz 
> > Dear Gerrit community,
> > I am very saddened to report that Shawn Pearce, long-time Git 
contributor and founder of the Gerrit Code Review project, passed away 
over the weekend after being diagnosed with lung cancer last year. He 
spent his final days comfortably in his home, surrounded by family, 
friends, and colleagues.
> > Shawn was an exceptional software engineer and it is impossible to 
overstate his contributions to the Git ecosystem. He had everything 
from the driving high-level vision to the coding skills to solve any 
complex problem and bring his vision to reality. If you had the 
pleasure of collaborating with him on code reviews, as I know many of 
you did, you've seen first-hand his dedication and commitment to 
quality. You can read more about his contributions in this recent 
interview 
. 

> > In addition to his technical contributions, Shawn truly loved the 
open-source communities he was a part of, and the Gerrit community in 
particular. Growing the Gerrit project from nothing to a global 
community with hundreds of contributors used by some of the world's 
most prominent tech companies is something he was extremely proud of.
> > Please join me in remembering Shawn Pearce and continuing his 
legacy. Feel free to use this thread to share your memories with the 
community Shawn loved.
> > If you are interested, his family has set up GoFundMe page 
 to put towards 
his children's future.

> > Best wishes,
> Dave Borowitz
> > > --
> --
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en 


> > ---
> You received this message because you are subscribed to the Google 
Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, 
send an email to repo-discuss+unsubscr...@googlegroups.com 
.
> For more options, visit https://groups.google.com/d/optout 
.




- End forwarded message -

[openstack-dev] [chef][ptl] PTL candidacy for Rocky

[Samuel Cassiba]

Ohai!

I am seeking to continue as PTL for Chef OpenStack, also known as
openstack-chef.

The tl;dr of my candidacy, which can be read at
https://review.openstack.org/539211 would be:
- The cookbooks are getting better code-wise, but we're not in a good
place people-wise to facilitate handing over the reins just yet.
- CI and pipelines are a focus of this cycle, to aid in delivering
code changes and project visibility.
- For a codebase as complex as openstack-chef, to keep it out of
irrelevance, the barrier to delivering change must be lowered
immensely.

In the last cycle, in addition to delivering Chef 13 support to the
cookbooks (2+ years worth of deprecations!), I successfully negotiated
a delicate, downright awkward, trademark issue on behalf of OpenStack.
The outcome of this was to further increase the visibility of
OpenStack's output in the open source community. The openstack-chef
community also introduced Test Kitchen and InSpec support to the
cookbooks, which enables us to further close the gap between CI and
local testing.

As always, openstack-chef need more reviewers and developers, but
testers especially. Without a consistent feedback loop, the codebase
starts to exist in a quasi-vacuum. As our pace typically keeps us a
release behind, the loop doesn't really close until the "self-LTS"
deployers of OpenStack look to the next release. Without someone to
keep things moving forward, progress stagnates, and, eventually, even
the stalwarts look elsewhere for an upstream.

Thank you for reading.

Delightfully,
Samuel Cassiba

__
OpenStack Development Mailing 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] Remembering Shawn Pearce (fwd)

[Adam Spiers]

Dear Stackers,

Since git and Gerrit are at the heart of our development process, I am
passing on this very sad news from the git / Gerrit communities that
Shawn Pearce has passed away after an aggressive lung cancer.

Shawn was founder of Gerrit / JGit / libgit2 / git-gui, and the third
most prolific contributor to git itself.

   https://gitenterprise.me/2018/01/30/shawn-pearce-a-true-leader/
   https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/
   https://twitter.com/cdibona/status/957822400518696960
   
https://public-inbox.org/git/CAP8UFD0aKqT5YXJx9-MqeKCKhOVGxninRf8tv30=hkgvmhg...@mail.gmail.com/T/#mf5c158c68565c1c68c80b6543966ef2cad6d151c
   https://groups.google.com/forum/#!topic/repo-discuss/B4P7G1YirdM/discussion

He is survived by his wife and two young sons.  A memorial fund has
been set up in aid of the boys' education and future:

   https://gitenterprise.me/2018/01/30/gerrithub-io-donations-to-shawns-family/

Thank you Shawn for enriching our lives with your great contributions
to the FLOSS community.

- Forwarded message from Adam Spiers  -

Date: Fri, 2 Feb 2018 15:12:35 +
From: Adam Spiers 
To: Luca Milanesio 
Subject: Re: Fwd: Remembering Shawn Pearce

Hi Luca, that's such sad news :-(  What an incredible contribution
Shawn made to the community.  In addition to Gerrit, I use git-gui and
gitk regularly, and also my git-deps utility is based on libgit2.  I
had no idea he wrote them all, and many other things.

I will certainly donate and also ensure that the OpenStack community
is aware of the memorial fund.  Thanks a lot for letting me know!

Luca Milanesio  wrote:

Hi Adam,
you probably have received this very sad news :-(
As GerritForge we are actively supporting, contributing and promoting the donations 
to Shawn's Memorial Fund (https://www.gofundme.com/shawn-pearce-memorial-fund) and 
added a donation button to GerritHub.io .

Feel free to spread the sad news to the OpenStack community you are in touch 
with.
---
Luca Milanesio
GerritForge
3rd Fl. 207 Regent Street
London W1B 3HH - UK
http://www.gerritforge.com 

l...@gerritforge.com 
Tel:  +44 (0)20 3292 0677
Mob: +44 (0)792 861 7383
Skype: lucamilanesio
http://www.linkedin.com/in/lucamilanesio 


> Begin forwarded message:
> 
> From: "'Dave Borowitz' via Repo and Gerrit Discussion" 

> Subject: Remembering Shawn Pearce
> Date: 29 January 2018 at 15:15:05 GMT
> To: repo-discuss 
> Reply-To: Dave Borowitz 
> 
> Dear Gerrit community,
> 
> I am very saddened to report that Shawn Pearce, long-time Git contributor and founder of the Gerrit Code Review project, passed away over the weekend after being diagnosed with lung cancer last year. He spent his final days comfortably in his home, surrounded by family, friends, and colleagues.
> 
> Shawn was an exceptional software engineer and it is impossible to overstate his contributions to the Git ecosystem. He had everything from the driving high-level vision to the coding skills to solve any complex problem and bring his vision to reality. If you had the pleasure of collaborating with him on code reviews, as I know many of you did, you've seen first-hand his dedication and commitment to quality. You can read more about his contributions in this recent interview .
> 
> In addition to his technical contributions, Shawn truly loved the open-source communities he was a part of, and the Gerrit community in particular. Growing the Gerrit project from nothing to a global community with hundreds of contributors used by some of the world's most prominent tech companies is something he was extremely proud of.
> 
> Please join me in remembering Shawn Pearce and continuing his legacy. Feel free to use this thread to share your memories with the community Shawn loved.
> 
> If you are interested, his family has set up GoFundMe page  to put towards his children's future.
> 
> Best wishes,

> Dave Borowitz
> 
> 
> --

> --
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en 

> 
> ---

> You received this message because you are subscribed to the Google Groups "Repo 
and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to 
repo-discuss+unsubscr...@googlegroups.com 
.
> For more options, visit https://groups.google.com/d/optout 
.



- End forwarded message -

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje

[openstack-dev] [monasca] Contribution from T-Systems

[Bedyk, Witold]

Hi Yuan,

Thanks for reaching out to us in the team meeting. I'm happy to hear you want 
to contribute your changes to the project. You can find our contribution 
guidelines here [1]. The general OpenStack Developer's Guide is here [2].
Which components/topics are you interested in, in terms of contribution? Also 
feature requests or improvement proposals are very welcome.

As you have probably noticed we will be planning the work for the next release 
during the Project Teams Gathering in Dublin end of this month [3, 4]. It's a 
perfect opportunity to engage in the project.

Best regards
Witek

[1] https://docs.openstack.org/monasca-api/latest/contributor/index.html
[2] https://docs.openstack.org/infra/manual/developers.html
[3] https://www.openstack.org/ptg
[4] https://etherpad.openstack.org/p/monasca-ptg-rocky

__
OpenStack Development Mailing 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] [nova] Cleaning databases before running a major upgrade or for maintenance purposes.

[Carlos Camacho Gonzalez]

Hi!

I'll like to raise a question related to "How to clean Nova databases
before running upgrades"
We want to check that Nova databases (nova, nova_api, nova_cell0,
nova_placement) are in good shape before running upgrade, we know that
there is some effort to "purge the deleted instances" but no patches yet
for that.

In general, how can I know we have cleaned all Nova DBs? This can be i.e.
for maintenance purposes or for checking it before the major upgrade.

Currently the command we run is:
   nova-manage db archive_deleted_rows --max_rows 100 --until-complete
Still, the archived rows are stored in shadow tables so we still have a big
DB, and there is some specs[1] to remove them but nothing landed/usable.

[1]: https://blueprints.launchpad.net/nova/+spec/purge-deleted-instances-cmd

Thanks,
Carlos
__
OpenStack Development Mailing 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-05

[Chris Dent]

Here's resource provider and placement update 18-05. 18-04 was skipped
on account of illness.

# Most Important

Feature freeze has come and gone, RC1 is next week. This means that
finding bugs and, where relevant, reporting them with a tag of
'queens-rc-potential' is top priority.

The PTG is coming up at the end of this month. If you have topics for
discussion that are not already on the etherpad add them:

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

I wrote a blog post to gather some thinking (and links) about
preparing to extract placement from nova (or at least ease the path
when it does eventually happen):

https://anticdent.org/placement-extraction.html

It's probably time to start writing specs for some of the things we
know will be a big deal with placement in Rocky. Eric has started with
a spec that covers the ProviderTree work. Much of that work is already
done, but never had a spec in the first place:

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

I'm on the hook to create a spec for enabling generation handling when
associating aggregates. If there are others, getting them started
before the PTG can help to make the time at the PTG more effective.

# What's Changed

A limit is now passed to /allocation_candidates to ensure that we
don't cause out of memory errors in big empty clouds.

Traits expressed as 'required' in flavor extra specs are passed in
requests to placement and /allocation_candidates accepts the the
required parameter.

More, but not yet all, requests from nova to placement include the
global request id.

Some, but not all, of the ProviderTree functionality has merged.

The full stack of Alternate Hosts is now merged.

The ironic driver now manages traits.

At least some support for VGPU merged. Not clear what this means for
end users.

# Help Wanted

Testing, Testing, Testing.

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

We've not yet identified the new themes, other than to know that
Nested remains a big deal.

## Nested Resource Providers

The work to get nested providers represented in the
/allocation_candidates did not complete before feature freeze. It
remains in progresss at


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

There's been a lot of discussion in IRC about the sometimes differing
goals on how people want NRP to work. One example is at:


http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-29.log.html#t2018-01-29T15:01:24

There's an email thread related to that discussion:

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

I think we'll be doing ourselves a favor if we can work to satisfy concrete
use cases and then generalize from that.

The related provider tree work is now under its own topic:

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

# Other

Plenty of these are bugs or fairly trivial and/or non-feature fixes.

* doc: mark the max microversions for queens
  https://review.openstack.org/#/c/539978/

* [Placement] Invalid query parameter could lead to HTTP 500
  https://review.openstack.org/#/c/539408/

* [placement] use simple FaultWrapper
  https://review.openstack.org/#/c/533752/

* Ensure resource classes correctly
  https://review.openstack.org/#/c/539738/

* Avoid inventory DELETE API (no conflict detection)
  https://review.openstack.org/#/c/539712/

* Do not normalize allocation ratios
  https://review.openstack.org/#/c/532924/

* 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

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

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

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

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

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

[openstack-dev] [tripleo] FFE - Feuture Freeze Exception request for Routed Spine and Leaf Deployment

[Harald Jensås]

Requesting: 
  Feuture Freeze Exception request for Routed Spine and Leaf Deployment

Blueprints:
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
ironic-inspector
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
deployment

All external dependencies for Routed Spine and Leaf Deployement have
finally landed. (Except puppet module changes.)


Pros


This delivers a feature that has been requested since the Kilo release.
It makes TripleO more viable in large deployments as well as in edge
use cases where openstack services are not deployed in one datacenter.

The core piece in this is the neutron segments service_plugin. This has
been around since newton. Most of the instack-undercloud patches were
first proposed during ocata.

The major change is in the undercloud. In tripleo-heat-templates we
need just a small change to ensure we get ip addresses allocated from
neutron when segments service plug-in is enabled in neutron. The
overcloud configuration stays the same, we already do have users
deploying routed networks in the isolated networks using composable
networks so we know it works.


Risks
=

I see little risk introducing a regression to current functionality
with these changes. The major part of the undercloud patches has been
around for a long time and passing CI. 

The format of undercloud.conf is changed, options are deprecated and
new options are added to enable multiple control plane subnets/l2-
segments to be defined. All options are properly deprectated, so
using a configuration file from pike will still work.



=
The list of patches that need to land
=

instack-undercloud
--

* Tripleo routed networks ironic inspector, and Undercloud
  https://review.openstack.org/#/c/437544/
* Move ctlplane network/subnet setup to python
  https://review.openstack.org/533364
* Update config to use per network groups
  https://review.openstack.org/533365
* Update validations to validate all subnets
  https://review.openstack.org/533366
* Add support for multiple inspection subnets
  https://review.openstack.org/533367
* Create static routes for remote subnets
  https://review.openstack.org/533368
* Add per subnet network cidr nat rules
  https://review.openstack.org/533369
* Add per subnet masquerading
  https://review.openstack.org/533370
* Install and enable neutron baremetal mech plugin
  https://review.openstack.org/537830

tripleo-heat-templates
--

* Add subnet property to ctlplane network for server resources
  https://review.openstack.org/473817 

tripleo-docs


* Documentation - TripleO routed-spine-and-leaf
  https://review.openstack.org/#/c/539939/ 

puppet-neutron
--

* Add networking-baremetal ml2 plug-in
  https://review.openstack.org/537826 
* Add networking-baremetal - ironic-neutron-agent
  https://review.openstack.org/539405


-- 
|Harald Jensås    
|  hjensas:irc

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

Re: [openstack-dev] [release] Release countdown for week R-3, February 3 - 9

[Frank Kloeker]

Am 2018-02-01 23:42, schrieb Sean McGinnis:

We are already starting on RC week. Time flies when you're having fun.

Development Focus
-

The Release Candidate (RC) deadline is this Thursday, the 8th. Work 
should be
focused on any release-critical bugs and wrapping up and remaining 
feature

work.

General Information
---

All cycle-with-milestones and cycle-with-intermediary projects should 
cut their
stable/queens branch by the end of this week. This branch will track 
the Queens

release.

Once stable/queens has been created, master will will be ready to 
switch to
Rocky development. While master will no longer be frozen, please 
prioritize any

work necessary for completing Queens plans.


[...]
Thx, Sean.
If your project contains translation stuff like Horizon Dashboard 
Plugins, please send me a note when you switch to stable/queens branch, 
so we can prepare translation platform in time with the new branch.


thx
Frank (eumel8)


__
OpenStack Development Mailing 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] Technical Committee Status update, February 2nd

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

* New project team: Qinling (Function as a Service) [1]
* Goal updates: ironic

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

This has been a busy week for our infrastructure team, as we digested
the surge in activity linked to the Queens Feature Freeze (and related
release/branching requests). Gate levels look like they are back to
normal levels now...

We added a new project team to the OpenStack family this week. Qinling,
which allows to provide function-as-a-service on top of an OpenStack
cloud, was just approved. It will be officially included in the next
OpenStack release cycle, Rocky.


== PTG preparation ==

Dublin is only 24 days from now, and we should prepare a bit to make the
most of this event. The Project Teams Gathering is a productivity
booster: getting together for face-to-face time to get quick agreement
on complex questions and making quick progress on critical work.

We have a lot of tracks, some around a specific project team, some
around a specific SIG, and some around a specific area of discussion.
You can find the track layout at:

https://www.openstack.org/ptg#tab_schedule

We have extra room on Monday and Tuesday for missing (or last-minute)
areas of discussion. If you can think of something we should really be
discussing, please add your thoughts to:

https://etherpad.openstack.org/p/PTG-Dublin-missing-topics

Track leads have set up a number of etherpads to openly brainstorm what
to discuss. You can find those (or link to missing ones) here:

https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads

New for this PTG, we'll have post-lunch presentations. Ideas and a
strawman programme are proposed here:

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

If you haven't registered yet, please note that the event is very likely
to sell out. I advise you to not wait too much before getting your ticket:

https://rockyptg.eventbrite.com


== Rocky goals ==

We have been making progress on selecting a set of goals for the Rocky
cycle. As a reminder, here are the currently-proposed goals:

* Storyboard Migration [2] (diablo_rojo)
* Remove mox [3] (chandankumar)
* Ensure pagination links [4] (mordred)
* Add Cold upgrades capabilities [5] (masayuki)
* Enable toggling DEBUG option at runtime [6] (gcb)

[2] https://review.openstack.org/513875
[3] https://review.openstack.org/532361
[4] https://review.openstack.org/532627
[5] https://review.openstack.org/#/c/533544/
[6] https://review.openstack.org/534605

In discussions this week the following set was proposed: mox reduction
and DEBUG runtime toggling. It represents a good mix of ops-facing
improvement and dev-facing tech debt reduction. Please chime in on the
threads and reviews if you think this would not be a reasonable set.


== Under discussion ==

A new project team was proposed to regroup people working on PowerVM
support in OpenStack. It is similar in many ways to the WinStackers team
(working on Hyper-V / Windows support). Please comment on the review at:

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

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, now on an active mailing-list
thread. Please chime in to inform the TC choice:

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


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

We need to finalize the set of Rocky goals, ahead of the PTG, so that
the champions for the selected goals can start planning their PTG
activities.

Thanks to pabelanger for volunteering to drive the S release naming
process. He needs to propose a release_naming.rst change proposing dates
and geographic area for the name choices.

Finally we need to start brainstorming the contents of the Monday
post-lunch presentation at the PTG (the "welcome to the PTG"
presentation which will be used to give situation awareness to attendees).


== 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 discussions to still be focused around
Rocky goal selection and PTG prep.

Cheers,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mai

[openstack-dev] [qa] Office Hours Report 2018-02-01

[Chandan kumar]

Hello,

Thanks everyone for attending QA office hour. Since It's the starting
of the year so attendance is low. We managed to triaged some bugs
opened/changed in last 14 days.

The IRC report [0] and full log [1] are available through meetbot.

bug 1745871 in Patrole "RBAC tests for group type specs"
https://bugs.launchpad.net/patrole/+bug/1745871
Status: confirmed
Related Review: https://review.openstack.org/#/c/525589/

1743688 in congress "Tempest unable to detect service availability
properly, causing congress tests to fail"
https://bugs.launchpad.net/devstack/+bug/1743688
Status: In Progress

bug 1744096 in devstack "CentOS install fails with 'python3: command not found'"
https://bugs.launchpad.net/devstack/+bug/1744096
status: In Progress

bug 1746687 in tempest "tempest plugins should be loaded though configuration"
https://bugs.launchpad.net/tempest/+bug/1746687
Status: Invalid

Above bug leads to interesting discussion on how to ship tempest
plugins with kolla tempest containers
Below are the remarks:
* Bundle all the plugins in a single containers.
* User service_available config params to enable or disable a plugin
while using it
* In tempest we have blacklist or whitelist test params to play with tests.

bug 1745322 in tempest "stackviz folder does not show up in logs on
zuulv3 native jobs"
https://bugs.launchpad.net/tempest/+bug/1745322
Status: Fix committed
Review: https://review.openstack.org/#/c/539146/

bug 1745307 in tempest "Group related cases would fail if driver has
group spec check"
https://bugs.launchpad.net/tempest/+bug/1745307
Status: in-progress
Review: https://review.openstack.org/537784

https://bugs.launchpad.net/tempest/+bug/1660612
bug 1660612 in neutron "Tempest full jobs time out on execution"
status: New
Comments: related fix https://review.openstack.org/#/c/536598/ is not
ok. it changes existing tox envs which has an impact on existing jobs
it make it all scenario to run parallel, but tempest full deos not run
 scenario tests.

Links:
[0]. 
http://eavesdrop.openstack.org/meetings/qa_office_hour/2018/qa_office_hour.2018-02-01-09.05.txt
[1]. 
http://eavesdrop.openstack.org/meetings/qa_office_hour/2018/qa_office_hour.2018-02-01-09.05.log.html

Thanks for reading.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing 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] [telemetry][heat][mistral][sdk][searchlight][senlin][tacker][tricircle][tripleo] Missing Queens releases

[Hanxi Liu]

On Thu, Feb 1, 2018 at 5:03 AM, Sean McGinnis  wrote:

> While reviewing Queens release deliverables and preparing missing
> stable/queens
> branches, we have identified several libraries that have not had any Queens
> releases.
>
> In the past, we have stated we would force a release for any missing
> deliverables in order to have a clear branching point. We considered
> tagging
> the base of the stable/pike branch again and starting a new stable/queens
> branch from there, but that doesn't work for several technical reasons the
> most
> important of which is that the queens release would not include any changes
> that had been backported to stable/pike, and we have quite a few of those.
> So,
> we are left with 2 choices: do not release these libraries at all for
> queens,
> or release from HEAD on master. Skipping the releases entirely will make it
> difficult to provide bug fixes in these libraries over the life of the
> queens
> release so, although it is potentially disruptive, we plan to release from
> HEAD
> on master. We will rely on the constraints update mechanism to protect the
> gate
> if the new releases introduce bugs and teams will be able to fix those
> problems
> on the new stable/queens branch and then release a new version.
>
> See https://review.openstack.org/#/c/539657/ and the notes below for
> details of
> what will be tagged.
>
> ceilometermiddleware
> 
>
> Mostly doc and CI related changes, but the "Retrieve project id to ignore
> from
> keystone" commit (e2bf485) looks like it may be important.
>
>
Thanks Sean and release team! It's ok on ceilometermiddleware from
Telemetry side.


Hanxi Liu

(IRC: lhx_)

__
OpenStack Development Mailing 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] [ptg] Dublin PTG schedule up

[Matthew Oliver]

Ahh makes sense. Thanks Thierry, I can tell this isn't your first Rodeo :)

Matt

On Fri, Feb 2, 2018 at 7:52 PM, Thierry Carrez 
wrote:

> Matthew Oliver wrote:
> > Sweet thanks Thierry,
> >
> > Only issue is I see what days things are happening, but not what rooms
> > things are in. Unless I'm failing at reading a table.
>
> Yes, that's by design. We publish the days early so that people can
> fine-tune their travel plans and start organizing. We are still
> finalizing the exact room assignments, though. Those will be ready by
> the time the event starts :)
>
> --
> Thierry
>
> __
> OpenStack Development Mailing 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] [ptg] Dublin PTG schedule up

[Thierry Carrez]

Matthew Oliver wrote:
> Sweet thanks Thierry,
> 
> Only issue is I see what days things are happening, but not what rooms
> things are in. Unless I'm failing at reading a table.

Yes, that's by design. We publish the days early so that people can
fine-tune their travel plans and start organizing. We are still
finalizing the exact room assignments, though. Those will be ready by
the time the event starts :)

-- 
Thierry

__
OpenStack Development Mailing 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] TripleO CI end of sprint status

[Arx Cruz]

Hello,

On January 31 we came the end of sprint using our new team structure, and
here’s the highlights.

Sprint Review:

On this sprint, the team worked on internal infrastructure.

One can see the results of the sprint via https://tinyurl.com/ycpw42pj


Ruck and Rover

What is Ruck and Rover

One person in our team is designated Ruck and another Rover, one is
responsible to monitoring the CI, checking for failures, opening bugs,
participate on meetings, and this is your focal point to any CI issues. The
other person, 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]

List of bugs that Ruck and Rover were working on:


   -

   https://bugs.launchpad.net/tripleo/+bug/1744151 -
   
barbican_tempest_plugin.tests.scenario.test_volume_encryption.VolumeEncryptionTest
   fails on Invalid Volume
   -

   https://bugs.launchpad.net/tripleo/+bug/1745712 - master:
   etc/pki/tls/certs/undercloud-192.168.24.2.pem]: Failed to generate
   additional resources using 'eval_generate': comparison of Array with Array
   failed
   -

   https://bugs.launchpad.net/tripleo/+bug/1746023 - rdo phase 2 status to
   dlrn_api fails with file not found
   -

   https://bugs.launchpad.net/tripleo/+bug/1746026 - Tracker, CI: OVB jobs
   on RDO cloud can't get OVB env because of 504 gateway timeout
   -

   https://bugs.launchpad.net/tripleo/+bug/1746281 - tripleo jobs running
   in rax have slow package downloads, jobs timing out
   -

   https://bugs.launchpad.net/tripleo/pike/+bug/1745686 -
   [gnocchi-db-sync]: gnocchi-upgrade --config-file /etc/gnocchi/gnocchi.conf
   --skip-storage --skip-incoming returned 2
   -

   https://bugs.launchpad.net/tripleo/+bug/1746729 - tracker, rdo sf
   nodepool slaves going off line
   -

   https://bugs.launchpad.net/tripleo/+bug/1746737 - "msg": "No package
   matching 'jq' found available, installed or updated"
   -

   https://bugs.launchpad.net/tripleo/+bug/1746734 - Periodic Jobs failing
   at tempest config while creating image(with swift backend)


We also have our new Ruck and Rover for this week:


   -

   Ruck
   -

  Rafael Folco - rfolco|ruck
  -

   Rover
   -

  Sagi Shnaidman  - sshnaidm|rover


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

[1]
https://github.com/openstack/tripleo-specs/blob/master/specs/policy/ci-team-structure.rst
__
OpenStack Development Mailing 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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Duncan Thomas]

So I guess my question here is why is being RESTful good? Sure it's (very,
very loosely) a standard, but what are the actual advantages? Standards
come and go, what we want most of all is a good quality, easy to use API.

I'm not saying that going RESTful is wrong, but I don't see much discussion
about what the advantages are, only about how close we are to implementing
it.

On 1 Feb 2018 10:55 pm, "Ed Leafe"  wrote:

> On Jan 18, 2018, at 4:07 AM, TommyLike Hu  wrote:
>
> >Recently We found an issue related to our OpenStack action APIs. We
> usually expose our OpenStack APIs by registering them to our API Gateway
> (for instance Kong [1]), but it becomes very difficult when regarding to
> action APIs. We can not register and control them seperately because them
> all share the same request url which will be used as the identity in the
> gateway service, not say rate limiting and other advanced gateway features,
> take a look at the basic resources in OpenStack
>
> We discussed your email at today’s API-SIG meeting [0]. This is an area
> that is always contentious in the RESTful world. Actions, tasks, and state
> changes are not actual resources, and in a pure REST design they should
> never be part of the URL. Instead, you should POST to the actual resource,
> with the desired action in the body. So in your example:
>
> > URL:/volumes/{volume_id}/action
> > BODY:{'extend':{}}
>
> the preferred way of achieving this is:
>
> URL: POST /volumes/{volume_id}
> BODY: {‘action’: ‘extend’, ‘params’: {}}
>
> The handler for the POST action should inspect the body, and call the
> appropriate method.
>
> Having said that, we realize that a lot of OpenStack services have adopted
> the more RPC-like approach that you’ve outlined. So while we strongly
> recommend a standard RESTful approach, if you have already released an
> RPC-like API, our advice is:
>
> a) avoid having every possible verb in the URL. In other words, don’t use:
>   /volumes/{volume_id}/mount
>   /volumes/{volume_id}/umount
>   /volumes/{volume_id}/extend
> This moves you further into RPC-land, and will make updating your API to a
> more RESTful design more difficult.
>
> b) choose a standard term for the item in the URL. In other words, always
> use ‘action’ or ‘task’ or whatever else you have adopted. Don’t mix
> terminology. Then pass the action to perform, along with any parameters in
> the body. This will make it easier to transition to a RESTful design by
> later updating the handlers to first inspect the BODY instead of relying
> upon the URL to determine what action to perform.
>
> You might also want to contact the Kong developers to see if there is a
> way to work with a RESTful API design.
>
> -- Ed Leafe
>
> [0] http://eavesdrop.openstack.org/meetings/api_sig/2018/api_
> sig.2018-02-01-16.02.log.html#l-28
>
>
>
>
> __
> OpenStack Development Mailing 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] [telemetry][heat][mistral][sdk][searchlight][senlin][tacker][tricircle][tripleo] Missing Queens releases

[Renat Akhmerov]

Sorry for the late reply. I just want to confirm that it’s ok from Mistral side.

Thanks

Renat Akhmerov
@Nokia

On 2 Feb 2018, 02:35 +0700, Sean McGinnis , wrote:
> Just confirming and closing things out. We did not receive any negative
> responses to the plan below, so a little earlier today I approved the 
> mentioned
> patch and we cut releases and branches for all libs.
>
> The next step if for these new versions to pass CI and get FFEs to raise the
> upper constraints for them past our requirements freeze. That official request
> will be coming shortly.
>
> Sean
>
> On Wed, Jan 31, 2018 at 03:03:44PM -0600, Sean McGinnis wrote:
> > While reviewing Queens release deliverables and preparing missing 
> > stable/queens
> > branches, we have identified several libraries that have not had any Queens
> > releases.
> >
> > In the past, we have stated we would force a release for any missing
> > deliverables in order to have a clear branching point. We considered tagging
> > the base of the stable/pike branch again and starting a new stable/queens
> > branch from there, but that doesn't work for several technical reasons the 
> > most
> > important of which is that the queens release would not include any changes
> > that had been backported to stable/pike, and we have quite a few of those. 
> > So,
> > we are left with 2 choices: do not release these libraries at all for 
> > queens,
> > or release from HEAD on master. Skipping the releases entirely will make it
> > difficult to provide bug fixes in these libraries over the life of the 
> > queens
> > release so, although it is potentially disruptive, we plan to release from 
> > HEAD
> > on master. We will rely on the constraints update mechanism to protect the 
> > gate
> > if the new releases introduce bugs and teams will be able to fix those 
> > problems
> > on the new stable/queens branch and then release a new version.
> >
> > See https://review.openstack.org/#/c/539657/ and the notes below for 
> > details of
> > what will be tagged.
> >
> > ceilometermiddleware
> > 
> >
> > Mostly doc and CI related changes, but the "Retrieve project id to ignore 
> > from
> > keystone" commit (e2bf485) looks like it may be important.
> >
> > Heat
> > 
> >
> > heat-translator
> > There are quite a few bug fixes and feature changes merged that have not 
> > been
> > released. It is currently marked with a type of "library", but we will 
> > change
> > this to "other" and require a release by the end of the cycle (see
> > https://review.openstack.org/#/c/539655/ for that change). Based on the 
> > README
> > description, this appears to be a command line and therefore should maybe 
> > have
> > a type of "client-library", but "other" would work as far as release process
> > goes. Since this is kind of a special command line, perhaps "other" would be
> > the correct type going forward, but we will need input from the Heat team on
> > that.
> >
> > python-heatclient
> > Only reno updates, so a new release on master should not be very disruptive.
> >
> > tosca-parser
> > Several unreleased bug fixes and feature changes. Consumed by 
> > heat-translator
> > and tacker, so there is some risk in releasing it this late.
> >
> >
> > Mistral
> > ---
> >
> > mistral-lib
> > Mostly packaging and build changes, with a couple of fixes. It is used by
> > mistral and tripleo-common.
> >
> > SDK
> > ---
> >
> > requestsexceptions
> > No changes this cycle. We will branch stable/queens from the same point as
> > stable/pike.
> >
> > Searchlight
> > ---
> >
> > python-searchlightclient
> > Only doc and g-r changes. Since the risk here is low, we are going to 
> > release
> > from master and branch from there.
> >
> > Senlin
> > --
> >
> > python-senlinclient
> > Just one bug fix. This is a dependency for heat, mistral, openstackclient,
> > python-openstackclient, rally, and senlin-dashboard. The one bug fix looks
> > fairly safe though, so we are going to release from master and branch from
> > there.
> >
> > Tacker
> > --
> >
> > python-tackerclient
> > Many feature changes and bug fixes. This impacts mistral and tacker.
> >
> > Tricircle
> > -
> >
> > python-tricircleclient
> > One feature and several g-r changes.
> >
> >
> > Please respond here, comment on the patch, or hit us up in 
> > #openstack-release
> > if you have any questions or concerns.
> >
> > Thanks,
> > Sean McGinnis (smcginnis)
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi