Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

2018-09-07 Thread Tony Breeds
On Fri, Sep 07, 2018 at 11:09:15AM +0200, Julien Danjou wrote:

> You can, I've already said +1 on a review a few weeks ago. :)

Oh great.  I'll dig that up and push forward with that side of things if
you don't mind.

Yours Tony.


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


[openstack-dev] [masakari] No meeting on next week (9/10)

2018-09-07 Thread Sam P
Hi All,
 Since most of us in Denver for PTG, there will be not meeting on 9/10.

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


Re: [openstack-dev] [Storyboard][Searchlight] Where can I find the project ID on Storyboard?

2018-09-07 Thread Jeremy Stanley
On 2018-09-08 10:10:37 +0900 (+0900), Trinh Nguyen wrote:
> I'm adding Searchlight projects to the Stein deliverables with the
> storyboard attribute. Where can I find the Searchlight projects ID? Right
> now I can only see the project links.

It can be looked up from the API like so:

https://storyboard.openstack.org/api/v1/projects/openstack/searchlight

However I agree expecting users to do this isn't particularly
friendly. Since this was in service of filling out release
management details, I've pushed https://review.openstack.org/600893
for review to support optionally using the project name now that SB
supports querying with it and uses it by default in webclient URLs.
-- 
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] [Storyboard][Searchlight] Where can I find the project ID on Storyboard?

2018-09-07 Thread Trinh Nguyen
Hi Storyboard team,

I'm adding Searchlight projects to the Stein deliverables with the
storyboard attribute. Where can I find the Searchlight projects ID? Right
now I can only see the project links.

Thanks,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
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-30 and R-29, September 10-21

2018-09-07 Thread Trinh Nguyen
Hi,

Thanks for the summary.

I just added Searchlight to the Stein deliverable [1]. One concern is we
moved our projects to Storyboard last week, do I have to change the project
file to reflect that and how?

Thanks,

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

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Sat, Sep 8, 2018 at 5:14 AM Sean McGinnis  wrote:

> Here we go again! The Stein cycle will be slightly longer than past
> cycles. In
> case you haven't seen it yet, please take a look over the schedule for this
> release:
>
> https://releases.openstack.org/stein/schedule.html
>
> Development Focus
> -
>
> Focus should be on optimizing the time at the PTG and following up after
> the
> event to jump start Stein development.
>
> General Information
> ---
>
> All teams should review their release liaison information and make sure it
> is
> up to date [1].
>
> [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons
>
> While reviewing liaisons, this would also be a good time to make sure your
> declared release model matches the project's plans for Stein (e.g. [2]).
> This
> should be done prior to the first milestone and can be done by proposing a
> change to the Stein deliverable file for the project(s) affected [3].
>
> [2]
> https://github.com/openstack/releases/blob/e0a63f7e896abdf4d66fb3ebeaacf4e17f688c38/deliverables/queens/glance.yaml#L5
> [3]
> http://git.openstack.org/cgit/openstack/releases/tree/deliverables/stein
>
> Now would be a good time to start brainstorming Forum topics while some of
> the
> PTG discussions are fresh. Just a couple months until the Summit and Forum
> in
> Berlin.
>
> Upcoming Deadlines & Dates
> --
>
> Stein-1 milestone: October 25  (R-24 week)
> Forum at OpenStack Summit in Berlin: November 13-15
>
> --
> 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-bin/mailman/listinfo/openstack-dev


[openstack-dev] [neutron] [router] status bug

2018-09-07 Thread Bhatia, Manjeet S
Hi neutrinos,

I was looking at Bug [1], and noticed that router status stays ACTIVE even 
after -disable ?

-openstack router -set disable router1

/opt/stack/neutron$ openstack router set --disable routerr1
vagrant@allinone:/opt/stack/neutron$ neutron router-show router1
neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | False|
| availability_zone_hints |  |
| availability_zones  |  |
| created_at  | 2018-09-08T00:30:46Z |
| description |  |
| distributed | True |
| external_gateway_info   |  |
| flavor_id   |  |
| ha  | False|
| id  | 6f88b5f4-dc94-44bd-89cd-9c0f2b374f79 |
| name| router1   |
| project_id  | 05d72b0eff534ccf81e37b5d6e3402f6 |
| revision_number | 1|
| routes  |  |
| status  | ACTIVE   |
| tags|  |
| tenant_id   | 05d72b0eff534ccf81e37b5d6e3402f6 |
| updated_at  | 2018-09-08T00:31:18Z |





Shouldn't it update the status to DOWN  ? before I open a ticket for bug I just 
wanted to confirm it ?

[1]. https://bugs.launchpad.net/neutron/+bug/1789434



Regards !
Manjeet Singh Bhatia
__
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] [tempest][CI][nova compute] Skipping non-compute-driver tests

2018-09-07 Thread Matt Riedemann

On 9/7/2018 10:25 AM, William M Edmonds wrote:
The concern that I have with whitelisting in a given CI is that it has 
to be done independently in every compute driver CI. So while I agree 
that it won't be easy to maintain tagging for compute driver on the 
tempest side, at least that's one place / easier than doing it in every 
driver CI. When anyone figures out that an change is needed, all of the 
CIs would benefit together if there is a shared solution.


How about storing the compute-driver specific whitelist in a common 
location? I'm not sure if that would be tempest, nova or somewhere else.


--

Thanks,

Matt

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


Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

2018-09-07 Thread Amy Marrich
I'm game!

Amy (spotz)

On Fri, Sep 7, 2018 at 5:30 PM, Ildiko Vancsa 
wrote:

> Hi Training Team,
>
> As a couple of us will be at the PTG next week it would be great to get
> together one of the days maybe for lunch.
>
> Wednesday would work the best for Kendall and me, but we can look into
> other days as well if it would not work for the majority of people around.
>
> So my questions would be:
>
> * Are you interested in getting together one of the lunch slots during
> next week?
>
> * Would Wednesday work for you or do you have another preference?
>
> Please drop a response to this thread and we will figure it out by Monday
> or early next week based on the responses.
>
> Thanks,
> Ildikó
> (IRC: ildikov)
>
>
>
> __
> 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] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

2018-09-07 Thread Ildiko Vancsa
Hi Training Team,

As a couple of us will be at the PTG next week it would be great to get 
together one of the days maybe for lunch.

Wednesday would work the best for Kendall and me, but we can look into other 
days as well if it would not work for the majority of people around.

So my questions would be:

* Are you interested in getting together one of the lunch slots during next 
week?

* Would Wednesday work for you or do you have another preference?

Please drop a response to this thread and we will figure it out by Monday or 
early next week based on the responses.

Thanks,
Ildikó
(IRC: ildikov)



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


[openstack-dev] [Storyboard] PTG Planning & Upcoming Meeting Cancelled

2018-09-07 Thread Kendall Nelson
Hello!

With the PTG in just a few days, I wanted to give some info and updates so
that you are prepared.

1. This coming week's regular meeting on Wednesday will be cancelled.

2. I am planning on booking Blanca Peak for the whole afternoon on Tuesday
for discussions. Just waiting for this patch to merge[0]. If we need more
time we can schedule something later in the week. See you there!

3. Here [1] is the etherpad that we've been collecting discussion topics
into. If there is anything you want to add, feel free.

-Kendall (diablo_rojo)

[0] https://review.openstack.org/#/c/600665/
[1]https://etherpad.openstack.org/p/sb-stein-ptg-planning
__
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] [First Contact] PTG Planning & Meeting Cancelled

2018-09-07 Thread Kendall Nelson
Hello Everyone!

I can't believe the PTG is only a few days away!

We have our etherpad of discussion topics here[1]. If there is anything
else we need to talk about, please add it!

We will be meeting Tuesday Morning in Blanca Peak. I don't think we will
fill the whole day, so it will be used for StoryBoard meetings in the
afternoon. If there are remote people interested in joining, please let me
know and I can set something up.

Also, if Tuesday morning doesn't work for people perhaps we can schedule a
recap for later in the week.

Also, the Wednesday meeting will be cancelled because many of us will be
meeting in person :)

-Kendall (diablo_rojo)

[1]https://etherpad.openstack.org/p/FC_SIG_ptg_stein
__
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 3 September 2018

2018-09-07 Thread Lance Bragstad
# Keystone Team Update - Week of 3 September 2018

## News

This week was mainly focused on the python3 community goal and ultimately
cleaning up a bunch of issues with stable branches that were uncovered in
those reviews. Next week is the PTG, which the group is preparing for in
addition to brainstorming Stein forum topics [0][1].

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134362.html
[1] https://etherpad.openstack.org/p/BER-keystone-forum-sessions

## User Feedback

The foundation provided us with the latest feedback from our users [0]. A
sanitized version of that data has been shared publicly [1] for you to
checkout prior to the PTG. We have time set aside on Wednesday to review
the feedback and discuss any adjustments we want to make to the survey
questions.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134434.html
[1]
https://docs.google.com/spreadsheets/d/1wz-GOoFODGWrFuGqVWDunEWsuhC_lvRJLrfUybTj69Q/edit?usp=sharing

## PTG Planning

As I'm sure you're aware, the PTG is next week. The schedule is relatively
firm at this point [0], but please raise any conflicts with other sessions
if you see any.

[0] https://etherpad.openstack.org/p/keystone-stein-ptg

## Open Specs

Search query: https://bit.ly/2Pi6dGj

A new specification was proposed this week to enable limit support for
domains [0]. This is going to be a main focus next week as we discuss
unified limits. Please have a look if you're interested in that particular
discussion.

[0] https://review.openstack.org/#/c/599491/

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 26 changes this week, most of which were for the python3
community goal [0].

We did notice a high number of stable branch failures for keystoneauth,
keystonemiddleware, and python-keystoneclient. This was discussed on the
ML[1][2].

[0] https://governance.openstack.org/tc/goals/stein/python3-first.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134391.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134454.html

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 58 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots.

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1776504

## Bugs

This week we opened 9 new bugs, closed 1, and fixed 3.

Bugs opened (9)

   - Bug #1790148 (keystone:Low) opened by FreudianSlip
   https://bugs.launchpad.net/keystone/+bug/1790148


   - Bug #1790428 (keystone:Undecided) opened by Eric Miller
   https://bugs.launchpad.net/keystone/+bug/1790428


   - Bug #179 (keystone:Undecided) opened by Paul Peereboom
   https://bugs.launchpad.net/keystone/+bug/179


   - Bug #1780164 (keystoneauth:Undecided) opened by mchlumsky
   https://bugs.launchpad.net/keystoneauth/+bug/1780164


   - Bug #1790423 (python-keystoneclient:Undecided) opened by ChenWu
   https://bugs.launchpad.net/python-keystoneclient/+bug/1790423


   - Bug #1790931 (oslo.limit:Medium) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790931


   - Bug #1790954 (oslo.limit:Medium) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790954


   - Bug #1790894 (oslo.limit:Low) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790894


   - Bug #1790935 (oslo.limit:Low) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790935


Bugs closed (1)

   - Bug #1790423 (python-keystoneclient:Undecided)
   https://bugs.launchpad.net/python-keystoneclient/+bug/1790423


Bugs fixed (3)

   - Bug #1777671 (keystone:Medium) fixed by Vishakha Agarwal
   https://bugs.launchpad.net/keystone/+bug/1777671


   - Bug #1790148 (keystone:Low) fixed by Chason Chan
   https://bugs.launchpad.net/keystone/+bug/1790148


   - Bug #1789351 (keystonemiddleware:Undecided) fixed by wangxiyuan
   https://bugs.launchpad.net/keystonemiddleware/+bug/1789351


## Milestone Outlook

We have a lot of work to do to shape the release between now and milestone
1, which will be October 26th. Focusing on specifications and early feature
development is appreciated.

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

## Shout-outs

Thanks to Ben, Doug, and Tony for helping us make sense of the
tox_install.sh and pip stable branch mess! We should be past the last layer
of the onion with respect to the python3 stable patches.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [ptls] [user survey] User Survey Privacy

2018-09-07 Thread Jimmy McArthur

Hi PTLs!

A recent question came up regarding public sharing of the 
Project-Specific feedback questions on the OpenStack User Survey.  The 
short answer is... this is a great idea! This information is meant to 
help projects improve and the information is not meant to be kept 
secret.  Oddly enough, nobody asked before lbragstad,  so thanks for 
asking!


The long answer... I would like to add a little bit of background on the 
user survey and how we treat the data.


Part of the agreement we make with users that fill out the User Survey 
is we will keep their data anonymized. As a result, when we publish data 
on the website[1] we ensure the user can see data from no fewer than 10 
companies at a time.   Additionally, the User Committee, who helps with 
the data analysis, sign an NDA before reviewing any data, which helps to 
preserve user privacy.


All that said, the questions for PTLs are framed as "Project Feedback", 
so the expectation and hope is that PTLs will not only use it to improve 
their projects, but will also share it amongst other relevant projects.


As excited as we are to have you share this data with the community, we 
do want to make sure there is nothing that would reveal the identity of 
the survey taker.  We've already vetted the English content, but we are 
still waiting on translations to finish up.  So, if you decide to share 
the data publicly, please only share the English content for the time 
being.  Feel free to reference this email or hit us up on the 
user-commit...@lists.openstack.org 



Beyond that, we encourage you to follow in Keystone's footsteps and 
share this feedback with the mailing list, at the PTG, or even with a 
buddy. We hope it's valuable to your project and the community at large!


Net: PTLs, please share the project feedback publicly (e.g. on the 
mailing lists) now (with the above caveats).


Cheers,
Jimmy

[1] https://www.openstack.org/analytics 

__
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] Release countdown for week R-30 and R-29, September 10-21

2018-09-07 Thread Sean McGinnis
Here we go again! The Stein cycle will be slightly longer than past cycles. In
case you haven't seen it yet, please take a look over the schedule for this
release:

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

Development Focus
-

Focus should be on optimizing the time at the PTG and following up after the
event to jump start Stein development.

General Information
---

All teams should review their release liaison information and make sure it is
up to date [1].

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons

While reviewing liaisons, this would also be a good time to make sure your
declared release model matches the project's plans for Stein (e.g. [2]). This
should be done prior to the first milestone and can be done by proposing a
change to the Stein deliverable file for the project(s) affected [3].

[2] 
https://github.com/openstack/releases/blob/e0a63f7e896abdf4d66fb3ebeaacf4e17f688c38/deliverables/queens/glance.yaml#L5
[3] http://git.openstack.org/cgit/openstack/releases/tree/deliverables/stein

Now would be a good time to start brainstorming Forum topics while some of the
PTG discussions are fresh. Just a couple months until the Summit and Forum in
Berlin.

Upcoming Deadlines & Dates
--

Stein-1 milestone: October 25  (R-24 week)
Forum at OpenStack Summit in Berlin: November 13-15

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


Re: [openstack-dev] [election][tc] Announcing candidacy

2018-09-07 Thread Matt Riedemann

On 9/7/2018 12:17 PM, Rico Lin wrote:
I'm refering on clear communication channels and go from Use cases to 
real development tasks (As I try to explain in the last section of my 
candidacy).


Sorry, I totally missed the other details in your candidacy email 
because they came after your signature. Otherwise I wouldn't have asked. :)



And here's some specific initiatives or deliverables sample I got in mind.
* From StarlingX, some great improvement for Edge cases are delivered to 
projects. And there're also communications cross StarlingX and TCs on 
how to make it integrated with rest OpenStack projects (currently 
StarlingX still using it's own forks of OpenStack projects). And 
there're other projects that other organizations contribute to OpenStack 
or form another communities that depend on OpenStack.
* We recently create a new repo `openstack-service-broker` [1]. Use 
Service Broker (A project from CloudFoundry) expose external resources 
to applications running in a PaaS. Which is exactly a integration cross 
CloudFoundry and OpenStack (protentially with K8s too) base on specific 
scenario.
* K8s as one of the most popular case here, I believe we already can see 
some nice integration cross OpenStack and K8s. Include Manila, Keystone 
support in K8s, Magnum become one of official deployment tool in K8s 
community. Also I'm currently working on Integrate Heat AutoScaling to 
K8s cluster autoscaler as well [2].

* OPNFV integrated with OpenStack as it's cluster provider.


Yes this is good detail, thanks Rico.

--

Thanks,

Matt

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


Re: [openstack-dev] [nova][cinder] about unified limits

2018-09-07 Thread Ben Nemec
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if that 
would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes were 
captured in etherpad [1]. We spent the Rocky cycle fixing usability 
issues with the API [2] and implementing support for a hierarchical 
enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick transition, 
as we don't want to keep the API hanging in an experimental state. It's 
really just a safe guard to make sure we have the opportunity to use it 
in another service before fully committing to the API. Ultimately, we 
don't want to prematurely mark the API as supported when other services 
aren't even using it yet, and then realize it has issues that could have 
been fixed prior to the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of oslo.limit 
is to abstract project and project hierarchy information away from the 
service, so that services don't have to reimplement client code to 
understand project trees, which could arguably become complex and lead 
to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not usage 
for that claim is valid. For example, here is a project ID, resource 
name, and resource quantity, tell me if this project is over it's 
associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and project 
hierarchies. Then it needs to reason about those things and calculate 
usage from the service in order to determine if the request claim is 
valid or not. There are patches up for this work, and reviews are always 
welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work out 
remaining bugs in both keystone and oslo.limit. Once we're confident in 
both the API and the library, we'll bump oslo.limit to version 1.0 at 
the same time we graduate the unified limits API from "experimental" to 
"supported". Note that oslo libraries <1.0 are considered experimental, 
which fits nicely with the unified limit API being experimental as we 
shake out usability issues in both pieces of software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we can 
use the first couple iterations to generate some well-written usage 
documentation. Any questions coming from developers in this phase should 
probably be answered in documentation if we want to enable folks to pick 
this up and run with it. Otherwise, I could see the handful of people 
pushing the effort becoming a bottle neck in adoption.


Hopefully this helps paint the landscape of where things are currently 
with respect to each piece. As always, let me know if you have any 
additional questions. If people want to discuss online, you can find me, 
and other contributors familiar with this topic, in #openstack-keystone 
or #openstack-dev on IRC (nic: lbragstad).


[0] 

Re: [openstack-dev] [nova][cinder] about unified limits

2018-09-07 Thread Lance Bragstad
That would be great! I can break down the work a little bit to help
describe where we are at with different parts of the initiative. Hopefully
it will be useful for your colleagues in case they haven't been closely
following the effort.

# keystone

Based on the initial note in this thread, I'm sure you're aware of
keystone's status with respect to unified limits. But to recap, the initial
implementation landed in Queens and targeted flat enforcement [0]. During
the Rocky PTG we sat down with other services and a few operators to
explain the current status in keystone and if either developers or
operators had feedback on the API specifically. Notes were captured in
etherpad [1]. We spent the Rocky cycle fixing usability issues with the API
[2] and implementing support for a hierarchical enforcement model [3].

At this point keystone is ready for services to start consuming the unified
limits work. The unified limits API is still marked as stable and it will
likely stay that way until we have at least one project using unified
limits. We can use that as an opportunity to do a final flush of any
changes that need to be made to the API before fully supporting it. The
keystone team expects that to be a quick transition, as we don't want to
keep the API hanging in an experimental state. It's really just a safe
guard to make sure we have the opportunity to use it in another service
before fully committing to the API. Ultimately, we don't want to
prematurely mark the API as supported when other services aren't even using
it yet, and then realize it has issues that could have been fixed prior to
the adoption phase.

# oslo.limit

In parallel with the keystone work, we created a new library to aid
services in consuming limits. Currently, the sole purpose of oslo.limit is
to abstract project and project hierarchy information away from the
service, so that services don't have to reimplement client code to
understand project trees, which could arguably become complex and lead to
inconsistencies in u-x across services.

Ideally, a service should be able to pass some relatively basic information
to oslo.limit and expect an answer on whether or not usage for that claim
is valid. For example, here is a project ID, resource name, and resource
quantity, tell me if this project is over it's associated limit or default
limit.

We're currently working on implementing the enforcement bits of oslo.limit,
which requires making API calls to keystone in order to retrieve the
deployed enforcement model, limit information, and project hierarchies.
Then it needs to reason about those things and calculate usage from the
service in order to determine if the request claim is valid or not. There
are patches up for this work, and reviews are always welcome [4].

Note that we haven't released oslo.limit yet, but once the basic
enforcement described above is implemented we will. Then services can
officially pull it into their code as a dependency and we can work out
remaining bugs in both keystone and oslo.limit. Once we're confident in
both the API and the library, we'll bump oslo.limit to version 1.0 at the
same time we graduate the unified limits API from "experimental" to
"supported". Note that oslo libraries <1.0 are considered experimental,
which fits nicely with the unified limit API being experimental as we shake
out usability issues in both pieces of software.

# services

Finally, we'll be in a position to start integrating oslo.limit into
services. I imagine this to be a coordinated effort between keystone, oslo,
and service developers. I do have a patch up that adds a conceptual
overview for developers consuming oslo.limit [5], which renders into [6].

To be honest, this is going to be a very large piece of work and it's going
to require a lot of communication. In my opinion, I think we can use the
first couple iterations to generate some well-written usage documentation.
Any questions coming from developers in this phase should probably be
answered in documentation if we want to enable folks to pick this up and
run with it. Otherwise, I could see the handful of people pushing the
effort becoming a bottle neck in adoption.

Hopefully this helps paint the landscape of where things are currently with
respect to each piece. As always, let me know if you have any additional
questions. If people want to discuss online, you can find me, and other
contributors familiar with this topic, in #openstack-keystone or
#openstack-dev on IRC (nic: lbragstad).

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[1] https://etherpad.openstack.org/p/unified-limits-rocky-ptg
[2] https://tinyurl.com/y6ucarwm
[3]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html
[4]
https://review.openstack.org/#/q/project:openstack/oslo.limit+status:open
[5] https://review.openstack.org/#/c/600265/
[6]

Re: [openstack-dev] [election][tc] Announcing candidacy

2018-09-07 Thread Rico Lin
On Fri, Sep 7, 2018 at 9:21 PM Matt Riedemann  wrote:

> On 9/6/2018 1:49 PM, Rico Lin wrote:
> > * Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)
>
> Are there some specific initiatives or deliverables you have in mind
> here, or just general open communication channels? It's very hard to
> gauge any kind of progress/success on the latter.
>

I'm refering on clear communication channels and go from Use cases to real
development tasks (As I try to explain in the last section of my candidacy).
And here's some specific initiatives or deliverables sample I got in mind.
* From StarlingX, some great improvement for Edge cases are delivered to
projects. And there're also communications cross StarlingX and TCs on how
to make it integrated with rest OpenStack projects (currently StarlingX
still using it's own forks of OpenStack projects). And there're other
projects that other organizations contribute to OpenStack or form another
communities that depend on OpenStack.
* We recently create a new repo `openstack-service-broker` [1]. Use Service
Broker (A project from CloudFoundry) expose external resources to
applications running in a PaaS. Which is exactly a integration cross
CloudFoundry and OpenStack (protentially with K8s too) base on specific
scenario.
* K8s as one of the most popular case here, I believe we already can see
some nice integration cross OpenStack and K8s. Include Manila, Keystone
support in K8s, Magnum become one of official deployment tool in K8s
community. Also I'm currently working on Integrate Heat AutoScaling to K8s
cluster autoscaler as well [2].
* OPNFV integrated with OpenStack as it's cluster provider.

So the goal here IMO is `how can we properly set up cross communication and
improve scenarios with use cases or help these scenarios to become
deliverable for user?`.
SIGs are one of the format that I believe can help to accelerate this goal.
As I mentioned in [3] and in goal `Strong the structure of SIGs`. We should
consider to allow SIGs to become that platform from use cases and scenario
to a trackable development tasks. I know there's nothing block a SIG to do
so, but there's also no guideline, structure format, or other resources to
make the path easier for SIG.

Hope these explains wht the goal is in my mind.

[1] https://github.com/openstack/openstack-service-broker
[2] https://github.com/kubernetes/autoscaler/pull/1226
[3]
http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Ben Nemec



On 09/07/2018 11:19 AM, Samuel Cassiba wrote:

On Fri, Sep 7, 2018 at 8:55 AM, Samuel Cassiba  wrote:

On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:

On 9/5/2018 2:49 PM, Samuel Cassiba wrote:


Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.



Are there specific initiatives you plan on pushing forward if on the TC? I'm
thinking about stuff from the laundry list here:

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



Excellent question!

It's not in my nature to push specific agendas. That said, being in
the deploy space, constellations is something that does have a
specific gravity that would, no doubt, draw me in, whether or not I am
part of the TC. I've viewed projects in the deploy space, such aq

Furthering the adoption of secret management is another thing that
hits close to home


...and that would be where an unintended keyboard-seeking Odin attack
preemptively initiates a half-thought thought. It's hard to get upset
at this face, though. https://i.imgur.com/c7tktmO.jpg

To that point, projects like Chef have made use of encrypted secrets
since more or less the dawn of time, but not at all in a portable way.
Continuing the work to bring secrets under a single focus is something
that I would also be a part of, with or without being on the TC.


Just want to note that there is work underway in Oslo to address this. 
The base framework for it merged in Rocky and we plan to have 
integration with Castellan in Stein.


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



In both of these efforts, I envision having some manner of involvement
no matter what. At the strategic level, working to ensure the
disparate efforts are in alignment is where I would gravitate to.

Best,
Samuel

__
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] [election] [tc] TC candidacy

2018-09-07 Thread Samuel Cassiba
On Fri, Sep 7, 2018 at 8:55 AM, Samuel Cassiba  wrote:
> On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:
>> On 9/5/2018 2:49 PM, Samuel Cassiba wrote:
>>>
>>> Though my hands-on experience goes back several releases, I still view
>>> things from the outside-looking-in perspective. Having the outsider
>>> lens is crucial in the long-term for any consensus-driven group,
>>> regardless of that consensus.
>>>
>>> Regardless of the election outcome, this is me taking steps to having a
>>> larger involvement in the overall conversations that drive so much of
>>> our daily lives. At the end of the day, we're all just groups of people
>>> trying to do our jobs. I view this as an opportunity to give back to a
>>> community that has given me so much.
>>
>>
>> Are there specific initiatives you plan on pushing forward if on the TC? I'm
>> thinking about stuff from the laundry list here:
>>
>> https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives
>>
>
> Excellent question!
>
> It's not in my nature to push specific agendas. That said, being in
> the deploy space, constellations is something that does have a
> specific gravity that would, no doubt, draw me in, whether or not I am
> part of the TC. I've viewed projects in the deploy space, such aq
>
> Furthering the adoption of secret management is another thing that
> hits close to home

...and that would be where an unintended keyboard-seeking Odin attack
preemptively initiates a half-thought thought. It's hard to get upset
at this face, though. https://i.imgur.com/c7tktmO.jpg

To that point, projects like Chef have made use of encrypted secrets
since more or less the dawn of time, but not at all in a portable way.
Continuing the work to bring secrets under a single focus is something
that I would also be a part of, with or without being on the TC.

In both of these efforts, I envision having some manner of involvement
no matter what. At the strategic level, working to ensure the
disparate efforts are in alignment is where I would gravitate to.

Best,
Samuel

__
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] [stable][keystone] python3 goal progress and tox_install.sh removal

2018-09-07 Thread Lance Bragstad
Thanks for all the help, everyone. Updating the status of reach repository
and branch with respect to the python3 goal and which reviews are needed in
order to get things squared away. Note that the linked python3 review is
just the one to port the zuul job definitions, and not all patches
generated for the goal. This is because the first patch was triggering the
failure - likely due to the branch being broken by tox_install.sh or new
pip versions among other things. The summary below is a list of things
needed to get the tests passing up to that point, at which point we should
be in a good state to pursue python3 issues if there are any.

Branches in red and bold are in need of reviews, all of which should be
setup to pass tests. If not then they should be dependent on patches to
make them pass.

*keystonemiddleware*
 - master: https://review.openstack.org/#/c/597659/
 - *stable/rocky*: https://review.openstack.org/#/c/597694/
 - *stable/queens*: https://review.openstack.org/#/c/597688/
 - *stable/pike*: https://review.openstack.org/#/c/597682/
 - *stable/ocata*: https://review.openstack.org/#/c/597677/

*keystoneauth*
 - master: https://review.openstack.org/#/c/597655/
 - *stable/rocky*: https://review.openstack.org/#/c/597693/
 - *stable/queens*: https://review.openstack.org/#/c/600564/ needed by
https://review.openstack.org/#/c/597687/
 - *stable/pike*: https://review.openstack.org/#/c/597681/
 - *stable/ocata*: https://review.openstack.org/#/c/598346/ needed by
https://review.openstack.org/#/c/597676/

*python-keystoneclient*
 - master: https://review.openstack.org/#/c/597671/
 - *stable/rocky*: https://review.openstack.org/#/c/597696/
 - *stable/queens*: https://review.openstack.org/#/c/597691/
 - *stable/pike*: https://review.openstack.org/#/c/597685/
 - *stable/ocata*: https://review.openstack.org/#/c/597679/

Hopefully this helps organize things a bit. I was losing my mind
maintaining a mental map.

Let me know if you see anything odd about the above. Otherwise feel free to
give those a review.

Thanks,

Lance

On Fri, Sep 7, 2018 at 2:39 AM Tony Breeds  wrote:

> On Thu, Sep 06, 2018 at 03:01:01PM -0500, Lance Bragstad wrote:
> > I'm noticing some odd cases with respect to the python 3 community goal
> > [0]. So far my findings are specific to keystone repositories, but I can
> > imagine this affecting other projects.
> >
> > Doug generated the python 3 reviews for keystone repositories, including
> > the ones for stable branches. We noticed some issues with the ones
> proposed
> > to stable (keystoneauth, python-keystoneclient) and master
> > (keystonemiddleware). For example, python-keystoneclient's stable/pike
> [1]
> > and stable/ocata [2] branches are both failing with something like [3]:
> >
> > ERROR: You must give at least one requirement to install (see "pip help
> > install")
>
> I've updated 1 and 2 to do the same thing that lots of other repos do
> and just exit 0 in this case.  1 and 2 now have a +1 from zuul.
>
> 
>
> > I've attempted to remove tox_install.sh using several approaches with
> > keystonemiddleware master [7]. None of which passed both unit tests and
> the
> > requirements check.
>
> Doug pointed out the fix here, which I added.  It passed most of the
> gate but failed in an unrelated neutron test so I've rechecked it.
>
> Yours Tony.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Samuel Cassiba
On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:
> On 9/5/2018 2:49 PM, Samuel Cassiba wrote:
>>
>> Though my hands-on experience goes back several releases, I still view
>> things from the outside-looking-in perspective. Having the outsider
>> lens is crucial in the long-term for any consensus-driven group,
>> regardless of that consensus.
>>
>> Regardless of the election outcome, this is me taking steps to having a
>> larger involvement in the overall conversations that drive so much of
>> our daily lives. At the end of the day, we're all just groups of people
>> trying to do our jobs. I view this as an opportunity to give back to a
>> community that has given me so much.
>
>
> Are there specific initiatives you plan on pushing forward if on the TC? I'm
> thinking about stuff from the laundry list here:
>
> https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives
>

Excellent question!

It's not in my nature to push specific agendas. That said, being in
the deploy space, constellations is something that does have a
specific gravity that would, no doubt, draw me in, whether or not I am
part of the TC. I've viewed projects in the deploy space, such aq

Furthering the adoption of secret management is another thing that
hits close to home

__
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] [Openstack] OpenStack Rocky for Ubuntu 18.04 LTS

2018-09-07 Thread Michael Johnson
Corey,

Awesome!  Excited to see Octavia included in the release.

Michael
On Fri, Sep 7, 2018 at 8:19 AM Corey Bryant  wrote:
>
> The Ubuntu OpenStack team at Canonical is pleased to announce the general 
> availability of OpenStack Rocky on Ubuntu 18.04 LTS via the Ubuntu Cloud 
> Archive. Details of the Rocky release can be found at:  
> https://www.openstack.org/software/rocky
>
> To get access to the Ubuntu Rocky packages:
>
> Ubuntu 18.04 LTS
> ---
>
> You can enable the Ubuntu Cloud Archive pocket for OpenStack Rocky on Ubuntu 
> 18.04 installations by running the following commands:
>
> sudo add-apt-repository cloud-archive:rocky
> sudo apt update
>
> The Ubuntu Cloud Archive for Rocky includes updates for:
>
> aodh, barbican, ceilometer, ceph (13.2.1), cinder, designate, 
> designate-dashboard, glance, gnocchi, heat, heat-dashboard, horizon, ironic, 
> keystone, magnum, manila, manila-ui, mistral, murano, murano-dashboard, 
> networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, 
> networking-odl, networking-ovn, networking-sfc, neutron, 
> neutron-dynamic-routing, neutron-fwaas, neutron-lbaas, 
> neutron-lbaas-dashboard, neutron-vpnaas, nova, nova-lxd, octavia, 
> openstack-trove, openvswitch (2.10.0), panko, sahara, sahara-dashboard, 
> senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.
>
> For a full list of packages and versions, please refer to:
> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/rocky_versions.html
>
> Python 3 support
> -
> Python 3 packages are now available for all of the above packages except 
> swift. All of these packages have successfully been unit tested with at least 
> Python 3.6. Function testing is ongoing and fixes will continue to be 
> backported to Rocky.
>
> Python 3 enablement
> --
> In Rocky, Python 2 packages will still be installed by default for all 
> packages except gnocchi and octavia, which are Python 3 by default. In a 
> future release, we will switch all packages to Python 3 by default.
>
> To enable Python 3 for existing installations:
> # upgrade to latest Rocky package versions first, then:
> sudo apt install python3- [1]
> sudo apt install libapache2-mod-wsgi-py3  # not required for all packages 
> [2]
> sudo apt purge python- [1]
> sudo apt autoremove --purge
> sudo systemctl restart -*
> sudo systemctl restart apache2  # not required for all packages [2]
>
> For example:
> sudo apt install aodh-*
> sudo apt install python3-aodh libapache2-mod-wsgi-py3
> sudo apt purge python-aodh
> sudo apt autoremove --purge
> sudo systemctl restart aodh-* apache2
>
> To enable Python 3 for new installations:
> sudo apt install python3- [1]
> sudo apt install libapache2-mod-wsgi-py3  # not required for all packages 
> [2]
> sudo apt install -
>
> For example:
> sudo apt install python3-aodh libapache2-mod-wsgi-py3 aodh-api
>
> [1] The naming convention of python packages is generally python- 
> and python3-. For horizon, however, the packages are named 
> python-django-horizon and python3-django-horizon.
>
> [2] The following packages are run under apache2 and require installation of 
> libapache2-mod-wsgi-py3 to enable Python 3 support:
> aodh-api, cinder-api, barbican-api, keystone, nova-placement-api, 
> openstack-dashboard, panko-api, sahara-api
>
> Other notable changes
> 
> sahara-api: sahara API now runs under apache2 with mod_wsgi
>
> Branch Package Builds
> -
> If you would like to try out the latest updates to branches, we deliver 
> continuously integrated packages on each upstream commit via the following 
> PPA’s:
>
> sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
> sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
> sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
> sudo add-apt-repository ppa:openstack-ubuntu-testing/queens
> sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky
>
> Reporting bugs
> ---
> If you have any issues please report bugs using the 'ubuntu-bug' tool to 
> ensure that bugs get logged in the right place in Launchpad:
>
> sudo ubuntu-bug nova-conductor
>
> Thanks to everyone who has contributed to OpenStack Rocky, both upstream and 
> downstream. Special thanks to the Puppet OpenStack modules team and the 
> OpenStack Charms team for their continued early testing of the Ubuntu Cloud 
> Archive, as well as the Ubuntu and Debian OpenStack teams for all of their 
> contributions.
>
> Have fun and see you in Stein!
>
> Cheers,
> Corey
> (on behalf of the Ubuntu OpenStack team)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

[openstack-dev] [goals][python3][ptl] ptg discussions about python3 goal

2018-09-07 Thread Doug Hellmann
Based on some feedback for goal champions from the last PTG, I
thought it would be a good idea to be explicit about the best way
to reach me in case your team has questions about the python3 goal
(unfortunately I'm the only champion for that goal who is able to
be at the PTG this time).

There is an "ask me anything" help room available on Monday and
Tuesday, but looking at the list of other things going on then I'm
likely to have a pretty full schedule those two days.  I'm booked
all day on Friday, so it's going to work best for you to let me
know where and when on Wednesday or Thursday you would like to talk,
and I will come to you. Try to give me more than a few minutes
notice.  :-)

If you email me directly at d...@doughellmann.com it will go to my
phone. Twitter mentions or DMs @doughellmann will also go to my
phone.  IRC mentions (dhellmann in #openstack-dev) will rely on me
being online, which is less likely if I'm in a session.

Doug

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


Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

2018-09-07 Thread Jay Pipes

On 09/07/2018 11:17 AM, Dan Smith wrote:

The other obvious thing is the database. The placement repo code as-is
today still has the check for whether or not it should use the
placement database but falls back to using the nova_api database
[5]. So technically you could point the extracted placement at the
same nova_api database and it should work. However, at some point
deployers will clearly need to copy the placement-related tables out
of the nova_api DB to a new placement DB and make sure the
'migrate_version' table is dropped so that placement DB schema
versions can reset to 1.


I think it's wrong to act like placement and nova-api schemas are the
same. One is a clone of the other at a point in time, and technically it
will work today. However the placement db sync tool won't do the right
thing, and I think we run the major risk of operators not fully grokking
what is going on here, seeing that pointing placement at nova-api
"works" and move on. Later, when we add the next placement db migration
(which could technically happen in stein), they will either screw their
nova-api schema, or mess up their versioning, or be unable to apply the
placement change.


With respect to grenade and making this work in our own upgrade CI
testing, we have I think two options (which might not be mutually
exclusive):

1. Make placement support using nova.conf if placement.conf isn't
found for Stein with lots of big warnings that it's going away in
T. Then Rocky nova.conf with the nova_api database configuration just
continues to work for placement in Stein. I don't think we then have
any grenade changes to make, at least in Stein for upgrading *from*
Rocky. Assuming fresh devstack installs in Stein use placement.conf
and a placement-specific database, then upgrades from Stein to T
should also be OK with respect to grenade, but likely punts the
cut-over issue for all other deployment projects (because we don't CI
with grenade doing Rocky->Stein->T, or FFU in other words).


As I have said above and in the review, I really think this is the wrong
approach. At the current point of time, the placement schema is a clone
of the nova-api schema, and technically they will work. At the first point
that placement evolves its schema, that will no longer be a workable
solution, unless we also evolve nova-api's database in lockstep.


2. If placement doesn't support nova.conf in Stein, then grenade will
require an (exceptional) [6] from-rocky upgrade script which will (a)
write out placement.conf fresh and (b) run a DB migration script,
likely housed in the placement repo, to create the placement database
and copy the placement-specific tables out of the nova_api
database. Any script like this is likely needed regardless of what we
do in grenade because deployers will need to eventually do this once
placement would drop support for using nova.conf (if we went with
option 1).


Yep, and I'm asserting that we should write that script, make grenade do
that step, and confirm that it works. I think operators should do that
step during the stein upgrade because that's where the fork/split of
history and schema is happening. I'll volunteer to do the grenade side
at least.

Maybe it would help to call out specifically that, IMHO, this can not
and should not follow the typical config deprecation process. It's not a
simple case of just making sure we "find" the nova-api database in the
various configs. The problem is that _after_ the split, they are _not_
the same thing and should not be considered as the same. Thus, I think
to avoid major disaster and major time sink for operators later, we need
to impose the minor effort now to make sure that they don't take the
process of deploying a new service lightly.

Jay's original relatively small concern was that deploying a new
placement service and failing to properly configure it would result in a
placement running with the default, empty, sqlite database. That's a
valid concern, and I think all we need to do is make sure we fail in
that case, explaining the situation.

We just had a hangout on the topic and I think we've come around to the
consensus that just removing the default-to-empty-sqlite behavior is the
right thing to do. Placement won't magically find nova.conf if it exists
and jump into its database, and it also won't do the silly thing of
starting up with an empty database if the very important config step is
missed in the process of deploying placement itself. Operators will have
to deploy the new package and do the database surgery (which we will
provide instructions and a script for) as part of that process, but
there's really no other sane alternative without changing the current
agreed-to plan regarding the split.

Is everyone okay with the above summary of the outcome?


Yes from my perspective.

-jay

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

[openstack-dev] [cinder][ptg] Topics scheduled for next week ...

2018-09-07 Thread Jay S Bryant

Team,

I have created an etherpad for each of the days of the PTG and split out 
the proposed topics from the planning etherpad into the individual days 
for discussion: [1] [2] [3]


If you want to add an additional topic please add it to Friday or find 
some time on one of the other days.


I look forward to discussing all these topics with you all next week.

Thanks!

Jay

[1] https://etherpad.openstack.org/p/cinder-ptg-stein-wednesday

[2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday

[3] https://etherpad.openstack.org/p/cinder-ptg-stein-friday


__
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] [cinder][placement] Room Scheduled for Cinder Placement Discussion ...

2018-09-07 Thread Jay S Bryant

All,

The results of the Doodle poll suggested that the end of the day Tuesday 
was the best option for us all to get together. [1]


I have scheduled the Big Thompson Room on Tuesday from 15:15 to 17:00.

I hope we can all get together there and then to have a good discussion.

Thanks!

Jay

[1] https://doodle.com/poll/4twwhy46bxerrthx#table


__
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] [tempest][CI][nova compute] Skipping non-compute-driver tests

2018-09-07 Thread William M Edmonds

Ghanshyam Mann  wrote on 09/07/2018 02:18:13 AM:

snip..

> neutron-tempest-plugin or other service test you can always avoid to
> run with regex. And i do not think compute negative or DB test will
> take much time to run. But still if you want to avoid to run then, I
> think it is easy to maintain a whitelist regex file on CI side which
> can run only compute driver tests(61 in this case).
>
> Tagging compute driver on tempest side is little hard to maintain i
> feel and it can goes out of date very easily. If you have any other
> idea on that, we can surly talk in PTG on this.

The concern that I have with whitelisting in a given CI is that it has to
be done independently in every compute driver CI. So while I agree that it
won't be easy to maintain tagging for compute driver on the tempest side,
at least that's one place / easier than doing it in every driver CI. When
anyone figures out that an change is needed, all of the CIs would benefit
together if there is a shared solution.
__
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][upgrade][qa] Some upgrade-specific news on extraction

2018-09-07 Thread Mohammed Naser
On Fri, Sep 7, 2018 at 11:18 AM Dan Smith  wrote:
>
> > The other obvious thing is the database. The placement repo code as-is
> > today still has the check for whether or not it should use the
> > placement database but falls back to using the nova_api database
> > [5]. So technically you could point the extracted placement at the
> > same nova_api database and it should work. However, at some point
> > deployers will clearly need to copy the placement-related tables out
> > of the nova_api DB to a new placement DB and make sure the
> > 'migrate_version' table is dropped so that placement DB schema
> > versions can reset to 1.
>
> I think it's wrong to act like placement and nova-api schemas are the
> same. One is a clone of the other at a point in time, and technically it
> will work today. However the placement db sync tool won't do the right
> thing, and I think we run the major risk of operators not fully grokking
> what is going on here, seeing that pointing placement at nova-api
> "works" and move on. Later, when we add the next placement db migration
> (which could technically happen in stein), they will either screw their
> nova-api schema, or mess up their versioning, or be unable to apply the
> placement change.
>
> > With respect to grenade and making this work in our own upgrade CI
> > testing, we have I think two options (which might not be mutually
> > exclusive):
> >
> > 1. Make placement support using nova.conf if placement.conf isn't
> > found for Stein with lots of big warnings that it's going away in
> > T. Then Rocky nova.conf with the nova_api database configuration just
> > continues to work for placement in Stein. I don't think we then have
> > any grenade changes to make, at least in Stein for upgrading *from*
> > Rocky. Assuming fresh devstack installs in Stein use placement.conf
> > and a placement-specific database, then upgrades from Stein to T
> > should also be OK with respect to grenade, but likely punts the
> > cut-over issue for all other deployment projects (because we don't CI
> > with grenade doing Rocky->Stein->T, or FFU in other words).
>
> As I have said above and in the review, I really think this is the wrong
> approach. At the current point of time, the placement schema is a clone
> of the nova-api schema, and technically they will work. At the first point
> that placement evolves its schema, that will no longer be a workable
> solution, unless we also evolve nova-api's database in lockstep.
>
> > 2. If placement doesn't support nova.conf in Stein, then grenade will
> > require an (exceptional) [6] from-rocky upgrade script which will (a)
> > write out placement.conf fresh and (b) run a DB migration script,
> > likely housed in the placement repo, to create the placement database
> > and copy the placement-specific tables out of the nova_api
> > database. Any script like this is likely needed regardless of what we
> > do in grenade because deployers will need to eventually do this once
> > placement would drop support for using nova.conf (if we went with
> > option 1).
>
> Yep, and I'm asserting that we should write that script, make grenade do
> that step, and confirm that it works. I think operators should do that
> step during the stein upgrade because that's where the fork/split of
> history and schema is happening. I'll volunteer to do the grenade side
> at least.
>
> Maybe it would help to call out specifically that, IMHO, this can not
> and should not follow the typical config deprecation process. It's not a
> simple case of just making sure we "find" the nova-api database in the
> various configs. The problem is that _after_ the split, they are _not_
> the same thing and should not be considered as the same. Thus, I think
> to avoid major disaster and major time sink for operators later, we need
> to impose the minor effort now to make sure that they don't take the
> process of deploying a new service lightly.

I think that's a valid different approach.  I'd be okay with this if
the appropriate
scripts and documentation is out there.  In this case, Grenade stuff
will be really
useful asset to look over upgrades with.

> Jay's original relatively small concern was that deploying a new
> placement service and failing to properly configure it would result in a
> placement running with the default, empty, sqlite database. That's a
> valid concern, and I think all we need to do is make sure we fail in
> that case, explaining the situation.

If it's a hard fail, that seems reasonable and ensures no surprises occur
during the upgrade or much later.

> We just had a hangout on the topic and I think we've come around to the
> consensus that just removing the default-to-empty-sqlite behavior is the
> right thing to do. Placement won't magically find nova.conf if it exists
> and jump into its database, and it also won't do the silly thing of
> starting up with an empty database if the very important config step is
> missed in the process of deploying placement 

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

2018-09-07 Thread Dan Smith
> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the
> placement database but falls back to using the nova_api database
> [5]. So technically you could point the extracted placement at the
> same nova_api database and it should work. However, at some point
> deployers will clearly need to copy the placement-related tables out
> of the nova_api DB to a new placement DB and make sure the
> 'migrate_version' table is dropped so that placement DB schema
> versions can reset to 1.

I think it's wrong to act like placement and nova-api schemas are the
same. One is a clone of the other at a point in time, and technically it
will work today. However the placement db sync tool won't do the right
thing, and I think we run the major risk of operators not fully grokking
what is going on here, seeing that pointing placement at nova-api
"works" and move on. Later, when we add the next placement db migration
(which could technically happen in stein), they will either screw their
nova-api schema, or mess up their versioning, or be unable to apply the
placement change.

> With respect to grenade and making this work in our own upgrade CI
> testing, we have I think two options (which might not be mutually
> exclusive):
>
> 1. Make placement support using nova.conf if placement.conf isn't
> found for Stein with lots of big warnings that it's going away in
> T. Then Rocky nova.conf with the nova_api database configuration just
> continues to work for placement in Stein. I don't think we then have
> any grenade changes to make, at least in Stein for upgrading *from*
> Rocky. Assuming fresh devstack installs in Stein use placement.conf
> and a placement-specific database, then upgrades from Stein to T
> should also be OK with respect to grenade, but likely punts the
> cut-over issue for all other deployment projects (because we don't CI
> with grenade doing Rocky->Stein->T, or FFU in other words).

As I have said above and in the review, I really think this is the wrong
approach. At the current point of time, the placement schema is a clone
of the nova-api schema, and technically they will work. At the first point
that placement evolves its schema, that will no longer be a workable
solution, unless we also evolve nova-api's database in lockstep.

> 2. If placement doesn't support nova.conf in Stein, then grenade will
> require an (exceptional) [6] from-rocky upgrade script which will (a)
> write out placement.conf fresh and (b) run a DB migration script,
> likely housed in the placement repo, to create the placement database
> and copy the placement-specific tables out of the nova_api
> database. Any script like this is likely needed regardless of what we
> do in grenade because deployers will need to eventually do this once
> placement would drop support for using nova.conf (if we went with
> option 1).

Yep, and I'm asserting that we should write that script, make grenade do
that step, and confirm that it works. I think operators should do that
step during the stein upgrade because that's where the fork/split of
history and schema is happening. I'll volunteer to do the grenade side
at least.

Maybe it would help to call out specifically that, IMHO, this can not
and should not follow the typical config deprecation process. It's not a
simple case of just making sure we "find" the nova-api database in the
various configs. The problem is that _after_ the split, they are _not_
the same thing and should not be considered as the same. Thus, I think
to avoid major disaster and major time sink for operators later, we need
to impose the minor effort now to make sure that they don't take the
process of deploying a new service lightly.

Jay's original relatively small concern was that deploying a new
placement service and failing to properly configure it would result in a
placement running with the default, empty, sqlite database. That's a
valid concern, and I think all we need to do is make sure we fail in
that case, explaining the situation.

We just had a hangout on the topic and I think we've come around to the
consensus that just removing the default-to-empty-sqlite behavior is the
right thing to do. Placement won't magically find nova.conf if it exists
and jump into its database, and it also won't do the silly thing of
starting up with an empty database if the very important config step is
missed in the process of deploying placement itself. Operators will have
to deploy the new package and do the database surgery (which we will
provide instructions and a script for) as part of that process, but
there's really no other sane alternative without changing the current
agreed-to plan regarding the split.

Is everyone okay with the above summary of the outcome?

--Dan

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

[openstack-dev] [Openstack] OpenStack Rocky for Ubuntu 18.04 LTS

2018-09-07 Thread Corey Bryant
The Ubuntu OpenStack team at Canonical is pleased to announce the general
availability of OpenStack Rocky on Ubuntu 18.04 LTS via the Ubuntu Cloud
Archive. Details of the Rocky release can be found at:
https://www.openstack.org/software/rocky

To get access to the Ubuntu Rocky packages:

Ubuntu 18.04 LTS
---

You can enable the Ubuntu Cloud Archive pocket for OpenStack Rocky on
Ubuntu 18.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:rocky
sudo apt update

The Ubuntu Cloud Archive for Rocky includes updates for:

aodh, barbican, ceilometer, ceph (13.2.1), cinder, designate,
designate-dashboard, glance, gnocchi, heat, heat-dashboard, horizon,
ironic, keystone, magnum, manila, manila-ui, mistral, murano,
murano-dashboard, networking-bagpipe, networking-bgpvpn, networking-hyperv,
networking-l2gw, networking-odl, networking-ovn, networking-sfc, neutron,
neutron-dynamic-routing, neutron-fwaas, neutron-lbaas,
neutron-lbaas-dashboard, neutron-vpnaas, nova, nova-lxd, octavia,
openstack-trove, openvswitch (2.10.0), panko, sahara, sahara-dashboard,
senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.

For a full list of packages and versions, please refer to:
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/rocky_versions.html

Python 3 support
-
Python 3 packages are now available for all of the above packages except
swift. All of these packages have successfully been unit tested with at
least Python 3.6. Function testing is ongoing and fixes will continue to be
backported to Rocky.

Python 3 enablement
--
In Rocky, Python 2 packages will still be installed by default for all
packages except gnocchi and octavia, which are Python 3 by default. In a
future release, we will switch all packages to Python 3 by default.

To enable Python 3 for existing installations:
# upgrade to latest Rocky package versions first, then:
sudo apt install python3- [1]
sudo apt install libapache2-mod-wsgi-py3  # not required for all
packages [2]
sudo apt purge python- [1]
sudo apt autoremove --purge
sudo systemctl restart -*
sudo systemctl restart apache2  # not required for all packages [2]

For example:
sudo apt install aodh-*
sudo apt install python3-aodh libapache2-mod-wsgi-py3
sudo apt purge python-aodh
sudo apt autoremove --purge
sudo systemctl restart aodh-* apache2

To enable Python 3 for new installations:
sudo apt install python3- [1]
sudo apt install libapache2-mod-wsgi-py3  # not required for all
packages [2]
sudo apt install -

For example:
sudo apt install python3-aodh libapache2-mod-wsgi-py3 aodh-api

[1] The naming convention of python packages is generally python-
and python3-. For horizon, however, the packages are named
python-django-horizon and python3-django-horizon.

[2] The following packages are run under apache2 and require installation
of libapache2-mod-wsgi-py3 to enable Python 3 support:
aodh-api, cinder-api, barbican-api, keystone, nova-placement-api,
openstack-dashboard, panko-api, sahara-api

Other notable changes

sahara-api: sahara API now runs under apache2 with mod_wsgi

Branch Package Builds
-
If you would like to try out the latest updates to branches, we deliver
continuously integrated packages on each upstream commit via the following
PPA’s:

sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
sudo add-apt-repository ppa:openstack-ubuntu-testing/queens
sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky

Reporting bugs
---
If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thanks to everyone who has contributed to OpenStack Rocky, both upstream
and downstream. Special thanks to the Puppet OpenStack modules team and the
OpenStack Charms team for their continued early testing of the Ubuntu Cloud
Archive, as well as the Ubuntu and Debian OpenStack teams for all of their
contributions.

Have fun and see you in Stein!

Cheers,
Corey
(on behalf of the Ubuntu OpenStack team)
__
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-job-failures] Release of openstack/networking-ansible failed

2018-09-07 Thread Doug Hellmann
Excerpts from zuul's message of 2018-09-07 12:05:20 +:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/63/639a3c3590ec20c33b1435e960d5331780298915/release/release-openstack-python/f485e0f/
>  : POST_FAILURE in 7m 15s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> - trigger-readthedocs-webhook 
> http://logs.openstack.org/63/639a3c3590ec20c33b1435e960d5331780298915/release/trigger-readthedocs-webhook/b1705ca/
>  : FAILURE in 1m 33s
> 

Based on the error at [1], it looks like someone is manually
publishing releases from openstack/networking-ansible and then
tagging them, instead of letting the release machinery publish based
on the tag.

Doug

[1] 
http://logs.openstack.org/63/639a3c3590ec20c33b1435e960d5331780298915/release/release-openstack-python/f485e0f/job-output.txt.gz#_2018-09-07_12_04_51_151414

__
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] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

2018-09-07 Thread Matthew Thode
On 18-09-07 11:09:15, Julien Danjou wrote:
> On Fri, Sep 07 2018, Tony Breeds wrote:
> 
> > On Thu, Sep 06, 2018 at 01:33:12PM +0300, Michel Peterson wrote:
> >
> >> I remember that before landing the problematic patch [1] there was some
> >> discussion around it. Basically the problem was not n-odl but ceilometer
> >> not being in pypi, but we never foresaw this problem.
> >> 
> >> Now that the problem is so critical, the question is how can we, from the
> >> n-odl team, help in fixing this? I am open to help in any effort that
> >> involves n-odl or any other project.
> >
> > As other have pointed out we can just ask the Telemetry team (PTL on CC)
> > why we can't publish ceilometer to pypi?
> 
> You can, I've already said +1 on a review a few weeks ago. :)
> 

Mind linking?  I can't find it.

> > https://pypi.org/project/ceilometer/ certainly seems to be the right
> > project.
> >
> > The crux of the code issue is:
> > from ceilometer.network.statistics import driver
> >
> > in networking_odl/ceilometer/network/statistics/opendaylight_v2/driver.py
> >
> > If this is supposed to be used they way you are how are prjects supposed
> > to get the ceilometer code?
> >

-- 
Matthew Thode


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


Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Zhipeng Huang
Well nova-cyborg is surely on the top-priority for OpenStack cross-project
collaboration. The two initiatives I mentioned is more in the field of
cross-community.

I think I didn't elaborate on how the TC role fit in this picture. For TC I
think it is important to be able to help on the cross community
collaboration, one community is intimidating enough, let alone venture into
totally different communities.

With that said, other than the two directions that I will personally
involve myself with, I will also help other cross community
ideas/initiatives to build relationship and get work done. I guess it is
more convincing when you as a TC member have actually skin in the game in
cross-community development.

So yes individual team will probably the best ones to drive such
collaborations, but it would also be nice to have TC lend a hand when there
is need :)

On Fri, Sep 7, 2018 at 10:17 PM Matt Riedemann  wrote:

> On 9/7/2018 8:54 AM, Zhipeng Huang wrote:
> > One is related to the cyborg project where the team is working to build
> > the open heterogenous resource mgmt platform. I would like to extend
> > this mission over to kubernetes, which currently lack of such component
> > and could benefit hugely from our work here in OpenStack. There are also
> > other communities like OPNFV where the edge cloud project, the C-RAN
> > project and Rocket project will be integrating and testing cyborg, as
> > well as ONNX where AI models will meet the resource models we defined in
> > Cyborg for NPUs and GPUs and FPGAs and whatever hardware should be
> chosen.
>
> I'd like to actually see some progress made on cyborg/nova integration
> before we get our hopes up about cyborg/something completely outside of
> openstack integration, but that's my biased view on it from being a nova
> person. See [1] for context from a discussion yesterday. I don't really
> know how the TC drives this more than the cyborg team themselves, but OK.
>
> [1]
>
> http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-09-06-14.00.log.html#l-120
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] modified devstack using openstack/placement

2018-09-07 Thread Matt Riedemann

On 9/6/2018 5:05 AM, Chris Dent wrote:

One question I have on the lib/placement changes in devstack: Is it
useful to make those changes be guarded by a conditional of the
form:

    if placement came from its own repo:
    do the new stuff
    else:
    do the old stuff

?


I think it would be mostly confusing if this is 
conditional/configurable. For example, if the nova-next job was changed 
to use placement from the placement repo, but the integrated gate jobs 
(tempest-full) were still all using placement from nova. I think we need 
to get to the point where we're ready to flip that switch to CI against 
the placement repo and then deal with the fallout.


--

Thanks,

Matt

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


Re: [openstack-dev] [Kolla] Denver PTG schedule

2018-09-07 Thread Mark Goddard
Looks like the ironic and kolla rooms are next to each other this time, so
I can hop between them to help setup the conferencing etc.

On Fri, 7 Sep 2018 at 15:21, Mark Goddard  wrote:

> Thanks for putting that together Eduardo. I've listed the sessions that I
> expect to attend below.
> Mark
>
> On Thu, 6 Sep 2018 at 17:40, Eduardo Gonzalez  wrote:
>
>> Hi folks,
>> This is the schedule for Kolla Denver PTG. If someone have a hard
>> conflict with any discussion please let me know if we can find a slot which
>> matches better.
>>
>> Wednesday
>> 3:10 - 3:55 [kolla-ansible] DRY ansible
>> 4:00 - 4:45 [kolla-ansible] Kayobe
>>
>> Thursday
>> 9:50 - 10:35 [kolla-ansible] Firewall configuration
>> 10.40 - 11:15 [kolla-ansible] Fast-forward upgrade
>> 11:20 - 12:00 [kolla-ansible] Multi release support
>> 12:00 - 13:30 LUNCH
>> 1:30 - 2:15 [kolla-ansible] Cells v2
>> 2:20 - 3:05 [kolla-ansible] Running kolla at scale
>> ?
>> 3:10 - 3:55 Kolla GUI
>> 4:00 - 4:45 PTG recap and Stein priority setting
>>
>> Friday
>> 9:00 - 9:45 [CI] Service testing and scenarios
>> 9:50 - 10:35 [CI] Upgrade jobs
>> 10.40 - 11:15 [CI] Usage of tempest and rally
>> 11:20 - 12:00 Define PTG TODOs (blueprints, specs, etc)
>> 12:00 - 13:30 LUNCH
>>
>> Regards
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Kolla] Denver PTG schedule

2018-09-07 Thread Mark Goddard
Thanks for putting that together Eduardo. I've listed the sessions that I
expect to attend below.
Mark

On Thu, 6 Sep 2018 at 17:40, Eduardo Gonzalez  wrote:

> Hi folks,
> This is the schedule for Kolla Denver PTG. If someone have a hard conflict
> with any discussion please let me know if we can find a slot which matches
> better.
>
> Wednesday
> 3:10 - 3:55 [kolla-ansible] DRY ansible
> 4:00 - 4:45 [kolla-ansible] Kayobe
>
> Thursday
> 9:50 - 10:35 [kolla-ansible] Firewall configuration
> 10.40 - 11:15 [kolla-ansible] Fast-forward upgrade
> 11:20 - 12:00 [kolla-ansible] Multi release support
> 12:00 - 13:30 LUNCH
> 1:30 - 2:15 [kolla-ansible] Cells v2
> 2:20 - 3:05 [kolla-ansible] Running kolla at scale
> ?
> 3:10 - 3:55 Kolla GUI
> 4:00 - 4:45 PTG recap and Stein priority setting
>
> Friday
> 9:00 - 9:45 [CI] Service testing and scenarios
> 9:50 - 10:35 [CI] Upgrade jobs
> 10.40 - 11:15 [CI] Usage of tempest and rally
> 11:20 - 12:00 Define PTG TODOs (blueprints, specs, etc)
> 12:00 - 13:30 LUNCH
>
> Regards
> __
> 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] [election] [tc] TC candidacy

2018-09-07 Thread Matt Riedemann

On 9/7/2018 8:54 AM, Zhipeng Huang wrote:
One is related to the cyborg project where the team is working to build 
the open heterogenous resource mgmt platform. I would like to extend 
this mission over to kubernetes, which currently lack of such component 
and could benefit hugely from our work here in OpenStack. There are also 
other communities like OPNFV where the edge cloud project, the C-RAN 
project and Rocket project will be integrating and testing cyborg, as 
well as ONNX where AI models will meet the resource models we defined in 
Cyborg for NPUs and GPUs and FPGAs and whatever hardware should be chosen.


I'd like to actually see some progress made on cyborg/nova integration 
before we get our hopes up about cyborg/something completely outside of 
openstack integration, but that's my biased view on it from being a nova 
person. See [1] for context from a discussion yesterday. I don't really 
know how the TC drives this more than the cyborg team themselves, but OK.


[1] 
http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-09-06-14.00.log.html#l-120


--

Thanks,

Matt

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


[openstack-dev] [nova][placement] No NovaScheduler meeting during PTG

2018-09-07 Thread Eric Fried
Our regularly scheduled Monday nova-scheduler meeting will not take
place next Monday, Sept 10th. We'll resume the following week.

-efried

__
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][upgrade][qa] Some upgrade-specific news on extraction

2018-09-07 Thread Matt Riedemann

On 9/6/2018 8:29 PM, Erik McCormick wrote:
We are planning to attend the upgrade sessions on Monday as a group. How 
about we put it there?


I threw it in the upgrades sig ptg etherpad. Where it goes in the agenda 
on Monday afternoon is up to you guys.


--

Thanks,

Matt

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


[openstack-dev] [keystone] 2018 User Survey Results

2018-09-07 Thread Lance Bragstad
The foundation just gave me a copy of the latest feedback from our users. I
wanted to share this with the group so people have time to digest it prior
to the PTG next week [0].

Here is the total count based on each response:

Federated identity enhancements had *184* responses

Performance improvements had *144* responses

Scaling out to multiple regions had *136* responses

Enhancing policy had *92* responses

Per domain configuration had *79* responses


Next Wednesday I have a time slot set aside to go through the results as a
group. Otherwise we can use the time to refine the questions we present in
the survey, since they haven't changed in years (I think Steve put the ones
we have today in place).


The script I used to count each occurrence is available [1] in case you
recently received survey results and want to parse them in a similar
fashion.


[0]
https://docs.google.com/spreadsheets/d/1wz-GOoFODGWrFuGqVWDunEWsuhC_lvRJLrfUybTj69Q/edit?usp=sharing

[1] https://gist.github.com/lbragstad/a812df72494ffbbbc8c742f4d90333d5
__
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] [election] [tc] TC candidacy

2018-09-07 Thread Zhipeng Huang
Thx Matt,

I think as I described in the candidacy patch, there two specific areas
that I would like to do the cross-community collaboration.

One is related to the cyborg project where the team is working to build the
open heterogenous resource mgmt platform. I would like to extend this
mission over to kubernetes, which currently lack of such component and
could benefit hugely from our work here in OpenStack. There are also other
communities like OPNFV where the edge cloud project, the C-RAN project and
Rocket project will be integrating and testing cyborg, as well as ONNX
where AI models will meet the resource models we defined in Cyborg for NPUs
and GPUs and FPGAs and whatever hardware should be chosen.

The other one is policy which related to the Kubernetes Policy WG I'm
leading and the CNCF Security WG which is under voting from ToC to take
shape. We have great policy in code implementation in Keystone and I'm keen
on investigating on how should that impact Kubernetes or Istio or SPIFEE
when we stack them up.

Of course there are other areas that i'm also working on which bridges
communities, one such example is the cloud ledger idea proposed for public
cloud wg involves collaboration with Ethereum Classic community, and
hopefully Hyperledger and others in the near future. However this is a long
term effort compared to the above mentioned two aspects.

Hope that answers the question :)

On Fri, Sep 7, 2018 at 9:34 PM Matt Riedemann  wrote:

> On 9/5/2018 6:49 PM, Zhipeng Huang wrote:
> > I found that most of my statement for my last ran is still valid today
> > [0][1]. I want to build strong cross-community collaboration, best
> > practices for project level governance and more innovations for
> OpenStack.
>
> As I asked Rico, are there specific cross-community initiatives or
> deliverables you plan on working on, or just having open dialog? Because
> the latter doesn't mean much to me personally. If the former, can you
> point some out?
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [placement] update 18-36

2018-09-07 Thread Chris Dent


HTML: https://anticdent.org/placement-update-18-36.html

Welcome back to the placement update. The last one was [5 weeks
ago](https://anticdent.org/placement-update-18-31.html). I took a
break to focus on some other things for a while. I plan to make it
a regular thing again, but will be skipping next week for the PTG.

The big news is that there is now a [placement
repository](https://git.openstack.org/cgit/openstack/placement).
That's the thing I was focussing on. [Work is
progressing](https://review.openstack.org/#/q/project:openstack/placement)
to get it healthy and happy.

Because of that, henceforth the shape of this update will change a
bit. If I'm able to find them, I'm going to try to include anything
that directly relates to placement. Primarily this will be stuff in
the placement repo itself, and related changes in nova, but
hopefully it will also include work in Blazar, Cyborg, Neutron, Zun
and other projects that are either already working with placement or
planning to do so soon. I can't see everything though so if I miss
something, please let me know. For this edition I'm not going to go
out of my way to report on individual reviews, rather set the stage
for the future.

# Most Important

If you're going to be at the PTG next week there will be plenty to
talk about related to placement.

* On Monday between 2-3pm Cyborg, Nova, and Placement -interested
  people will meet in the Cyborg room. 
* On Tuesday 10am it's with Blazar.

* Sometime, maybe Tuesday afternoon (TBD), with Cinder.
* Much of Wednesday: in the Nova room to discuss Placement (the
  service) and placement (the process) -related topics.

The other pending issues are related to upgrades (from-nova,
to-placement), migrating existing data, and management of schema
migrations. Matt [posted a summary of some of
that](http://lists.openstack.org/pipermail/openstack-dev/2018-September/134395.html)
to get feedback from the wider community.

# What's Changed

openstack/placement

Propose your changes to placement there, not nova. Nova still has
placement code within itself, but for the time being the placement
parts are 
[frozen](http://lists.openstack.org/pipermail/openstack-dev/2018-August/134042.html).

# Bugs

For now, bugs are still being tracked under nova using the tag
`placement`. There will likely be some changes in this, but it
works for now. There's also an etherpad where [cleanups and
todos](https://etherpad.openstack.org/p/placement-extract-stein-3)
are being remembered.

* Placement related [bugs not yet in progress](https://goo.gl/TgiPXb):
  17.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 10.

# Specs

It's that time in the cycle, so let's have a specs section. This
currently includes proposals in nova-specs (where placement-service-related
specs will live for a while). In the future it will also have any
other stuff I can find out there in the world.

* 
  Account for host agg allocation ratio in placement
  (Still in rocky/)

* 
  Placement: any traits in allocation_candidate query

* 
  Add subtree filter for GET /resource_providers

* 
  Network bandwidth resource provider

* 
  Resource provider - request group mapping in allocation candidate

* 
  Placement: support mixing required traits with any traits

* 
  VMware: place instances on resource pool
  (still in rocky/)

* 
  Standardize CPU resource tracking

* 
  Allow overcommit of dedicated CPU
  (Has an alternative which changes allocations to a float)

* 
  List resource providers having inventory

* 
  Bi-directional enforcement of traits

* 
  allow transferring ownership of instance

* 
  Placement model for passthrough devices

* 
  Propose counting quota usage from placement and API database
  (A bit out of date but may be worth resurrecting)

# Main Themes

We'll figure out what the main themes are next week at the PTG, once
that happens this section will have more. In the meantime:

## Reshape Provider Trees

Testing of the `/reshaper` from libvirt and xen drivers is showing
some signs of success moving VGPU inventory from the compute node to
a child provider.

## Consumer Generations

There continues to be work in progress on the nova side to make best
use of consumer generations.

See: 

# Other

The placement repo is currently small enough that looking at [all
open 

Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Matt Riedemann

On 9/5/2018 6:49 PM, Zhipeng Huang wrote:
I found that most of my statement for my last ran is still valid today 
[0][1]. I want to build strong cross-community collaboration, best 
practices for project level governance and more innovations for OpenStack.


As I asked Rico, are there specific cross-community initiatives or 
deliverables you plan on working on, or just having open dialog? Because 
the latter doesn't mean much to me personally. If the former, can you 
point some out?


--

Thanks,

Matt

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


Re: [openstack-dev] [election][tc] announcing candidacy

2018-09-07 Thread Matt Riedemann

On 9/4/2018 7:30 AM, Doug Hellmann wrote:

I am announcing my candidacy for a position on the OpenStack
Technical Committee.

I started contributing to OpenStack in 2012, not long after joining
Dreamhost, and I am currently employed by Red Hat to work on OpenStack
with a focus on long-term project concerns. I have served on the
Technical Committee for the last five years, including as Chair during
the last term. I have also been PTL of the Oslo and Release Management
teams at different points in the past.

I have spent most of my time in all of those roles over the last few
years making incremental improvements in our ability to collaborate
while building OpenStack, including initiatives such as leading the
current community goal to run CI jobs under Python 3 by default [1];
coordinating last year's documentation migration; and updating our
dependency management system to make it easier for projects to run
stand-alone.

During my time serving as TC Chair, I have tried to update the way the
group works with the community. We started by performing a "health
check" for all of our project teams [2], as a way to spot potential
issues teams are experiencing that we can help with, and to encourage TC
members to learn more about teams they may not interact with on a
daily basis. We will be reviewing the results at the PTG [3], and
continuing to refine that process.

I have also had a few opportunities this year to share our governance
structure with other communities [4][5]. It's exciting to be able to
talk to them about how the ideals and principles that hold our
community together can also apply to their projects.

The OpenStack community continues to be the most welcoming group I
have interacted with in more than 25 years of contributing to open
source projects. I look forward to another opportunity to serve the
project through the Technical Committee over the coming year.

Thank you,
Doug

Candidacy submission: https://review.openstack.org/599582
Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
Commit history: https://review.openstack.org/#/q/owner:2472,n,z
Foundation Profile:
http://www.openstack.org/community/members/profile/359
Freenode: dhellmann
Website: https://doughellmann.com

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://wiki.openstack.org/wiki/OpenStack_health_tracker
[3] https://etherpad.openstack.org/p/tc-stein-ptg
[4] https://doughellmann.com/blog/2018/08/21/planting-acorns/
[5] https://www.python.org/dev/peps/pep-8002/

__
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



I have generally been very cynical of repeat TC members, mostly because 
I don't know what they actually get done, but this candidacy email is a 
very nice example of specific issues that you've worked on and I really 
appreciate you being able to point out the things you've worked on while 
being on the TC. Thanks for pushing on this stuff Doug.


--

Thanks,

Matt

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


Re: [openstack-dev] [election][tc] announcing candidacy

2018-09-07 Thread Matt Riedemann

On 9/4/2018 7:15 PM, Julia Kreger wrote:

The most specific thing that is weighing on my mind is elevating and
supporting contributors. While this is not new, I think we as a
community need to refocus on it because they are very fibers that make
up the fabric of our community and ultimately the electorate.


Do you have specific *kinds* of contributors in mind here? Like are you 
mostly thinking new or part-time contributors, or are you also including 
long-time maintainers of the project, because let's not forget those are 
also contributors (usually in a large personal sacrificial way).


Do you have specific ideas on how to elevate and support contributors? 
OR what do you see are the major issues not being addressed? Burn out? 
Contributor's backing companies not supporting them in some form? Other?


--

Thanks,

Matt

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


Re: [openstack-dev] [election] [tc] thank you

2018-09-07 Thread Matt Riedemann

On 9/5/2018 10:03 AM, Anita Kuno wrote:

On 2018-09-05 04:01 AM, Thierry Carrez wrote:

Emilien Macchi wrote:



I personally feel like some rotation needs to happen


A very honourable sentiment, Emilien.


+1

--

Thanks,

Matt

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


Re: [openstack-dev] [election] [tc] TC Candidacy

2018-09-07 Thread Matt Riedemann

On 9/5/2018 1:20 PM, Kristi Nikolla wrote:

I’m really excited to have the opportunity to take part in the discussion with
regards to the technical vision for OpenStack. Regardless of election outcome,
this is the first step towards a larger involvement from me in the important
discussions (no more shying away from the important mailing list threads.)


I'm not trying to pick on you Kristi, but personally I'm tired of the TC 
vision question that's been going on for years now and would like the 
people I vote for to spend less time talking about OpenStack and what it 
is or what it isn't (because that changes based on the person you talk 
to and on what day you ask them), and spend more time figuring out how 
to move cross-project initiatives forward. So whether or not OpenStack 
is a toolkit for private/public/edge clouds, or a product, or something 
else, there are likely common themes within OpenStack that we can 
generally agree on across projects and need people to work on them, 
rather than just talk about doing them. Are there specific cross-project 
initiatives you are interested in working on?


--

Thanks,

Matt

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


Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Matt Riedemann

On 9/5/2018 2:49 PM, Samuel Cassiba wrote:

Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.


Are there specific initiatives you plan on pushing forward if on the TC? 
I'm thinking about stuff from the laundry list here:


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

--

Thanks,

Matt

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


Re: [openstack-dev] [election][tc] Announcing candidacy

2018-09-07 Thread Matt Riedemann

On 9/6/2018 1:49 PM, Rico Lin wrote:

* Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)


Are there some specific initiatives or deliverables you have in mind 
here, or just general open communication channels? It's very hard to 
gauge any kind of progress/success on the latter.


--

Thanks,

Matt

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


Re: [openstack-dev] [election][tc] TC Candidacy

2018-09-07 Thread Matt Riedemann

On 9/6/2018 2:59 AM, Ghanshyam Mann wrote:

* Share Project teams work for Common Goals:  Every cycle we have TC goals and 
some future direction where all the projects needs to start working. Projects 
try to do their best in that but big challenge for them is resource bandwidth. 
In Current situation, It is very hard for projects teams to accommodate those 
work by themselves. Project team are shrinking and key members are overloaded. 
My Idea is to form a temporary team of contributors under Goal champion and 
finish those common area work during starting of cycle (so that we can make 
sure to finish the work well on time and test throughout the cycle). That 
temporary team can be formed with volunteers from any project team or new part 
time contributors with help of OUI or FirstContact SIG etc.


This is a good idea and something I personally would like to see the TC 
doing to move actual positive technical changes forward across OpenStack.


--

Thanks,

Matt

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


[openstack-dev] it may be a bug of swift3 1.7.0 or ?

2018-09-07 Thread Bob-XiuCai
Hi,


Environment:
openstack (liberty) swift
swift3: 1.7.0
boto: 2.48.0


If bucket name has unicode characters such as Chinese words 
(`u'\u54e6\u76c6\u65af\u5766'`),
  boto will return "AccessDenied".


See this (https://github.com/boto/boto3/issues/1693) for details, because i 
thought it was boto's fault at first.


Regards!__
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] [puppet] Puppet weekly recap - week 35-36

2018-09-07 Thread Tobias Urdin

Hello fellow Puppeteers!

Welcome to the weekly Puppet recap for week 35 and 36.
Because I was away last week I forgot to follow up the progress of week 35.

The past two weeks has been quite calm, we have had a lot of changes due 
to the move
away from Zuul config in project-config and the bump of the version for 
all modules on the

master branch to prepare for the Stein cycle.

MERGED CHANGES


= puppet-barbican =
* 34e6f3a Add barbican::worker class
The Barbican module now supports installation and management of the
barbican-worker service.

= puppet-cinder =
* 3c634d2 Deprecate parameters that have been removed from cinder
Config options for Cinder that was removed in Queens has been deprecated
in the Puppet interface.

= puppet-ironic =
* f37d8f6 Add tests for oslo_messaging_notifications
Added missing spec tests for the recent oslo messaging addition

* 27bf3a0 Expose the notification_level paramenter
Added the [DEFAULT]/notification_level configuration option

= puppet-neutron =
* 33f8cdc Notify about deprecated neutron::services::lbaas
Neutron LBaaS is deprecated so a warning has been added

* c70e4fa Add ensure_lbaas_package to neutron::server
Added the ability to install the LBaaS plugin from the neutron::server class

= puppet-nova =
393694a Add a release note for sync_power_state_interval parameter
b4f3d6a compute: add sync_power_state_interval parameter

Added the sync_power_state_interval configuration option for nova.

= puppet-octavia =
2b83ae2 Add octavia::certificates::client_ca and data
45673ee Added missing DB params to init class
e1531c3 Add Octavia API WSGI support
d2a9586 Add octavia::neutron to configure nova section
6731e53 Add octavia::glance to configure glance section
9b285e7 Add missing options to octavia::certificates
6864cd0 Add octavia::nova to configure nova section
7d6bada Add workers support to octavia::worker class
6e7dacc Add api_v1_enabled and api_v2_enabled options
14c5257 Add allow_tls_terminated_listeners config option

The Octavia module have had a lot of changes to make sure it's fit
to be used. It now includes all the required classes and configuration
options to use it. You can run the API in WSGI, enable/disable the v1
and v2 API, set if TLS listeners is allowed and separate the client and
server CA certificates.

= puppet-openstack-integration =
* 1edb135 Remove tripleo-puppet-ci-centos-7-undercloud-oooq job
Removed TripleO testing for non-containerized undercloud.

* 9cb0e06 Higher timeout and two tries for update packages
In the repos.pp file the upgrade packages call times out so we tried
increasing the timeout and set tries to two (2) but it did not solve the 
issue.


* 15dd562 Add barbican::worker to integration testing
The newly added barbican::worker class is tested in the integration testing.

= puppet-vswitch =
* b6dab2e Fix the undefined method 'chomp' for nil:NilClass error seen 
with ovs 2.10
Fixed a bug where the output to stdout contained error messages the 
provider would

fail to parse the values, it now ignores nil values.

SPECS
=
No new specs.

Only one open spec:

*  Add parameter data types spec
https://review.openstack.org/#/c/568929/

CI
=

There is some current issues with the CI, if anybody feels they have 
time we all would appreciate

that you help us resolve it.

* The update-packages call in repos.pp for 
openstack/puppet-openstack-integration times out on
CentOS 7 (calling yum upgrade). This makes integration testing for 
puppet-openstacklib fail.


* The stable/ocata and stable/pike branches has issues and are failing, 
this block most of the
Zuul config retire from project-config patches that Doug has proposed, 
we need to resolve this by
unblocking (fixing) the CI. This is probably backporting previous fixes 
to CI.


I have been very busy with finalizing a project so I've not been able to 
look at this. I will have a look

this weekend or hopefully next week but would appreciate any help.

After CI is fixed we can merge all these:

* Update Gemfile for stable/rocky (openstack/puppet-openstacklib)
https://review.openstack.org/#/c/597087/

* make openstackclient package name configurable 
(openstack/puppet-openstacklib)

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

* All the python3-first topic changes
(named "import zuul job settings from project-config" and "switch 
documentation job to new PTI")


NEEDS REVIEWS
==

* Make ironic password a secret
https://review.openstack.org/#/c/598173/

* Remove usage of deprecated RamFilter
https://review.openstack.org/#/c/597204/

* Add cinder::nova class to configure nova section
https://review.openstack.org/#/c/600559/

* Cinder-type param is_public/access_project_ids
https://review.openstack.org/#/c/600071/

* Remove ironic inspector dnsmasq bind-interfaces setting
https://review.openstack.org/#/c/600068/

* Add octavia testing
https://review.openstack.org/#/c/597600/

* Change beaker testing to 

Re: [openstack-dev] Nominating Chris Dent for placement-core

2018-09-07 Thread Eric Fried
After a week with only positive responses, it is my pleasure to add
Chris to the placement-core team.

Welcome home, Chris.

On 08/31/2018 10:45 AM, Eric Fried wrote:
> The openstack/placement project [1] and its core team [2] have been
> established in gerrit.
> 
> I hereby nominate Chris Dent for membership in the placement-core team.
> He has been instrumental in the design, implementation, and stewardship
> of the placement API since its inception and has shown clear and
> consistent leadership.
> 
> As we are effectively bootstrapping placement-core at this time, it
> would seem appropriate to consider +1/-1 responses from heavy placement
> contributors as well as existing cores (currently nova-core).
> 
> [1] https://review.openstack.org/#/admin/projects/openstack/placement
> [2] https://review.openstack.org/#/admin/groups/1936,members
> 
> __
> 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] [horizon] No meeting next week

2018-09-07 Thread Ivan Kolodyazhny
Hi team,

A lot of us will attend PTG in Denver next week so we skip the meeting on
9/12.

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


Re: [openstack-dev] [all][infra] Moving cover job from post to check pipeline

2018-09-07 Thread Andreas Jaeger

On 2018-09-06 20:10, Andreas Jaeger wrote:

Citing Ian Wienand in [2]

"There was a thread some time ago that suggested coverage jobs weren't 
doing much in the "post" pipeline because nobody looks at them and the 
change numbers may be difficult to find anyway [1]. This came up again 
in a cleanup to add non-voting coverage jobs in 
I5c42530d1dda41b8dc8c13cdb10458745bec7bcc.


There really is no consistency across projects; it seems like a couple 
of different approaches have been cargo-cult copied as new projects came 
in, depending on which random project was used as a template. This 
change does a cleanup by moving all post coverage jobs into the check 
queue as non-voting jobs."


Correcting: It's a voting job.

Note that I pushed changes - using topic:update-zuul - to projects with 
that update and found a few broken cover jobs. Those were run as post 
jobs and always failed ;(


Andreas

I've updated Ian's change [2] now and propose to move ahead with it - 
and suggest that projects with in-repo coverage job follow it as well. 
Let's use the new template [3] openstack-cover-jobs (and it's 
-horizon/-neutron variants) for this change.


Andreas

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099491.html

[2] https://review.openstack.org/#/c/432836/
[3] 
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-openstack-cover-jobs 






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


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


Re: [openstack-dev] [tripleo] VFs not configured in SR-IOV role

2018-09-07 Thread Saravanan KR
Not sure which version you are using, but the service
"OS::TripleO::Services::NeutronSriovHostConfig" is responsible for
setting up VFs. Check if this service is enabled in the deployment.
One of the missing place is being fixed -
https://review.openstack.org/#/c/597985/

Regards,
Saravanan KR
On Tue, Sep 4, 2018 at 8:58 PM Samuel Monderer
 wrote:
>
> Hi,
>
> Attached is the used to deploy an overcloud with SR-IOV role.
> The deployment completed successfully but the VFs aren't configured on the 
> host.
> Can anyone have a look at what I missed.
>
> Thanks
> Samuel
> __
> 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] [tempest][CI][nova compute] Skipping non-compute-driver tests

2018-09-07 Thread Chen CH Ji
Thanks for the confirmation, I agree use internal maintain CI whitelist is
a good way, and I confirmed with our CI folks that we already did so and
more can be removed per
Eric's test result below, so we will compare and remove unnecessary cases
to get more bandwidth to run 3rd party CI. 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



From:   Ghanshyam Mann 
To: "OpenStack Development Mailing List \\"

Date:   09/07/2018 02:18 PM
Subject:Re: [openstack-dev] [tempest][CI][nova compute] Skipping
non-compute-driver tests






  On Fri, 07 Sep 2018 04:41:32 +0900 Eric Fried 
wrote 
 > Jichen-
 >
 > That patch is not ever intended to merge; hope that was clear from
the
 > start :) It was just a proving ground to demonstrate which tests still
 > pass when there's effectively no compute driver in play.
 >
 > We haven't taken any action on this from our end, though we have
done a
 > little brainstorming about how we would tool our CI to skip those tests
 > most (but not all) of the time. Happy to share our experiences with you
 > if/as we move forward with that.
 >
 > Regarding the tempest-level automation, I certainly had z in mind
when
 > I was thinking about it. If you have the time and inclination to help
 > look into it, that would be most welcome.

Sorry for late response, somehow i missed this thread. As you mentioned and
noticed in your patch that there are ~700 tests which does not touch
compute driver. Most of them are from neutron-tempest-plugins or other
service tests. From Tempest compute tests, many of them are negative tests
or DB layer tests [1].

neutron-tempest-plugin or other service test you can always avoid to run
with regex. And i do not think compute negative or DB test will take much
time to run. But still if you want to avoid to run then, I think it is easy
to maintain a whitelist regex file on CI side which can run only compute
driver tests(61 in this case).

Tagging compute driver on tempest side is little hard to maintain i feel
and it can goes out of date very easily. If you have any other idea on
that, we can surly talk in PTG on this.

[1]
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz


 >
 > Thanks,
 > efried
 >
 > On 09/06/2018 12:33 AM, Chen CH Ji wrote:
 > > I see the patch is still ongoing status and do you have a follow up
 > > plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
 > > so skip non-compute related cases will be a good for 3rd part CI ..
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 Eric Fried ---09/04/2018 09:35:09
PM---Folks-
 > > The other day, I posted an experimental patch [1] withEric Fried
 > > ---09/04/2018 09:35:09 PM---Folks- The other day, I posted an
 > > experimental patch [1] with an effectively
 > >
 > > From: Eric Fried 
 > > To: "OpenStack Development Mailing List (not for usage questions)"
 > > 
 > > Date: 09/04/2018 09:35 PM
 > > Subject: [openstack-dev] [tempest][CI][nova compute] Skipping
 > > non-compute-driver tests
 > >
 > >

 > >
 > >
 > >
 > > Folks-
 > >
 > > The other day, I posted an experimental patch [1] with an effectively
 > > empty ComputeDriver (just enough to make n-cpu actually start) to see
 > > how much of our CI would pass. The theory being that any tests that
 > > still pass are tests that don't touch our compute driver, and are
 > > therefore not useful to run in our CI environment. Because anything
that
 > > doesn't touch our code should already be well covered by generic
 > > dsvm-tempest CIs. The results [2] show that 707 tests still pass.
 > >
 > > So I'm wondering whether there might be a way to mark tests as being
 > > "compute driver-specific" such that we could switch off all the other
 > > ones [3] via a one-line conf setting. Because surely this has
potential
 > > to save a lot of CI resource not just for us but for other driver
 > > vendors, in tree and out.
 > >
 > > Thanks,
 > > efried
 > >
 > > [1]
https://review.openstack.org/#/c/599066/

 > > [2]
 > >
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz

 > > [3] I get that there's still value in running all those tests. But it
 > > could be done like once every 10 or 50 or 100 runs instead of every
time.
 > >
 > >
__
 > > OpenStack Development 

Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

2018-09-07 Thread Julien Danjou
On Fri, Sep 07 2018, Tony Breeds wrote:

> On Thu, Sep 06, 2018 at 01:33:12PM +0300, Michel Peterson wrote:
>
>> I remember that before landing the problematic patch [1] there was some
>> discussion around it. Basically the problem was not n-odl but ceilometer
>> not being in pypi, but we never foresaw this problem.
>> 
>> Now that the problem is so critical, the question is how can we, from the
>> n-odl team, help in fixing this? I am open to help in any effort that
>> involves n-odl or any other project.
>
> As other have pointed out we can just ask the Telemetry team (PTL on CC)
> why we can't publish ceilometer to pypi?

You can, I've already said +1 on a review a few weeks ago. :)

> https://pypi.org/project/ceilometer/ certainly seems to be the right
> project.
>
> The crux of the code issue is:
> from ceilometer.network.statistics import driver
>
> in networking_odl/ceilometer/network/statistics/opendaylight_v2/driver.py
>
> If this is supposed to be used they way you are how are prjects supposed
> to get the ceilometer code?
>
>
>
> Yours Tony.
>

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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] [stable][keystone] python3 goal progress and tox_install.sh removal

2018-09-07 Thread Tony Breeds
On Thu, Sep 06, 2018 at 03:01:01PM -0500, Lance Bragstad wrote:
> I'm noticing some odd cases with respect to the python 3 community goal
> [0]. So far my findings are specific to keystone repositories, but I can
> imagine this affecting other projects.
> 
> Doug generated the python 3 reviews for keystone repositories, including
> the ones for stable branches. We noticed some issues with the ones proposed
> to stable (keystoneauth, python-keystoneclient) and master
> (keystonemiddleware). For example, python-keystoneclient's stable/pike [1]
> and stable/ocata [2] branches are both failing with something like [3]:
> 
> ERROR: You must give at least one requirement to install (see "pip help
> install")

I've updated 1 and 2 to do the same thing that lots of other repos do
and just exit 0 in this case.  1 and 2 now have a +1 from zuul.


 
> I've attempted to remove tox_install.sh using several approaches with
> keystonemiddleware master [7]. None of which passed both unit tests and the
> requirements check.

Doug pointed out the fix here, which I added.  It passed most of the
gate but failed in an unrelated neutron test so I've rechecked it.

Yours Tony.


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


[openstack-dev] [neutron] Pep8 job failures

2018-09-07 Thread Slawomir Kaplonski
Hi,

Recently bump of eventlet to 0.24.0 was merged in requirements repo [1]. 
That caused issue in Neutron and pep8 job is now failing. See [2]. So if You 
have pep8 failed in Your patch with error like in [3] please don’t recheck job 
- it will not help :)
Patch to fix that is already proposed [4]. When it will be merged, please 
rebase Your patch and this issue should be solved.

[1] https://review.openstack.org/#/c/589382/
[2] https://bugs.launchpad.net/neutron/+bug/1791178
[3] 
http://logs.openstack.org/37/382037/73/gate/openstack-tox-pep8/7f200e6/job-output.txt.gz#_2018-09-06_17_48_34_700485
[4] https://review.openstack.org/600565

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [release] [stable] Cherry-pick migration to stable/rocky

2018-09-07 Thread Pierre Gaxatte
> Backporting a migration like that is OK as long as you don't skip
> migrations, that is to say revision '030' of the database should be the
> same on all branches.  Given we've only just released rocky I expect
> that will be the case here.
> 
> You absolutely must have a release note and call it out as upgrade impact
> and of course this is a minor release not a patch release.
The release note was not in the initial change so here it is:
https://review.openstack.org/#/c/600018

Any input is welcome as the wording and content might not be exactly
what you expect.

Regards,
Pierre

__
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] [tempest][CI][nova compute] Skipping non-compute-driver tests

2018-09-07 Thread Ghanshyam Mann



  On Fri, 07 Sep 2018 04:41:32 +0900 Eric Fried  wrote 
 
 > Jichen-
 > 
 > That patch is not ever intended to merge; hope that was clear from the
 > start :) It was just a proving ground to demonstrate which tests still
 > pass when there's effectively no compute driver in play.
 > 
 > We haven't taken any action on this from our end, though we have done a
 > little brainstorming about how we would tool our CI to skip those tests
 > most (but not all) of the time. Happy to share our experiences with you
 > if/as we move forward with that.
 > 
 > Regarding the tempest-level automation, I certainly had z in mind when
 > I was thinking about it. If you have the time and inclination to help
 > look into it, that would be most welcome.

Sorry for late response, somehow i missed this thread. As you mentioned and 
noticed in your patch that there are ~700 tests which does not touch compute 
driver. Most of them are from neutron-tempest-plugins or other service tests. 
From Tempest compute tests, many of them are negative tests or DB layer tests 
[1].

neutron-tempest-plugin or other service test you can always avoid to run with 
regex. And i do not think compute negative or DB test will take much time to 
run. But still if you want to avoid to run then, I think it is easy to maintain 
a whitelist regex file on CI side which can run only compute driver tests(61 in 
this case). 

Tagging compute driver on tempest side is little hard to maintain i feel and it 
can goes out of date very easily. If you have any other idea on that, we can 
surly talk in PTG on this. 

[1] 
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz

 > 
 > Thanks,
 > efried
 > 
 > On 09/06/2018 12:33 AM, Chen CH Ji wrote:
 > > I see the patch is still ongoing status and do you have a follow up
 > > plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
 > > so skip non-compute related cases will be a good for 3rd part CI .. 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 Eric Fried ---09/04/2018 09:35:09 PM---Folks-
 > > The other day, I posted an experimental patch [1] withEric Fried
 > > ---09/04/2018 09:35:09 PM---Folks- The other day, I posted an
 > > experimental patch [1] with an effectively
 > > 
 > > From: Eric Fried 
 > > To: "OpenStack Development Mailing List (not for usage questions)"
 > > 
 > > Date: 09/04/2018 09:35 PM
 > > Subject: [openstack-dev] [tempest][CI][nova compute] Skipping
 > > non-compute-driver tests
 > > 
 > > 
 > > 
 > > 
 > > 
 > > Folks-
 > > 
 > > The other day, I posted an experimental patch [1] with an effectively
 > > empty ComputeDriver (just enough to make n-cpu actually start) to see
 > > how much of our CI would pass. The theory being that any tests that
 > > still pass are tests that don't touch our compute driver, and are
 > > therefore not useful to run in our CI environment. Because anything that
 > > doesn't touch our code should already be well covered by generic
 > > dsvm-tempest CIs. The results [2] show that 707 tests still pass.
 > > 
 > > So I'm wondering whether there might be a way to mark tests as being
 > > "compute driver-specific" such that we could switch off all the other
 > > ones [3] via a one-line conf setting. Because surely this has potential
 > > to save a lot of CI resource not just for us but for other driver
 > > vendors, in tree and out.
 > > 
 > > Thanks,
 > > efried
 > > 
 > > [1] https://review.openstack.org/#/c/599066/
 > > [2]
 > > http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz
 > > [3] I get that there's still value in running all those tests. But it
 > > could be done like once every 10 or 50 or 100 runs instead of every time.
 > > 
 > > __
 > > 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: