[Openstack] User Committee IRC Meeting - Monday Jan 30th - Host Needed

2017-01-29 Thread Edgar Magana 
Dear UC Community,

Our next UC IRC meeting is scheduled for this Monday Jan 30th at 1900 UTC in 
(freenode) #openstack-meeting.
Unfortunately, I have a last-minute conflict and I won’t be able to lead the 
session. I would like to know if we have any volunteers to drive the session.



I have also a proposal to move the meeting for a different day this week which 
I like it better.



Topics to cover:



-  UC Election

-  PTG activities from UC members

-  Boston planning

-  Open Agenda

User Committee OpenStack
Jon, Shilla and Edgar
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] User Committee IRC Meeting - Monday Jan 30th - Host Needed

2017-01-29 Thread Edgar Magana 
Dear UC Community,

Our next UC IRC meeting is scheduled for this Monday Jan 30th at 1900 UTC in 
(freenode) #openstack-meeting.
Unfortunately, I have a last-minute conflict and I won’t be able to lead the 
session. I would like to know if we have any volunteers to drive the session.



I have also a proposal to move the meeting for a different day this week which 
I like it better.



Topics to cover:



-  UC Election

-  PTG activities from UC members

-  Boston planning

-  Open Agenda

User Committee OpenStack
Jon, Shilla and Edgar
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-29 Thread Kekane, Abhishek 
Sorry for wrong auto-correction :)

Congratulations Dharini, All the best. .

Abhishek
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: Sunday, January 29, 2017 8:39 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Congratulations Sharing. .
All the best.

Abhishek

Sent from OWA on Android

From: Brian Rosmaita 
>
Sent: Thursday, January 26, 2017 8:56:30 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Having heard only affirmative responses, I've added Dharini Chandrasekar
to the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome to the Glance core team, Dharini!

On 1/24/17 8:36 AM, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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][elections] PTL nomination period is now over

2017-01-29 Thread Kendall Nelson 
Yes of course :) Did you want to schedule a meeting or just discuss here
more?

I've seen some discussion about making UX to a working group?

-Kendall (diablo_rojo)

On Sun, Jan 29, 2017, 7:46 PM Lana Brindley 
wrote:

> Hi Kendall,
>
> I'd like to discuss the future of the UX project with you, if that's OK?
>
> Lana
>
> On 30/01/17 11:05, Kendall Nelson wrote:
> > Hello All!
> >
> > PTL Nomination is now over. The official candidate list is available on
> the election website[0].
> >
> > There is only 1project without candidates, so according to this
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
> >
> > There are 5projects that will have an election: Ironic, Keystone,
> Neutron, Quality Assurance and Stable Branch Maintenance.The details for
> those will be posted shortly after we setup the CIVS system.
> >
> > Thank you,
> >
> > [0]: http://governance.openstack.org/election/# <
> http://governance.openstack.org/election/#pike-ptl-candidates>pike <
> http://governance.openstack.org/election/#pike-ptl-candidates>-ptl-candidates
> 
> > [1]:
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] Supporting our global community

2017-01-29 Thread Lana Brindley 
Jonathon, Mark, Lauren, and the rest of the Foundation staff,

Thank you for this important note.

Is Foundation able to provide some concrete assurance that they will continue 
to ensure that availability of visas is to be prioritised for future OpenStack 
events? Additionally, that you will not run events in countries that do not 
reflect OpenStack values of diversity?

Lana

On 30/01/17 04:34, Jonathan Bryce wrote:
> OpenStack is a global open source community. The OpenStack Foundation serves 
> members in 180 countries focused on advancing the capabilities and 
> accessibility of open infrastructure everywhere. We fundamentally believe 
> diversity and collaboration are a powerful force for innovation, and it has 
> been amazing to see the product of tens of thousands of people around the 
> world over the last 6+ years.
> 
> Lauren, Mark and I disagree with the executive order issued by President 
> Trump that targets individuals from 7 countries. The order restricts the 
> travel and movement of people in a discriminatory way that  results in a 
> restriction on access to talent and ideas. It is still unclear how the 
> policies will play out and be enforced, but we will be watching, advocating 
> for and supporting our community members to the best of our ability. 
> 
> This executive order will not impact the governance of the Foundation or the 
> way the community operates globally. We will continue to support user groups 
> and community members that are active in the seven countries named by the 
> executive order, alongside our 120+ user groups around the world. However, we 
> have two scheduled events in the United States within the next six months 
> that will attract a global audience: the PTG (Project Teams Gathering) in 
> Atlanta, Feb 20-24, a smaller event that will bring together hundreds of 
> upstream contributors, and the OpenStack Summit in Boston, May 8-11, our 
> larger event that happens every six months. 
> 
> This executive order could impact some community members' ability to travel 
> to Atlanta and Boston, but unfortunately it is too late at this point to 
> change the location of these events. The following three OpenStack Summits, 
> however, are now scheduled to occur outside of the United States. The next 
> Summit will be in November 2017 in Sydney, Australia and we are working to 
> finalize the details so we can announce the following two Summit locations 
> soon.
> 
> We’ve already heard from one community member, Mohammed Naser, who is 
> concerned that his plans to travel from Canada to Atlanta to attend the PTG 
> may be restricted, simply because he a dual citizen of Canada and Iraq.  
> Mohammed has been contributing code to OpenStack since 2011 and is the CEO 
> and Founder of Vexxhost. Blocking his travel would serve no purpose and rob 
> the community of a valuable contributor during an important event. If you are 
> concerned about the impact or have any questions, please don't hesitate to 
> reach out to me at jonat...@openstack.org.
> 
> Political actions like this highlight the importance of our collective 
> values. The Four Opens, the founding principles of our community, exist to 
> ensure the free flow of talent and ideas, across geographic, national, 
> organizational or other lines that might divide us. We believe in humanity. 
> We believe in opportunity. We believe in the power of collaboration across 
> borders, and we will continue to carry forward our mission.
> 
> We also posted this online: 
> https://www.openstack.org/blog/2017/01/supporting-our-global-community/
> 
> Jonathan Bryce
> Mark Collier
> Lauren Sell
> 
> 
> 
> __
> 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
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [ux] Future of the OpenStack UX team

2017-01-29 Thread Lana Brindley 
Hi Thierry,

Sorry for not noticing this thread and replying earlier.

I've now reviewed the minutes from the meeting, and I support thingee's 
suggestion of having a UX working group. This way, UX can get the attention it 
rightly deserves. Without the research and guidelines provided by the UX team, 
user-facing projects (such as Docs) will be poorer. I believe that it's in 
Foundations best interests to ensure that UX work is ongoing, and adequately 
supported, in the same way as Marketing and other user outreach services. 

I am happy to work with Foundation (on behalf of the Docs team) to determine 
how this would work in practice.

Thanks,
Lana

On 05/01/17 00:43, Thierry Carrez wrote:
> Hi everyone,
> 
> Piet recently reached out to me to explain that he won't be able to
> continue in his role as OpenStack UX team's PTL. Since he created the
> team and spent a lot of time coordinating its activities, that raises
> the question of the future of the OpenStack UX team.
> 
> The situation was discussed at the TC meeting yesterday[1] and the
> general feeling was that there was a lot of value in a separate team
> centralizing things like Persona definition and facilitating
> properly-conducted UX surveys. That said, if nobody is able to dedicate
> the time that effort needs, we could also disband the centralized team
> and encourage every project to adopt the tools and techniques that were
> built and introduced by the UX team in the past years.
> 
> So... What are your thoughts on those options ? Do we have a volunteer
> (or more than one) to take over UX PTLship ?
> 
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html#l-404
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [vitrage] New Vitrage project mascot

2017-01-29 Thread Renat Akhmerov 
Looks cool :)

Renat Akhmerov
@Nokia

> On 29 Jan 2017, at 19:23, Yujun Zhang  wrote:
> 
> Not remembering the original design. 
> 
> This one looks good to me :-)
> 
> On Sun, Jan 29, 2017 at 8:18 PM Afek, Ifat (Nokia - IL)  > wrote:
> Hi,
> 
>  
> 
> This is the new draft of our Giraffe mascot. The illustrators tried to make 
> its skin look more like stained glass.
> 
> What do you think?
> 
>  
> 
> Ifat.
> 
>  
> 
> 
> 
>  
> 
>  
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2017-01-29 Thread Lana Brindley 
On 30/01/17 14:15, Steve Martinelli wrote:
> On Sun, Jan 29, 2017 at 8:05 PM, Kendall Nelson  > wrote:
> 
> PTL Nomination is now over. The official candidate list is available on 
> the election website[0].
> 
> 
> It's great to see only 1 project was without a PTL!
>  
> 
> There is only 1project without candidates, so according to this 
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
> 
> 
> The UX project was briefly discussed at a recent TC meeting (see the end of 
> the log) [1], with Piet stepping down there was some discussion about whether 
> or not it needs to be a standalone project, or can turn into a working group 
> (like the API working group).
> 
> Oh, Thierry sent something out to the mailing list already [2], no replies :(
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
> 

Ah, thanks Steve. I'll digest this and then reply on that thread :)

Lana

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2017-01-29 Thread Steve Martinelli 
On Sun, Jan 29, 2017 at 8:05 PM, Kendall Nelson 
wrote:

> PTL Nomination is now over. The official candidate list is available on
> the election website[0].
>

It's great to see only 1 project was without a PTL!


> There is only 1 project without candidates, so according to this
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
>

The UX project was briefly discussed at a recent TC meeting (see the end of
the log) [1], with Piet stepping down there was some discussion about
whether or not it needs to be a standalone project, or can turn into a
working group (like the API working group).

Oh, Thierry sent something out to the mailing list already [2], no replies
:(

[1]
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[OpenStack-Infra] Dropped connections from static.o.o

2017-01-29 Thread Ian Wienand 
Hi,

We got a report of CI jobs failing with disconnects when
downloading from tarballs.openstack.org.  The file in question is
a largish container for kolla-kubernetes [1]

ISTR this is not the first time we've had complaints about this, but
I'm not sure if we ever came up with a solution.

Below are some of the failed jobs with the ip, start & failure
time of the download.

---
http://logs.openstack.org/98/426598/5/check/gate-kolla-kubernetes-deploy-centos-binary-2-ceph-nv/21e4361/console.html
inet 146.20.105.26
2017-01-30 00:00:08.109056 | + curl ... 
http://tarballs.openstack.org/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2
2017-01-30 00:04:44.002456 | curl: (18) transfer closed with 88598540 bytes 
remaining to read

http://logs.openstack.org/98/426598/5/check/gate-kolla-kubernetes-deploy-centos-binary-2-ceph-multi-nv/fe0849b/console.html
inet 146.20.105.198
2017-01-30 00:00:08.471434 | + curl -o ... 
http://tarballs.openstack.org/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2
2017-01-30 00:04:42.685201 | curl: (18) transfer closed with 542002092 bytes 
remaining to read

http://logs.openstack.org/98/426598/5/check/gate-kolla-kubernetes-deploy-centos-binary-2-external-ovs-nv/38030a1/console.html
inet6 2001:4800:1ae1:18:f816:3eff:fe9b:f9e2/64 
2017-01-30 00:01:07.306370 | + curl -o ... 
http://tarballs.openstack.org/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2
2017-01-30 00:03:34.810258 | curl: (18) transfer closed with 222546512 bytes 
remaining to read
---

At first, there is not much correlation and two of the requests
appear to not be logged at all.

---
root@static:/var/log/apache2# grep 'centos-binary-ceph.tar.bz2' 
tarballs.openstack.org_*  | grep '30/Jan'
tarballs.openstack.org_access.log:2001:4800:1ae1:18:f816:3eff:fe9e:4ccf - - 
[30/Jan/2017:00:00:33 +] "GET 
/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2 HTTP/1.1" 200 
1395496732 "-" "curl/7.29.0"
tarballs.openstack.org_access.log:2001:4800:1ae1:18:f816:3eff:fe67:2ca6 - - 
[30/Jan/2017:00:00:47 +] "GET 
/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2 HTTP/1.1" 200 
1395496732 "-" "curl/7.29.0"
tarballs.openstack.org_access.log:2001:4800:1ae1:18:f816:3eff:fe9b:f9e2 - - 
[30/Jan/2017:00:01:07 +] "GET 
/kolla-kubernetes/gate/containers//centos-binary-ceph.tar.bz2 HTTP/1.1" 200 
1395496732 "-" "curl/7.29.0"
---

However, I went to the generic apache error log around that time and
found the following

---
[Sun Jan 29 23:59:16.284909 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
[Mon Jan 30 00:00:02.334021 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
[Mon Jan 30 00:00:04.336258 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
[Mon Jan 30 00:01:48.449350 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
[Mon Jan 30 00:02:25.490781 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
[Mon Jan 30 00:03:10.539081 2017] [mpm_event:error] [pid 1967:tid 
140205198583680] AH00485: scoreboard is full, not at MaxRequestWorkers
...
---

I think this is a smoking gun for the issue, because this issue leads
to the death of the serving process, which gets logged a little later.
Correlating this it seems like a few of these time-stamps match up
with when the reported jobs reported they got disconnected.

---
[Mon Jan 30 00:03:31.562290 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 14410 exit signal Segmentation fault (11)
[Mon Jan 30 00:03:35.566735 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 20378 exit signal Segmentation fault (11)
...
[Mon Jan 30 00:04:17.614883 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 4126 exit signal Segmentation fault (11)
[Mon Jan 30 00:04:17.614951 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 4204 exit signal Segmentation fault (11)
[Mon Jan 30 00:04:22.621893 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 4290 exit signal Segmentation fault (11)
[Mon Jan 30 00:04:37.638901 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 4358 exit signal Segmentation fault (11)
[Mon Jan 30 00:04:41.643388 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 4324 exit signal Segmentation fault (11)
[Mon Jan 30 00:04:42.645053 2017] [core:notice] [pid 1967:tid 140205198583680] 
AH00052: child pid 20485 exit signal Segmentation fault (11)
---

This ungraceful exit might also explain the lack of logs.

Unfortunately, the prognosis for this issue is not great.  The
original bug [2] seems to show it is a systemic issue and it is
discussed in the documentation [3] which says in short

 This mpm showed

Re: [openstack-dev] [nova] The status of servers API's filters

2017-01-29 Thread Ghanshyam Mann 
On Sun, Jan 29, 2017 at 10:12 AM, Alex Xu  wrote:

>
>
> 2017-01-29 1:31 GMT+08:00 Matt Riedemann :
>
>> On 1/27/2017 3:37 AM, Alex Xu wrote:
>>
>>> The patches about validation the filters and sorts for servers API are
>>> merged [0]. But we still have something left [1].
>>>
>>> The left is about the proposal of introducing the new rule
>>> 'os_compute_api:servers:all_tenants_visible' which is soft enforcement.
>>> The new rule will instead of the old hard enforcement rule
>>> "os_compute_api:servers:index:get_all_tenants".
>>>
>>> In the discussion of nova API meeting, Join pointed out that the change
>>> from hard enforcement to soft enforcement needs Microversion. The API
>>> used to return 403 when user didn't have permission of all_tenants
>>> parameter. But now the API returns 200 with the own instances when no
>>> permission of all_tenants parameter. So the proposal should be separated
>>> to two parts:
>>>
>>> i. rename the policy from "get_all_tenants" to the "all_tenants_visible"
>>> ii. change the enforcement from hard to soft by Microversion.
>>>
>>> In the old microversion, the rule keeps as hard enforcement.
>>>
>>> So in Ocata, "get_all_tenants" will be deprecated. If the deployer have
>>> overriden rule in the policy file, the old rule still will be enforced,
>>> and the warning message will be emit to notice that the user needs to
>>> move their custom rule to the new rule 'all_tenants_visiable'. And if
>>> the API user requests with new microversion, the rule will become soft
>>> enforcement.
>>>
>>> So if that sounds make sense, there also have another question about
>>> whether we have enough time to merge it. I think Matt will make a call
>>> on it.
>>>
>>> And due to holidays in China, both I and Kevin are in vacation.  And
>>> really really appreciate Ghanshyam take care on those patches! The
>>> spec[3] and the patch[1] already updated by him.
>>>
>>> AnywayHappy Chinese New Year to everyone(yea, new year again \o/).
>>>
>>> Thanks
>>> Alex
>>>
>>> [0] https://review.openstack.org/408571
>>> 
>>> and https://review.openstack.org/415142
>>> 
>>> [1] https://review.openstack.org/#/q/status:open+project:opensta
>>> ck/nova+branch:master+topic:bp/add-whitelist-for-server-list
>>> -filter-sort-parameters
>>> >> ack/nova+branch:master+topic:bp/add-whitelist-for-server-lis
>>> t-filter-sort-parameters>
>>> [3] https://review.openstack.org/425533
>>> 
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> My immediate question is, does this need to happen in Ocata or can we
>> defer the all_tenants_visible policy change to Pike? Is there anything we
>> merged in Ocata that is now broken, or weird, or blocks us from doing
>> something later, etc if we don't get this done now?
>>
>
> I didn't see any broken or blocks without the all_tenants_visiable policy
> change. The policy change is just part of vision of how filters should be
> looks like between admin user and non-admin user.
>
>
>>
>> Honestly I never really understood why the all_tenants policy change was
>> being lumped in with the server sort/filter whitelist blueprint, except
>> maybe just because of convenience?
>>
>
> Emm..I didn't remember any discussion about why we should put all of them
> into one spec or not.
>
>
>> Anyway, this seems like something we can defer to Pike unless I'm missing
>> something.
>
>
> I'm ok with that, due to I didn't have any critical reason. The only thing
> is we need one more cycle to remove a old policy rule. But currently the
> new proposal without more discussion, and we only have 1 week left for spec
> change and patches. It isn't worth to take that risk I guess.
>

​Ok, I was thinking if we could get new policy and old policy deprecation​
in Ocata and behavior change in Pike but yes that needs spec update and
review which is little bit tight for Ocata.

I am also ok to defer this in Pike.



>
> Anyway, Matt, thanks for your response.
>
>
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2017-01-29 Thread Lana Brindley 
Hi Kendall,

I'd like to discuss the future of the UX project with you, if that's OK?

Lana

On 30/01/17 11:05, Kendall Nelson wrote:
> Hello All!
> 
> PTL Nomination is now over. The official candidate list is available on the 
> election website[0].
> 
> There is only 1project without candidates, so according to this 
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
> 
> There are 5projects that will have an election: Ironic, Keystone, Neutron, 
> Quality Assurance and Stable Branch Maintenance.The details for those will be 
> posted shortly after we setup the CIVS system.
> 
> Thank you,
> 
> [0]: http://governance.openstack.org/election/# 
> pike 
> -ptl-candidates
>  
> [1]: 
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [all][elections] PTL nomination period is now over

2017-01-29 Thread Kendall Nelson 
Hello All!

PTL Nomination is now over. The official candidate list is available on the
election website[0].

There is only 1 project without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.

There are 5 projects that will have an election: Ironic, Keystone, Neutron,
Quality Assurance and Stable Branch Maintenance. The details for those will
be posted shortly after we setup the CIVS system.

Thank you,

[0]: http://governance.openstack.org/election/#
pike

-ptl-candidates

[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [openstack-dev] Supporting our global community

2017-01-29 Thread Anita Kuno 

On 2017-01-29 01:34 PM, Jonathan Bryce wrote:

OpenStack is a global open source community. The OpenStack Foundation serves 
members in 180 countries focused on advancing the capabilities and 
accessibility of open infrastructure everywhere. We fundamentally believe 
diversity and collaboration are a powerful force for innovation, and it has 
been amazing to see the product of tens of thousands of people around the world 
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump 
that targets individuals from 7 countries. The order restricts the travel and 
movement of people in a discriminatory way that  results in a restriction on 
access to talent and ideas. It is still unclear how the policies will play out 
and be enforced, but we will be watching, advocating for and supporting our 
community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the 
way the community operates globally. We will continue to support user groups 
and community members that are active in the seven countries named by the 
executive order, alongside our 120+ user groups around the world. However, we 
have two scheduled events in the United States within the next six months that 
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, 
Feb 20-24, a smaller event that will bring together hundreds of upstream 
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event 
that happens every six months.

This executive order could impact some community members' ability to travel to 
Atlanta and Boston, but unfortunately it is too late at this point to change 
the location of these events. The following three OpenStack Summits, however, 
are now scheduled to occur outside of the United States. The next Summit will 
be in November 2017 in Sydney, Australia and we are working to finalize the 
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned 
that his plans to travel from Canada to Atlanta to attend the PTG may be 
restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has 
been contributing code to OpenStack since 2011 and is the CEO and Founder of 
Vexxhost. Blocking his travel would serve no purpose and rob the community of a 
valuable contributor during an important event. If you are concerned about the 
impact or have any questions, please don't hesitate to reach out to me at 
jonat...@openstack.org.


An update: Canada's Immigration Minister held a press conference saying 
that Canadians with dual citizenship won't be affected: 
http://www.cbc.ca/news/politics/canada-hussen-reaction-to-trump-travel-restrictions-1.3957515 
Now that should make things easier for Mohammed Naser but it doesn't 
solve the larger problem affecting the whole community.


Also in the above linked article, the Canadian government will accept 
those travelers refused entry by the United States due to this order, if 
you find yourself in a situation where that information might be of help 
to you.


As I already shared with Jonathan in private, I'm Canadian and plan on 
avoiding as much travel to the US as I am able for the next four years, 
so people not from the 7 named countries are also making choices as a 
consequence of this action.


Confident we can collectively envision a productive future for all of us,
Anita.



Political actions like this highlight the importance of our collective values. 
The Four Opens, the founding principles of our community, exist to ensure the 
free flow of talent and ideas, across geographic, national, organizational or 
other lines that might divide us. We believe in humanity. We believe in 
opportunity. We believe in the power of collaboration across borders, and we 
will continue to carry forward our mission.

We also posted this online: 
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] Supporting our global community

2017-01-29 Thread Anita Kuno 

On 2017-01-29 01:34 PM, Jonathan Bryce wrote:

OpenStack is a global open source community. The OpenStack Foundation serves 
members in 180 countries focused on advancing the capabilities and 
accessibility of open infrastructure everywhere. We fundamentally believe 
diversity and collaboration are a powerful force for innovation, and it has 
been amazing to see the product of tens of thousands of people around the world 
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump 
that targets individuals from 7 countries. The order restricts the travel and 
movement of people in a discriminatory way that  results in a restriction on 
access to talent and ideas. It is still unclear how the policies will play out 
and be enforced, but we will be watching, advocating for and supporting our 
community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the 
way the community operates globally. We will continue to support user groups 
and community members that are active in the seven countries named by the 
executive order, alongside our 120+ user groups around the world. However, we 
have two scheduled events in the United States within the next six months that 
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, 
Feb 20-24, a smaller event that will bring together hundreds of upstream 
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event 
that happens every six months.

This executive order could impact some community members' ability to travel to 
Atlanta and Boston, but unfortunately it is too late at this point to change 
the location of these events. The following three OpenStack Summits, however, 
are now scheduled to occur outside of the United States. The next Summit will 
be in November 2017 in Sydney, Australia and we are working to finalize the 
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned 
that his plans to travel from Canada to Atlanta to attend the PTG may be 
restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has 
been contributing code to OpenStack since 2011 and is the CEO and Founder of 
Vexxhost. Blocking his travel would serve no purpose and rob the community of a 
valuable contributor during an important event. If you are concerned about the 
impact or have any questions, please don't hesitate to reach out to me at 
jonat...@openstack.org.


An update: Canada's Immigration Minister held a press conference saying 
that Canadians with dual citizenship won't be affected: 
http://www.cbc.ca/news/politics/canada-hussen-reaction-to-trump-travel-restrictions-1.3957515 
Now that should make things easier for Mohammed Naser but it doesn't 
solve the larger problem affecting the whole community.


Also in the above linked article, the Canadian government will accept 
those travelers refused entry by the United States due to this order, if 
you find yourself in a situation where that information might be of help 
to you.


As I already shared with Jonathan in private, I'm Canadian and plan on 
avoiding as much travel to the US as I am able for the next four years, 
so people not from the 7 named countries are also making choices as a 
consequence of this action.


Confident we can collectively envision a productive future for all of us,
Anita.



Political actions like this highlight the importance of our collective values. 
The Four Opens, the founding principles of our community, exist to ensure the 
free flow of talent and ideas, across geographic, national, organizational or 
other lines that might divide us. We believe in humanity. We believe in 
opportunity. We believe in the power of collaboration across borders, and we 
will continue to carry forward our mission.

We also posted this online: 
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell




__
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] Finding common version for keystoneauth1 and remote keystone

2017-01-29 Thread George Shuklin 

Hello everyone.

I'm working on openstack application. It should works with large range 
of openstacks (at least from Havana till Pica+) and works on large range 
of keystoneauth1 clients (at least from Ubuntu's trusty distro versions 
till Xenial+). I want it to work with any combination of available versions.


I use following steps:

1. Autodiscovery of supported versions:

def _find_local_versions():
version_filter = partial(re.find, 'v\d+')
return filter(version_filter, dir(keystoneauth1.identity))

2. Discovery of remote versions:

r = requests.get(keystone.auth_url)
versions = map(lambda x: x['id'], r.json()['versions']['values'])

3. Matching them together (plus my own application's list of supported 
versions).


4. Use separate code for 'v2' and 'v3' with auto-conversion between 
'tenant_name' and 'project_name' for keystoneauth1.identity.v2/v3


Is this a proper way to do it? Is here a better way to do this? Thanks.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

2017-01-29 Thread Mike Carden 
On Sat, Jan 28, 2017 at 1:29 AM, Alexandra Settle 
wrote:

> Hi OpenStack-Ansible team,
>
>
>
> I would like to propose Amy Marrich for the core team for
> OpenStack-Ansible.
>
>
>
+1I wholeheartedly agree.

-- 
MC
__
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] [Swift] Bug: swift-ring-builder set_weight doesn't work

2017-01-29 Thread Matthew Oliver 
Hey Alexandr,

Thanks for the email. I can help you in this instance, and I'll push up a
patch to correct the usage documentation for the long version of the
set_weight command.


On Sun, Jan 29, 2017 at 8:33 AM, Alexandr Porunov <
alexandr.poru...@gmail.com> wrote:

> Hello,
>
> I can't change a weight of the device.
> Here is a list of my devices:
>
> Devices:id  region  zone  ip address  port  replication ip
>  replication port  name weight partitions balance meta
>  0   1 1   host1  6000   host1
>  6000d1 1000.00   10240.00 bla bla1 bla2
>  1   1 1   host1  6000   host1
>  6000d2 1000.00   10240.00 bla bla1 bla2
>  2   1 1   host1  6000   host1
>  6000d3 1000.00   10240.00 bla bla1 bla2
>
> Here is what I tried to change a weight:
> swift-ring-builder object.builder set_weight --region 1 --zone 1 --ip
> host1 --port 6000 --replication-ip host1 --replication-port 6000 --device
> d1 --meta "bla bla1 bla2" --weight 1000
>

There is a problem with the command as you've sent it. But I agree it isn't
obvious from the usage error. Using the long form (--region, --device, etc)
is just defining search criteria for what you want to change. Not
specifying what you want to change.

So in your case above your looking for a device that already has a weight
of 1000, and your not specifying what the change it to. To fix your
command, you'd need to:

  swift-ring-builder object.builder set_weight --region 1 --zone 1 --ip
host1 --port 6000 --replication-ip host1 --replication-port 6000 --device
d1 --meta "bla bla1 bla2" --weight 1024 1000

NOTE: I am sending in the 1000 as the last option. Obviously as these are
search terms you don't actually have to send them all in, only the ones
that identify the devices or device you want to change.


> swift-ring-builder object.builder set_weight r1z1-host1:6000Rhost1:6000
> d1_"bla bla1 bla2" 2000
>

The short version above is failing, as you forgot to add the '/' seperator
between the port and the device, given your example it should have been:

swift-ring-builder object.builder set_weight
r1z1-host1:6000Rhost1:6000/d1_"bla bla1 bla2" 2000

NOTE: the '/' before the d1.

What your putting in there is just a search for devices to change. You
don't have to put the full string in. I guess if you have a tool that will
use the full definition then fine. I find when wanting to update just 1
host it's easier to do so via the device id:

  swift-ring-builder set_weight d1 2000

In both cases it doesn't work and shows the next information:
>
> swift-ring-builder  set_weight  
>
> [ 
> [--yes]
>
>
>
> or
>
>
>
> swift-ring-builder  set_weight
>
> --region  --zone  --ip  --port 
>
> --replication-ip  --replication-port 
>
> --device  --meta  --weight 
>
> [--yes]
>
>

This usage isn't been very useful here, as it's missing the actual adding
the weight. I'll raise a bug and patch to address this.


>
>
> Where ,  and  are replication ip, hostname
>
> and port.
>
> Any of the options are optional in both cases.
>
>
>
> Resets the devices' weights. No partitions will be reassigned to or
> from
> the device until after running 'rebalance'. This is so you can make
>
> multiple device changes and rebalance them all just once.
>
>
>
> Option --yes assume a yes response to all questions.
>
>
> Please, correct me if it is my fault.
>
> Best regards,
> Alexandr
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
regards,
Matt
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Fuel] Use other NIC

2017-01-29 Thread John Petrini 
I've always run it as a VM. In my opinion there's no real need to dedicate
hardware to Fuel since it doesn't even need to be running all the time.
Once you deploy your cloud you can shut it down until the next time it's
needed.

That will solve you eth0 problem also.

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Sun, Jan 29, 2017 at 1:12 PM, Georgios Dimitrakakis  wrote:

> Hi!
>
> I am a new user of Fuel and would like to deploy it on a physical
> SuperMicro machine. Unfortunately I wasn't able to install it via the ISO
> file since I 've tried several times (with both the community and the
> Mirantis edition) and every time there is a problem with the boot loader
> which cannot be installed correctly thus resulting in a non-bootable
> system. That's the reason I moved on, I installed CentOS and tried to
> follow the instructions from here: http://docs.openstack.org/deve
> loper/fuel-docs/userdocs/fuel-install-guide/install/install_
> install_fuel_master_node.html
>
> Even this attempt was without success since the Fuel bootstrap script is
> looking for connectivity on eth0 which is not connected.
>
> The machine is the property of a DataCenter and out of the 4interfaces
> only the two are cabled and those two are not the first ones but the third
> and forth. So my CentOS has connectivity on "eno3" and "eno4" devices. So
> my question is how can I instruct Fuel to look for connectivity on "eno3"
> rather than on "eth0" or "eno1"?
>
> I did try to disable the first two interfaces from the BIOS but couldn't
> find any option. Then I thought that I could perform a trick and rename the
> devices but that doesn't seem correct...If there isn't any other option I
> will try it but I am sure that Fuel has a way to instract the bootstarp
> script to use a specific device but haven't found it yet.
>
> Your help is much appreciated!
>
> Thank you,
>
>
> George
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Summit considerations

2017-01-29 Thread Martin Millnert 
Hi Marton,

On Sun, Jan 29, 2017 at 07:51:33PM +, Marton Kiss wrote:
> Hi Martin,
> 
> You can find a short official answer to your question:
> https://www.openstack.org/blog/2017/01/supporting-our-global-community/
> 
> Regards,
>   Marton Kiss
>   OpenStack Ambassador

Thanks for the quick response and appropriate message.

Best,
Martin Millnert


signature.asc
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Davanum Srinivas 
Graham,

I've turned it essentially into a no-op now. i'll let the original
authors debate the full revert and other implications.

Thanks,
Dims

On Sun, Jan 29, 2017 at 3:42 PM, Hayes, Graham  wrote:
> On 29/01/2017 15:45, Davanum Srinivas wrote:
>> Graham, Sławek, Joshua,
>>
>> Please take a look at my attempt:
>> https://review.openstack.org/#/c/426576/
>>
>> Thanks,
>> Dims
>>
>
> At this point, a full revert seems like the right idea.
>
> There is a few problem with the warning, not just the amount of them.
>
> Previously we have gone out of our way to avoid these issues in
> libraries. (e.g. [1])
>
> The stack level also seems wrong to me - it is pointing at the
> consuming project not the oslo.context library.
>
> 1 - https://review.openstack.org/#/c/275914/ specifically
> https://review.openstack.org/#/c/275914/3/oslo_versionedobjects/fields.py
> L311.
>
>> On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham  wrote:
>>> On 29/01/17 00:53, Davanum Srinivas wrote:
 Graham, Sławek,

 Have you seen this?

 Neutron has/uses a WarningFixture:
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70

 Which uses filterwarnings:
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80

 Where "always" is being used:
 https://docs.python.org/2/library/warnings.html

 Which prints warnings every single time.

 So, can we please "fix" it in there quickly?

 Thanks,
 Dims
>>>
>>> This is still a broken release - previously in oslo libraries we have
>>> been careful with issuing multiple warnings for a deprecation.
>>>
>>> This is still an issue, with glance-api [0] and I assume others (e.g. we
>>> have not had a designate CI run with the new oslo.context yet)
>>>
>>> Seen as we are going into RC week, it seems very risky to keep it.
>>>
>>> 0 -
>>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22
>>>
 On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
 wrote:
> Hello,
>
> Thanks. I just filled bug report to oslo project:
> https://bugs.launchpad.net/oslo.context/+bug/1660088
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
> On Sat, 28 Jan 2017, Hayes, Graham wrote:
>
>> On 28/01/17 20:54, Sławek Kapłoński wrote:
>>> Hello,
>>>
>>> I pushed today patch in Neutron to gerrit [1] and I noticed that 
>>> functional
>>> tests are failing. In logs there is huge number of deprecation warnings
>>> displayed [2]. Tests are failing because of global timeout is reached 
>>> and IMO
>>> reason of this timeout is this huge amount of deprecation warnings.
>>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is
>>> installed. With oslo.context==2.11.0 all is fine.
>>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You
>>> already know about it and there is some patch to fix it but I couldn't 
>>> find it?
>>
>> Its an oslo.context bug - I can't see one filed for it yet.
>>>
>>> [1] https://review.openstack.org/#/c/426429/
>>> [2] 
>>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
>>>
>>
>> It looks like the warnings function was miss used - this should be set
>> as a once only message. The stack trace level seems suspect, as it
>> points as neutron/context.py as the one sending out the notice, not
>> oslo.contexts base class.
>>
>> [3] seems to the cause - I would suggest reverting this commit and
>> doing a 2.13.0 release. This is going to be *really* noisy. (logstash
>> has 2.5 million items for this string in the last 24 hours)
>>
>> 3 -
>> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[Openstack-operators] Fwd: [openstack-dev] Supporting our global community

2017-01-29 Thread Melvin Hillsman 
In case you missed it.

-- Forwarded message --
From: Jonathan Bryce 
Date: Sun, Jan 29, 2017 at 12:34 PM
Subject: [openstack-dev] Supporting our global community
To: foundat...@lists.openstack.org, "OpenStack Development Mailing List
(not for usage questions)" ,
commun...@openstack.org


OpenStack is a global open source community. The OpenStack Foundation
serves members in 180 countries focused on advancing the capabilities and
accessibility of open infrastructure everywhere. We fundamentally believe
diversity and collaboration are a powerful force for innovation, and it has
been amazing to see the product of tens of thousands of people around the
world over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President
Trump that targets individuals from 7 countries. The order restricts the
travel and movement of people in a discriminatory way that  results in a
restriction on access to talent and ideas. It is still unclear how the
policies will play out and be enforced, but we will be watching, advocating
for and supporting our community members to the best of our ability.

This executive order will not impact the governance of the Foundation or
the way the community operates globally. We will continue to support user
groups and community members that are active in the seven countries named
by the executive order, alongside our 120+ user groups around the world.
However, we have two scheduled events in the United States within the next
six months that will attract a global audience: the PTG (Project Teams
Gathering) in Atlanta, Feb 20-24, a smaller event that will bring together
hundreds of upstream contributors, and the OpenStack Summit in Boston, May
8-11, our larger event that happens every six months.

This executive order could impact some community members' ability to travel
to Atlanta and Boston, but unfortunately it is too late at this point to
change the location of these events. The following three OpenStack Summits,
however, are now scheduled to occur outside of the United States. The next
Summit will be in November 2017 in Sydney, Australia and we are working to
finalize the details so we can announce the following two Summit locations
soon.

We’ve already heard from one community member, Mohammed Naser, who is
concerned that his plans to travel from Canada to Atlanta to attend the PTG
may be restricted, simply because he a dual citizen of Canada and Iraq.
Mohammed has been contributing code to OpenStack since 2011 and is the CEO
and Founder of Vexxhost. Blocking his travel would serve no purpose and rob
the community of a valuable contributor during an important event. If you
are concerned about the impact or have any questions, please don't hesitate
to reach out to me at jonat...@openstack.org.

Political actions like this highlight the importance of our collective
values. The Four Opens, the founding principles of our community, exist to
ensure the free flow of talent and ideas, across geographic, national,
organizational or other lines that might divide us. We believe in humanity.
We believe in opportunity. We believe in the power of collaboration across
borders, and we will continue to carry forward our mission.

We also posted this online: https://www.openstack.org/
blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell



__
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



-- 
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Sławek Kapłoński 
Hello,

My patch [1] to fix it in Neutron is now merged. Thx Ihar and Kevin for
so fast review :)
It looks that now functional tests are working fine.

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

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Sun, 29 Jan 2017, Sławek Kapłoński wrote:

> Hello,
> 
> I made small patch to Neutron to fix [1] this issue. It looks that
> functional tests are fine with it [2].
> Please review it if it makes sense for You :)
> 
> [1] https://review.openstack.org/#/c/426550/
> [2] 
> http://logs.openstack.org/50/426550/1/check/gate-neutron-dsvm-functional-ubuntu-xenial/4b56e71/console.html
> 
> -- 
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
> 
> On Sun, 29 Jan 2017, Sławek Kapłoński wrote:
> 
> > Hello,
> > 
> > Thanks for explaining that. I'm don't know this part well and that's why
> > I asked here if it's oslo or neutron issue.
> > So it looks like it is issue in Neutron nor Oslo.context, right?
> > 
> > -- 
> > Best regards / Pozdrawiam
> > Sławek Kapłoński
> > sla...@kaplonski.pl
> > 
> > On Sat, 28 Jan 2017, Joshua Harlow wrote:
> > 
> > > Yup, all that should be needed is to read the docs and adjust it.
> > > 
> > > "once" - print only the first occurrence of matching warnings, regardless 
> > > of
> > > location
> > > 
> > > "always" - always print matching warnings
> > > 
> > > Changing it to 'once' should gather less repeated logs; IMHO 'always' 
> > > should
> > > never be used, so that was probably just a mistake for whoever committed
> > > that fixture with it set like that.
> > > 
> > > -Josh
> > > 
> > > Davanum Srinivas wrote:
> > > > Graham, Sławek,
> > > > 
> > > > Have you seen this?
> > > > 
> > > > Neutron has/uses a WarningFixture:
> > > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
> > > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
> > > > 
> > > > Which uses filterwarnings:
> > > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
> > > > 
> > > > Where "always" is being used:
> > > > https://docs.python.org/2/library/warnings.html
> > > > 
> > > > Which prints warnings every single time.
> > > > 
> > > > So, can we please "fix" it in there quickly?
> > > > 
> > > > Thanks,
> > > > Dims
> > > > 
> > > > On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
> > > > wrote:
> > > > > Hello,
> > > > > 
> > > > > Thanks. I just filled bug report to oslo project:
> > > > > https://bugs.launchpad.net/oslo.context/+bug/1660088
> > > > > 
> > > > > --
> > > > > Best regards / Pozdrawiam
> > > > > Sławek Kapłoński
> > > > > sla...@kaplonski.pl
> > > > > 
> > > > > On Sat, 28 Jan 2017, Hayes, Graham wrote:
> > > > > 
> > > > > > On 28/01/17 20:54, Sławek Kapłoński wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I pushed today patch in Neutron to gerrit [1] and I noticed that 
> > > > > > > functional
> > > > > > > tests are failing. In logs there is huge number of deprecation 
> > > > > > > warnings
> > > > > > > displayed [2]. Tests are failing because of global timeout is 
> > > > > > > reached and IMO
> > > > > > > reason of this timeout is this huge amount of deprecation 
> > > > > > > warnings.
> > > > > > > I checked that those warnings are disaplyed when 
> > > > > > > oslo.context==2.12.0 is
> > > > > > > installed. With oslo.context==2.11.0 all is fine.
> > > > > > > Should it be reported as bug in Neutron or in Oslo project? Or 
> > > > > > > maybe You
> > > > > > > already know about it and there is some patch to fix it but I 
> > > > > > > couldn't find it?
> > > > > > Its an oslo.context bug - I can't see one filed for it yet.
> > > > > > > [1] https://review.openstack.org/#/c/426429/
> > > > > > > [2] 
> > > > > > > http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
> > > > > > > 
> > > > > > It looks like the warnings function was miss used - this should be 
> > > > > > set
> > > > > > as a once only message. The stack trace level seems suspect, as it
> > > > > > points as neutron/context.py as the one sending out the notice, not
> > > > > > oslo.contexts base class.
> > > > > > 
> > > > > > [3] seems to the cause - I would suggest reverting this commit and
> > > > > > doing a 2.13.0 release. This is going to be *really* noisy. 
> > > > > > (logstash
> > > > > > has 2.5 million items for this string in the last 24 hours)
> > > > > > 
> > > > > > 3 -
> > > > > > https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
> > > > > > 
> > > > > > __
> > > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > > Unsubscribe: 
> > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > >

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Hayes, Graham 
On 29/01/2017 15:45, Davanum Srinivas wrote:
> Graham, Sławek, Joshua,
>
> Please take a look at my attempt:
> https://review.openstack.org/#/c/426576/
>
> Thanks,
> Dims
>

At this point, a full revert seems like the right idea.

There is a few problem with the warning, not just the amount of them.

Previously we have gone out of our way to avoid these issues in
libraries. (e.g. [1])

The stack level also seems wrong to me - it is pointing at the
consuming project not the oslo.context library.

1 - https://review.openstack.org/#/c/275914/ specifically
https://review.openstack.org/#/c/275914/3/oslo_versionedobjects/fields.py 
L311.

> On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham  wrote:
>> On 29/01/17 00:53, Davanum Srinivas wrote:
>>> Graham, Sławek,
>>>
>>> Have you seen this?
>>>
>>> Neutron has/uses a WarningFixture:
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
>>>
>>> Which uses filterwarnings:
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
>>>
>>> Where "always" is being used:
>>> https://docs.python.org/2/library/warnings.html
>>>
>>> Which prints warnings every single time.
>>>
>>> So, can we please "fix" it in there quickly?
>>>
>>> Thanks,
>>> Dims
>>
>> This is still a broken release - previously in oslo libraries we have
>> been careful with issuing multiple warnings for a deprecation.
>>
>> This is still an issue, with glance-api [0] and I assume others (e.g. we
>> have not had a designate CI run with the new oslo.context yet)
>>
>> Seen as we are going into RC week, it seems very risky to keep it.
>>
>> 0 -
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22
>>
>>> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
>>> wrote:
 Hello,

 Thanks. I just filled bug report to oslo project:
 https://bugs.launchpad.net/oslo.context/+bug/1660088

 --
 Best regards / Pozdrawiam
 Sławek Kapłoński
 sla...@kaplonski.pl

 On Sat, 28 Jan 2017, Hayes, Graham wrote:

> On 28/01/17 20:54, Sławek Kapłoński wrote:
>> Hello,
>>
>> I pushed today patch in Neutron to gerrit [1] and I noticed that 
>> functional
>> tests are failing. In logs there is huge number of deprecation warnings
>> displayed [2]. Tests are failing because of global timeout is reached 
>> and IMO
>> reason of this timeout is this huge amount of deprecation warnings.
>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is
>> installed. With oslo.context==2.11.0 all is fine.
>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You
>> already know about it and there is some patch to fix it but I couldn't 
>> find it?
>
> Its an oslo.context bug - I can't see one filed for it yet.
>>
>> [1] https://review.openstack.org/#/c/426429/
>> [2] 
>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
>>
>
> It looks like the warnings function was miss used - this should be set
> as a once only message. The stack trace level seems suspect, as it
> points as neutron/context.py as the one sending out the notice, not
> oslo.contexts base class.
>
> [3] seems to the cause - I would suggest reverting this commit and
> doing a 2.13.0 release. This is going to be *really* noisy. (logstash
> has 2.5 million items for this string in the last 24 hours)
>
> 3 -
> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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


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

Re: [Openstack] Summit considerations

2017-01-29 Thread Marton Kiss 
Hi Martin,

You can find a short official answer to your question:
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Regards,
  Marton Kiss
  OpenStack Ambassador

On Sun, Jan 29, 2017 at 6:39 PM Martin Millnert  wrote:

> Dear fellow stackers,
>
> OpenStack summits should be open to all, regardless of religion.
> Effectively this currently means summits cannot be hosted within
> the US, per my understanding of current US policies.
>
> I wish the board can deliver a policy/statement addressing this.
>
> Best regards,
> fellow human,
> Martin Millnert
>
> PS. No partisan/political discussion required. Objective facts will do. DS
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] Supporting our global community

2017-01-29 Thread Jonathan Bryce 
OpenStack is a global open source community. The OpenStack Foundation serves 
members in 180 countries focused on advancing the capabilities and 
accessibility of open infrastructure everywhere. We fundamentally believe 
diversity and collaboration are a powerful force for innovation, and it has 
been amazing to see the product of tens of thousands of people around the world 
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump 
that targets individuals from 7 countries. The order restricts the travel and 
movement of people in a discriminatory way that  results in a restriction on 
access to talent and ideas. It is still unclear how the policies will play out 
and be enforced, but we will be watching, advocating for and supporting our 
community members to the best of our ability. 

This executive order will not impact the governance of the Foundation or the 
way the community operates globally. We will continue to support user groups 
and community members that are active in the seven countries named by the 
executive order, alongside our 120+ user groups around the world. However, we 
have two scheduled events in the United States within the next six months that 
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, 
Feb 20-24, a smaller event that will bring together hundreds of upstream 
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event 
that happens every six months. 

This executive order could impact some community members' ability to travel to 
Atlanta and Boston, but unfortunately it is too late at this point to change 
the location of these events. The following three OpenStack Summits, however, 
are now scheduled to occur outside of the United States. The next Summit will 
be in November 2017 in Sydney, Australia and we are working to finalize the 
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned 
that his plans to travel from Canada to Atlanta to attend the PTG may be 
restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has 
been contributing code to OpenStack since 2011 and is the CEO and Founder of 
Vexxhost. Blocking his travel would serve no purpose and rob the community of a 
valuable contributor during an important event. If you are concerned about the 
impact or have any questions, please don't hesitate to reach out to me at 
jonat...@openstack.org.

Political actions like this highlight the importance of our collective values. 
The Four Opens, the founding principles of our community, exist to ensure the 
free flow of talent and ideas, across geographic, national, organizational or 
other lines that might divide us. We believe in humanity. We believe in 
opportunity. We believe in the power of collaboration across borders, and we 
will continue to carry forward our mission.

We also posted this online: 
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell



__
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] [Fuel] Use other NIC

2017-01-29 Thread Georgios Dimitrakakis 

Hi!

I am a new user of Fuel and would like to deploy it on a physical 
SuperMicro machine. Unfortunately I wasn't able to install it via the 
ISO file since I 've tried several times (with both the community and 
the Mirantis edition) and every time there is a problem with the boot 
loader which cannot be installed correctly thus resulting in a 
non-bootable system. That's the reason I moved on, I installed CentOS 
and tried to follow the instructions from here: 
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_install_fuel_master_node.html


Even this attempt was without success since the Fuel bootstrap script 
is looking for connectivity on eth0 which is not connected.


The machine is the property of a DataCenter and out of the 4interfaces 
only the two are cabled and those two are not the first ones but the 
third and forth. So my CentOS has connectivity on "eno3" and "eno4" 
devices. So my question is how can I instruct Fuel to look for 
connectivity on "eno3" rather than on "eth0" or "eno1"?


I did try to disable the first two interfaces from the BIOS but 
couldn't find any option. Then I thought that I could perform a trick 
and rename the devices but that doesn't seem correct...If there isn't 
any other option I will try it but I am sure that Fuel has a way to 
instract the bootstarp script to use a specific device but haven't found 
it yet.


Your help is much appreciated!

Thank you,


George

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Summit considerations

2017-01-29 Thread Martin Millnert 
Dear fellow stackers,

OpenStack summits should be open to all, regardless of religion.
Effectively this currently means summits cannot be hosted within
the US, per my understanding of current US policies.

I wish the board can deliver a policy/statement addressing this.

Best regards,
fellow human,
Martin Millnert

PS. No partisan/political discussion required. Objective facts will do. DS


signature.asc
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [trove] status of the gate

2017-01-29 Thread Amrith Kumar 
All:

There are at least a couple of issues that are currently impacting the trove
gate and I'm getting to the bottom of it. The currently known problems are
being handled in a single commit[1].

This currently emcompasses the issues identified in three independent
commits, none of which will be able to merge by themselves [2], [3], and
[4].

There is at least one more issue that I have to wrestle to the ground and it
appears to be some change to the structure of oslo_context that isn't
immediately apparent (at least that's the current hunch).

In the meanwhile, rechecks and changes to trove, and python-troveclient will
merely fail after taking up some useless time in the gate.

I'll try and get this resolved soon, sorry for the delay.

-amrith 

[1] https://review.openstack.org/#/c/426535/
[2] https://review.openstack.org/#/c/425857/
[3] https://review.openstack.org/#/c/423086/
[4] https://review.openstack.org/#/c/412497/


--
Amrith Kumar
GPG: 0x5e48849a9d21a29b



smime.p7s
Description: S/MIME cryptographic 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] [OpenStack-Infra] [infra] Pike PTG Etherpad

2017-01-29 Thread Paul Belanger 
On Wed, Jan 25, 2017 at 11:44:46PM +, Jeremy Stanley wrote:
> Just a heads-up I've been meaning to send for a while... as
> discussed in the last month of Infra meetings we've got a pad here
> for people to pitch ideas of things they want to collaborate on in
> the Infra team space at the PTG on Monday and Tuesday:
> 
> https://etherpad.openstack.org/p/infra-ptg-pike
> 
> It's pretty much a free-for-all; as long as there are at least two
> people who want to work together on a topic and it's Infra-related
> we'll do our best to accommodate. It's also listed with all the
> others so you don't need to remember the pad name:
> 
> https://wiki.openstack.org/wiki/PTG/Pike/Etherpads
> 
> I'm looking forward to seeing lots of you in a few weeks! I and a
> number of other Infra team members will be around for the full week
> so if there's any related discussions you want to have with your own
> teams just give us a heads up and we can try to have someone with
> some Infra-sense pop in and help.
> -- 
> Jeremy Stanley

I've added 2 items I'd like to talk about:

 - Zuulv3: JJB to ansible playbook (onetime) converter.
 - Control plan upgrades to Xenial.

> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Davanum Srinivas 
Graham, Sławek, Joshua,

Please take a look at my attempt:
https://review.openstack.org/#/c/426576/

Thanks,
Dims

On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham  wrote:
> On 29/01/17 00:53, Davanum Srinivas wrote:
>> Graham, Sławek,
>>
>> Have you seen this?
>>
>> Neutron has/uses a WarningFixture:
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
>>
>> Which uses filterwarnings:
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
>>
>> Where "always" is being used:
>> https://docs.python.org/2/library/warnings.html
>>
>> Which prints warnings every single time.
>>
>> So, can we please "fix" it in there quickly?
>>
>> Thanks,
>> Dims
>
> This is still a broken release - previously in oslo libraries we have
> been careful with issuing multiple warnings for a deprecation.
>
> This is still an issue, with glance-api [0] and I assume others (e.g. we
> have not had a designate CI run with the new oslo.context yet)
>
> Seen as we are going into RC week, it seems very risky to keep it.
>
> 0 -
> http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22
>
>> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
>> wrote:
>>> Hello,
>>>
>>> Thanks. I just filled bug report to oslo project:
>>> https://bugs.launchpad.net/oslo.context/+bug/1660088
>>>
>>> --
>>> Best regards / Pozdrawiam
>>> Sławek Kapłoński
>>> sla...@kaplonski.pl
>>>
>>> On Sat, 28 Jan 2017, Hayes, Graham wrote:
>>>
 On 28/01/17 20:54, Sławek Kapłoński wrote:
> Hello,
>
> I pushed today patch in Neutron to gerrit [1] and I noticed that 
> functional
> tests are failing. In logs there is huge number of deprecation warnings
> displayed [2]. Tests are failing because of global timeout is reached and 
> IMO
> reason of this timeout is this huge amount of deprecation warnings.
> I checked that those warnings are disaplyed when oslo.context==2.12.0 is
> installed. With oslo.context==2.11.0 all is fine.
> Should it be reported as bug in Neutron or in Oslo project? Or maybe You
> already know about it and there is some patch to fix it but I couldn't 
> find it?

 Its an oslo.context bug - I can't see one filed for it yet.
>
> [1] https://review.openstack.org/#/c/426429/
> [2] 
> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
>

 It looks like the warnings function was miss used - this should be set
 as a once only message. The stack trace level seems suspect, as it
 points as neutron/context.py as the one sending out the notice, not
 oslo.contexts base class.

 [3] seems to the cause - I would suggest reverting this commit and
 doing a 2.13.0 release. This is going to be *really* noisy. (logstash
 has 2.5 million items for this string in the last 24 hours)

 3 -
 https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea

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



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

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

Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-29 Thread Kekane, Abhishek 
Congratulations Sharing. .
All the best.

Abhishek

Sent from OWA on Android

From: Brian Rosmaita 
Sent: Thursday, January 26, 2017 8:56:30 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Having heard only affirmative responses, I've added Dharini Chandrasekar
to the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome to the Glance core team, Dharini!

On 1/24/17 8:36 AM, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [aodh][vitrage] Aodh generic alarms

2017-01-29 Thread Afek, Ifat (Nokia - IL) 
On 26/01/2017, 20:09, "Julien Danjou"  wrote:

> On Thu, Jan 26 2017, gordon chung wrote:
> 
> > On 26/01/17 11:41 AM, Julien Danjou wrote:
>
> > and vitrage would be an alarm orchestrator?
> 
> Yup, something like that. It could be the one driving Zabbix and
> creating alarms for Zabbix in Aodh when a new host is plugged for
> example.

Vitrage could be enhanced to become an alarm orchestrator. 
The question is – do you want Vitrage to be one? 
And how would you describe the role of an alarm orchestrator/manager? 


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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Hayes, Graham 
On 29/01/17 00:53, Davanum Srinivas wrote:
> Graham, Sławek,
> 
> Have you seen this?
> 
> Neutron has/uses a WarningFixture:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
> 
> Which uses filterwarnings:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
> 
> Where "always" is being used:
> https://docs.python.org/2/library/warnings.html
> 
> Which prints warnings every single time.
> 
> So, can we please "fix" it in there quickly?
> 
> Thanks,
> Dims

This is still a broken release - previously in oslo libraries we have
been careful with issuing multiple warnings for a deprecation.

This is still an issue, with glance-api [0] and I assume others (e.g. we
have not had a designate CI run with the new oslo.context yet)

Seen as we are going into RC week, it seems very risky to keep it.

0 -
http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22

> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  wrote:
>> Hello,
>>
>> Thanks. I just filled bug report to oslo project:
>> https://bugs.launchpad.net/oslo.context/+bug/1660088
>>
>> --
>> Best regards / Pozdrawiam
>> Sławek Kapłoński
>> sla...@kaplonski.pl
>>
>> On Sat, 28 Jan 2017, Hayes, Graham wrote:
>>
>>> On 28/01/17 20:54, Sławek Kapłoński wrote:
 Hello,

 I pushed today patch in Neutron to gerrit [1] and I noticed that functional
 tests are failing. In logs there is huge number of deprecation warnings
 displayed [2]. Tests are failing because of global timeout is reached and 
 IMO
 reason of this timeout is this huge amount of deprecation warnings.
 I checked that those warnings are disaplyed when oslo.context==2.12.0 is
 installed. With oslo.context==2.11.0 all is fine.
 Should it be reported as bug in Neutron or in Oslo project? Or maybe You
 already know about it and there is some patch to fix it but I couldn't 
 find it?
>>>
>>> Its an oslo.context bug - I can't see one filed for it yet.

 [1] https://review.openstack.org/#/c/426429/
 [2] 
 http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html

>>>
>>> It looks like the warnings function was miss used - this should be set
>>> as a once only message. The stack trace level seems suspect, as it
>>> points as neutron/context.py as the one sending out the notice, not
>>> oslo.contexts base class.
>>>
>>> [3] seems to the cause - I would suggest reverting this commit and
>>> doing a 2.13.0 release. This is going to be *really* noisy. (logstash
>>> has 2.5 million items for this string in the last 24 hours)
>>>
>>> 3 -
>>> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 


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

[openstack-dev] [Senlin] PTL candidacy

2017-01-29 Thread Qiming Teng 
The election of Pike PTL is happening during the Chinese Spring
Festival, so many developers from China are not reachable on radar.

As a community, we have done a lot of amazing work during the Ocata
cycle:

- Versioning everything, especially the engine RPCs
- Support status added to profile type, policy type
- Unified notification for message and event format
- Improved support to health policy
- Improved support to container profile
- and many others

It has been an unusual cycle because it is *very* short. It has been an
amazing cycle for the team because we have more hands working on
different things and we have identified quite some new requirements
for the team to contribute.

In the coming cycle, I'd like to again serve as the team facilitator,
which is called the PTL sometimes. My vision for the Pike cycle is as
follows:

- A mature, supported health policy implementation.
- A better management of the container clusters.
- A better support to the NFV use cases.
- A more comprehensive feature support in the dashboard project.
- A stronger team to take the Senlin project to its next level.

These are just things on top of my head. All ideas are welcomed.

- Qiming Teng


__
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] [vitrage] New Vitrage project mascot

2017-01-29 Thread Yujun Zhang 
Not remembering the original design.

This one looks good to me :-)

On Sun, Jan 29, 2017 at 8:18 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi,
>
>
>
> This is the new draft of our Giraffe mascot. The illustrators tried to
> make its skin look more like stained glass.
>
> What do you think?
>
>
>
> Ifat.
>
>
>
>
>
>
>
>
>
> __
> 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] [vitrage] New Vitrage project mascot

2017-01-29 Thread Afek, Ifat (Nokia - IL) 
Hi,

This is the new draft of our Giraffe mascot. The illustrators tried to make its 
skin look more like stained glass.
What do you think?

Ifat.

[cid:image001.png@01D27A3A.128CB9B0]




__
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] [Zun] Propose a change of the Zun core team membership

2017-01-29 Thread Qiming Teng 
+1 to both.

On Mon, Jan 23, 2017 at 10:56:00PM +, Hongbin Lu wrote:
> Hi Zun cores,
> 
> I proposed a change of Zun core team membership as below:
> 
> + Kevin Zhao (kevin-zhao)
> - Haiwei Xu (xu-haiwei)
> 
> Kevin has been working for Zun for a while, and made significant 
> contribution. He submitted several non-trivial patches with high quality. One 
> of his challenging task is adding support of container interactive mode, and 
> it looks he is capable to handle this challenging task (his patches are under 
> reviews now). I think he is a good addition to the core team. Haiwei is a 
> member of the initial core team. Unfortunately, his activity dropped down in 
> the past a few months.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin
> 

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


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

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Sławek Kapłoński 
Hello,

I made small patch to Neutron to fix [1] this issue. It looks that
functional tests are fine with it [2].
Please review it if it makes sense for You :)

[1] https://review.openstack.org/#/c/426550/
[2] 
http://logs.openstack.org/50/426550/1/check/gate-neutron-dsvm-functional-ubuntu-xenial/4b56e71/console.html

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Sun, 29 Jan 2017, Sławek Kapłoński wrote:

> Hello,
> 
> Thanks for explaining that. I'm don't know this part well and that's why
> I asked here if it's oslo or neutron issue.
> So it looks like it is issue in Neutron nor Oslo.context, right?
> 
> -- 
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
> 
> On Sat, 28 Jan 2017, Joshua Harlow wrote:
> 
> > Yup, all that should be needed is to read the docs and adjust it.
> > 
> > "once" - print only the first occurrence of matching warnings, regardless of
> > location
> > 
> > "always" - always print matching warnings
> > 
> > Changing it to 'once' should gather less repeated logs; IMHO 'always' should
> > never be used, so that was probably just a mistake for whoever committed
> > that fixture with it set like that.
> > 
> > -Josh
> > 
> > Davanum Srinivas wrote:
> > > Graham, Sławek,
> > > 
> > > Have you seen this?
> > > 
> > > Neutron has/uses a WarningFixture:
> > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
> > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
> > > 
> > > Which uses filterwarnings:
> > > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
> > > 
> > > Where "always" is being used:
> > > https://docs.python.org/2/library/warnings.html
> > > 
> > > Which prints warnings every single time.
> > > 
> > > So, can we please "fix" it in there quickly?
> > > 
> > > Thanks,
> > > Dims
> > > 
> > > On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
> > > wrote:
> > > > Hello,
> > > > 
> > > > Thanks. I just filled bug report to oslo project:
> > > > https://bugs.launchpad.net/oslo.context/+bug/1660088
> > > > 
> > > > --
> > > > Best regards / Pozdrawiam
> > > > Sławek Kapłoński
> > > > sla...@kaplonski.pl
> > > > 
> > > > On Sat, 28 Jan 2017, Hayes, Graham wrote:
> > > > 
> > > > > On 28/01/17 20:54, Sławek Kapłoński wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I pushed today patch in Neutron to gerrit [1] and I noticed that 
> > > > > > functional
> > > > > > tests are failing. In logs there is huge number of deprecation 
> > > > > > warnings
> > > > > > displayed [2]. Tests are failing because of global timeout is 
> > > > > > reached and IMO
> > > > > > reason of this timeout is this huge amount of deprecation warnings.
> > > > > > I checked that those warnings are disaplyed when 
> > > > > > oslo.context==2.12.0 is
> > > > > > installed. With oslo.context==2.11.0 all is fine.
> > > > > > Should it be reported as bug in Neutron or in Oslo project? Or 
> > > > > > maybe You
> > > > > > already know about it and there is some patch to fix it but I 
> > > > > > couldn't find it?
> > > > > Its an oslo.context bug - I can't see one filed for it yet.
> > > > > > [1] https://review.openstack.org/#/c/426429/
> > > > > > [2] 
> > > > > > http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
> > > > > > 
> > > > > It looks like the warnings function was miss used - this should be set
> > > > > as a once only message. The stack trace level seems suspect, as it
> > > > > points as neutron/context.py as the one sending out the notice, not
> > > > > oslo.contexts base class.
> > > > > 
> > > > > [3] seems to the cause - I would suggest reverting this commit and
> > > > > doing a 2.13.0 release. This is going to be *really* noisy. (logstash
> > > > > has 2.5 million items for this string in the last 24 hours)
> > > > > 
> > > > > 3 -
> > > > > https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
> > > > > 
> > > > > __
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: 
> > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > __
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: 
> > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > 
> > > 
> > > 
> > > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >

Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests

2017-01-29 Thread Sławek Kapłoński 
Hello,

Thanks for explaining that. I'm don't know this part well and that's why
I asked here if it's oslo or neutron issue.
So it looks like it is issue in Neutron nor Oslo.context, right?

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Sat, 28 Jan 2017, Joshua Harlow wrote:

> Yup, all that should be needed is to read the docs and adjust it.
> 
> "once" - print only the first occurrence of matching warnings, regardless of
> location
> 
> "always" - always print matching warnings
> 
> Changing it to 'once' should gather less repeated logs; IMHO 'always' should
> never be used, so that was probably just a mistake for whoever committed
> that fixture with it set like that.
> 
> -Josh
> 
> Davanum Srinivas wrote:
> > Graham, Sławek,
> > 
> > Have you seen this?
> > 
> > Neutron has/uses a WarningFixture:
> > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161
> > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70
> > 
> > Which uses filterwarnings:
> > http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80
> > 
> > Where "always" is being used:
> > https://docs.python.org/2/library/warnings.html
> > 
> > Which prints warnings every single time.
> > 
> > So, can we please "fix" it in there quickly?
> > 
> > Thanks,
> > Dims
> > 
> > On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński  
> > wrote:
> > > Hello,
> > > 
> > > Thanks. I just filled bug report to oslo project:
> > > https://bugs.launchpad.net/oslo.context/+bug/1660088
> > > 
> > > --
> > > Best regards / Pozdrawiam
> > > Sławek Kapłoński
> > > sla...@kaplonski.pl
> > > 
> > > On Sat, 28 Jan 2017, Hayes, Graham wrote:
> > > 
> > > > On 28/01/17 20:54, Sławek Kapłoński wrote:
> > > > > Hello,
> > > > > 
> > > > > I pushed today patch in Neutron to gerrit [1] and I noticed that 
> > > > > functional
> > > > > tests are failing. In logs there is huge number of deprecation 
> > > > > warnings
> > > > > displayed [2]. Tests are failing because of global timeout is reached 
> > > > > and IMO
> > > > > reason of this timeout is this huge amount of deprecation warnings.
> > > > > I checked that those warnings are disaplyed when oslo.context==2.12.0 
> > > > > is
> > > > > installed. With oslo.context==2.11.0 all is fine.
> > > > > Should it be reported as bug in Neutron or in Oslo project? Or maybe 
> > > > > You
> > > > > already know about it and there is some patch to fix it but I 
> > > > > couldn't find it?
> > > > Its an oslo.context bug - I can't see one filed for it yet.
> > > > > [1] https://review.openstack.org/#/c/426429/
> > > > > [2] 
> > > > > http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html
> > > > > 
> > > > It looks like the warnings function was miss used - this should be set
> > > > as a once only message. The stack trace level seems suspect, as it
> > > > points as neutron/context.py as the one sending out the notice, not
> > > > oslo.contexts base class.
> > > > 
> > > > [3] seems to the cause - I would suggest reverting this commit and
> > > > doing a 2.13.0 release. This is going to be *really* noisy. (logstash
> > > > has 2.5 million items for this string in the last 24 hours)
> > > > 
> > > > 3 -
> > > > https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea
> > > > 
> > > > __
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: 
> > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > 
> > 
> > 
> > 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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