[openstack-dev] [magnum] PTL Candidacy for Pike

2017-01-28 Thread Adrian Otto 
Team,

I announce my candidacy for, and respectfully request your support to serve as 
your Magnum PTL again for the Pike release cycle.

Here are are my achievements and OpenStack experience and that make me the 
best choice for this role:

* Founder of the OpenStack Containers Team
* Established vision and specification for Magnum
* Founding PTL for Magnum
* Core reviewer since the first line of code was contributed in Nov 2014
* Added Magnum to OpenStack
* Led numerous mid cycle meetups as PTL
* 3 terms of experience as elected PTL for Solum
* Involved with OpenStack since Austin Design Summit in 2010

What background and skills help me to serve in this role well:

* Over 20 years of experience in technical leadership positions
* Unmatched experience leading multi-organization collaborations
* Diplomacy skills for inclusion of numerous viewpoints
* Ability to drive consensus and shared vision
* Considerable experience in public speaking, including multiple keynotes at 
OpenStack Summits, and numerous appearances at other events.
* Leadership of collaborative OpenStack design summit sessions
* Deep belief in Open Source, Open Development, Open Design, and Open Community
* I love OpenStack and I love using containers

During the Ocata cycle we worked toward enabling the next generation
of applications with a design for complex clusters, and better integrating
our clusters with OpenStack services for networking and storage.

I am only running for PTL for one project, because I want Magnum to be my
primary focus.  I look forward to your vote, and continued success together.

Thanks,

Adrian Otto



__
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-28 Thread Joshua Harlow 

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

Re: [openstack-dev] [glance] new draft logo of the Glance mascot

2017-01-28 Thread Ian Cordasco 
I love it!

Top-posting from my phone

On Jan 28, 2017 3:08 PM, "Brian Rosmaita" 
wrote:

> Hello Glancers,
>
> Attached is the new draft logo of the Glance mascot.  It looks to me
> like this draft captures the key features we requested (and is much more
> personable than the previous version).  If you have a contrary opinion,
> please reply quickly as Heidi Joy's team wants to have all the logos
> ready before the PTG.
>
> I just want to add that this mascot is going to need a name.  I hereby
> propose "Bikeshed, the Glance chipmunk".  But hopefully someone will
> have a better idea.
>
> cheers,
> brian
>
> On 1/26/17, 9:46 PM, "Heidi Joy Tretheway"  wrote:
> > Hi Brian and Nikhil,
>
> > I'm happy to be able to finally share a new take on the Glance
> > project mascot. We listened to your team's feedback via the survey
> > and we asked a different illustration team to make a chipmunk with
> > its cheek stuffed with nuts, as your team requested. I hope your team
> > likes it! We're pushing hard to have everything ready by the PTG, so
> > please do alert me if there's anything else of major concern. Thank
> > you!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-01-28 Thread Alex Xu 
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-
>> list-filter-sort-parameters>
>> [3] https://review.openstack.org/425533
>> 
>>
>>
>>
>> 
>> __
>> 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
>>
>>
> 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.

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: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-28 Thread Davanum Srinivas 
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
>



-- 
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] [nova] allow_resize_to_same_host true needed for affinity

2017-01-28 Thread David Medberry 
hmmm, it says "not for usage questions" so maybe I'll just propose a change
to nova/conf/compute.py as supporting affined hosts is a perfectly valid
PRODUCTION reason for setting this (above and beyond the single node
testing.)

On Sat, Jan 28, 2017 at 5:15 PM, David Medberry 
wrote:

> Hi,
>
> If you allow "affinity" server via the ServerGroupAffinityFilter it looks
> like you need to set allow_resize_to_same_host to true. Should I add a bit
> more description that this is needed to the description (reason) in the
> config file?
>
> (Users do need to sometimes resize things that are in an affinity group.
> This fails if you can't resize back to the same host.)
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] allow_resize_to_same_host true needed for affinity

2017-01-28 Thread David Medberry 
Hi,

If you allow "affinity" server via the ServerGroupAffinityFilter it looks
like you need to set allow_resize_to_same_host to true. Should I add a bit
more description that this is needed to the description (reason) in the
config file?

(Users do need to sometimes resize things that are in an affinity group.
This fails if you can't resize back to the same host.)
__
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-28 Thread Sławek Kapłoński 
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


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

Re: [openstack-dev] [charms] Incorrect Padding for SSL Cert/Key

2017-01-28 Thread James Beedy 
Ok, progress. I've encoded my cert and key to base64 strings and specified
them in my haproxy config, and seem to be getting past the padding error.
My issue now, is that I am not seeing the cert/key in /etc/ssl/private on
the haproxy host once deployed. I'm thinking specifying the ssl cert/key
will work for the Openstack charms now that I've got the encoding part
squared away. Still stumped by haproxy though ... can't seem to get it
provision the cert/key correctly for the life of me. Possibly there is
something else I'm missing here ...

On Sat, Jan 28, 2017 at 1:04 PM, James Beedy  wrote:

> I'm having issues with padding when trying to specify key/cert as config
> options for Haproxy, and have experienced the same issue in the past, when
> trying to specify key/cert for the Openstack charms. Could someone give an
> example of what the correct padding of a base64 encoded ssl cert might look
> like in the charm config yaml.
>
> My charm config looks like this -> http://paste.ubuntu.com/23882917/
>
> The error I'm getting is this -> http://paste.ubuntu.com/23882921/
>
> Thanks
>
__
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-28 Thread Hayes, Graham 
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-dev] [glance] new draft logo of the Glance mascot

2017-01-28 Thread Brian Rosmaita 
Hello Glancers,

Attached is the new draft logo of the Glance mascot.  It looks to me
like this draft captures the key features we requested (and is much more
personable than the previous version).  If you have a contrary opinion,
please reply quickly as Heidi Joy's team wants to have all the logos
ready before the PTG.

I just want to add that this mascot is going to need a name.  I hereby
propose "Bikeshed, the Glance chipmunk".  But hopefully someone will
have a better idea.

cheers,
brian

On 1/26/17, 9:46 PM, "Heidi Joy Tretheway"  wrote:
> Hi Brian and Nikhil,

> I'm happy to be able to finally share a new take on the Glance
> project mascot. We listened to your team's feedback via the survey
> and we asked a different illustration team to make a chipmunk with
> its cheek stuffed with nuts, as your team requested. I hope your team
> likes it! We're pushing hard to have everything ready by the PTG, so
> please do alert me if there's anything else of major concern. Thank
> you!
__
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] [charms] Incorrect Padding for SSL Cert/Key

2017-01-28 Thread James Beedy 
I'm having issues with padding when trying to specify key/cert as config
options for Haproxy, and have experienced the same issue in the past, when
trying to specify key/cert for the Openstack charms. Could someone give an
example of what the correct padding of a base64 encoded ssl cert might look
like in the charm config yaml.

My charm config looks like this -> http://paste.ubuntu.com/23882917/

The error I'm getting is this -> http://paste.ubuntu.com/23882921/

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

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

2017-01-28 Thread Sławek Kapłoński 
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?

[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
-- 
Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

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

Re: [openstack-dev] [Nova] FFE Request for "restore-vm-diagnostics"

2017-01-28 Thread Matt Riedemann 

On 1/27/2017 1:24 AM, Sergey Nikitin wrote:

Hi, folks!

I'm asking a FFE for restore-vm-diagnostics [1]. There are 3 patches and
yesterday I had five +2 on them from Alex Xu, Stephen Finucane and John
Garbutt. Unfortunatly I lost 3 of them because of nits fixing. I mean
that patches are totally ready for merge and it would be a pity to move
them into next release.

https://review.openstack.org/#/c/394480/
https://review.openstack.org/#/c/399613/
https://review.openstack.org/#/c/355540/

[1] https://blueprints.launchpad.net/nova/+spec/restore-vm-diagnostics



__
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



This is low priority and with less than one week until RC1 I'd prefer to 
just defer this to Pike and get it in early there.


--

Thanks,

Matt Riedemann

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

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

2017-01-28 Thread 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:openstack/nova+branch:master+topic:bp/add-whitelist-for-server-list-filter-sort-parameters

[3] https://review.openstack.org/425533




__
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



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?


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?


Anyway, this seems like something we can defer to Pike unless I'm 
missing something.


--

Thanks,

Matt Riedemann

__
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] [watcher][keystone] getting AttributeError: 'module' object has no attribute 'epoll'

2017-01-28 Thread Pradeep Singh 
Hello All,

I am installing watcher  following[1].
I have executed the commands mentioned here[2] to install the watcher.
When i execute the command 'watcher strategy list', i am getting below
exception:

AttributeError: 'module' object has no attribute 'epoll' in watcher-api.

Full stack trace of the logs are here[3].

Could you please help me in resolving the issue. Thanks.


[1]http://docs.openstack.org/developer/watcher/deploy/installation.html.
[2]http://paste.openstack.org/show/596805/
[3]http://paste.openstack.org/show/596803/
__
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] [stackalytics] how to remove obsoleted email address from one id

2017-01-28 Thread Yujun Zhang 
Stackalytics cores:

I reported a bug on ownership of commits in stackalytics months ago[1]. It
seems to be caused by obsoleted email address in user default data.

In `user_processor`, it merges email addresses from `default_data.json` to
runtime storage[2]. It seems removing email address from user profile is
not possible.

*This will cause a statistic data error when user changes his launchpad id.*

My commits submitted with email address "zhang.yuj...@zte.com.cn" are now
updated to EasyStack instead of ZTE Corporation[3].

Below is the detailed analysis:

I modified my launchpad id from `zhangyujun` to `yujunz` and forced an
association of my email address "zhang.yuj...@zte.com.cn" to `yujunz` by
patching `default_data.json`[4].

Now I realized the association between `zhang.yuj...@zte.com.cn
` still exists in runtime storage. I found my
commits associated to `zhangyujun` and `yujunz` randomly even after trying
to rewrite the old user id[5]

So when another user registered with my old launchpad id[6], it started to
cause statistic chaos not only in user but also in company.

My questions is: *is there any way to remove the obsolete email address*?

[1]: https://bugs.launchpad.net/stackalytics/+bug/1634020
[2]:
http://git.openstack.org/cgit/openstack/stackalytics/tree/stackalytics/processor/user_processor.py#n99
[3]:
http://stackalytics.com/?project_type=opnfv-group=commits_id=zhangyujun
[4]: https://review.openstack.org/#/c/365375/1/etc/default_data.json
[5]: https://review.openstack.org/#/c/384000/1/etc/default_data.json
[6]: https://review.openstack.org/#/c/384801/1/etc/default_data.json
__
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