Re: [openstack-dev] [Valence] Nominate Anusha and Bian for Valence core reviewers

[Potter, Nathaniel]

+1 from me, they've both been very helpful and have been doing good work :).

-Nate

_
From: Yang, Lin A
Sent: Monday, April 3, 2017 3:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [Valence] Nominate Anusha and Bian for Valence core reviewers


Hi,

I would like to nominate Anusha Ramineni and Bian Hu as core reviewer for 
Valence.

They are excellent contributor to our project since the project's creation, and 
have shown great knowledge in Valence, OpenStack and Python. Please response 
with your +1 or any objections.

Thanks,
Lin.

__
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] Barcelona Summit -- Monday -- openings in command-presence-workshop

[Potter, Nathaniel]

*Forwarding along a message from Malini Bhandaru*

Hello Everyone!

We have a few slots still available on Monday's Command Presence workshop and 
are opening out to a broader audience. Please register if interested. Past 
attendees, despite their many skills and experience, vouched that they had 
learned a trick or two.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16888/command-presence-workshop

Regards,
Malini

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

Re: [openstack-dev] [cinder] Volume Drivers unit tests

[Potter, Nathaniel]

Hi all,

I'm not totally sure that this is the same issue, but lately I've seen the gate 
tests fail while hanging at this point [1], but they say 'ok' rather than 
'inprogress'. Has anyone else come across this? It only happens sometimes, and 
a recheck can get past it. The full log is here [2].

[1] http://paste.openstack.org/show/539314/
[2] 
http://logs.openstack.org/90/341090/6/check/gate-cinder-python34-db/ea65de5/console.html

Thanks,
Nate


From: yang, xing [mailto:xing.y...@emc.com]
Sent: Thursday, July 21, 2016 3:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [cinder] Volume Drivers unit tests

Hi Ivan,

Do you have any logs for the VMAX driver?  We'll take a look.

Thanks,
Xing



From: Ivan Kolodyazhny [e...@e0ne.info]
Sent: Thursday, July 21, 2016 4:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Volume Drivers unit tests
Thank you Xing,

The issue is related both to VNX and VMAX EMC drivers

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Jul 21, 2016 at 11:00 PM, yang, xing 
> wrote:
Hi Ivan,

Thanks for sending this out.  Regarding the issue in the EMC VNX driver unit 
tests, it is tracked by this bug 
https://bugs.launchpad.net/cinder/+bug/1578986.  The driver was recently 
refactored so this is probably a new issue introduced by the refactor.  We are 
investigating this issue.

Thanks,
Xing



From: Ivan Kolodyazhny [e...@e0ne.info]
Sent: Thursday, July 21, 2016 1:02 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cinder] Volume Drivers unit tests
Hi team,

First of all, I would like to apologize, if my mail is be too emotional. I 
spent too much of time to fix it and failed.
TL;DR;

What I want to say is: "Let's spend some time to make our tests better and fix 
all issues". Patch [1] is still unstable. Unit tests can pass or fail in a in a 
random order. Also, I've disabled some tests to pass CI.


Long version:

While I was working on patch "Move drivers unit tests to unit.volume.drivers 
directory" [1] I've found a lot of issues with our unit tests :(. Not all of 
them are already fixed, so that patch is still in progress

What did I found and what should we have to fix:

1) Execution time [2]. I don't want to argue what it unit tests, but 2-4 
seconds per tests should be non-acceptable, IMO.

2) Execution order. Seriously, do you know that our tests will fail or hang if 
execution order will change? Even if one test for diver A failed, some tests 
for driver B will fail too.

3) Lack of mock. It's a root cause for #2. We didn't mock sleeps and event 
loops right. We don't mock RPC call well too [3]. We don't have 
'cinder.openstack.common.rpc.impl_fake' module in Cinder tree.

In some drivers, we use oslo_service.loopingcall.FixedIntervalLoopingCall [4]. 
We've go ZeroIntervalLoopingCall [5] class in Cinder. Do we use it everywhere 
or mock FixedIntervalLoopingCall right? I don't think so, I've hacked 
oslo_service in my env to rise an exception if interval > 0. 297 tests failed. 
It means, our tests use sleep. We have to get rid of this. TBH, not only volume 
drivers unit tests failed. E.g. some API unit tests failed too.


4) Due to #3, sometimes unit tests hangs even on master branch with a minor 
changes.If I stop execution of such tests, usually I see something like [6]. In 
most of cases I see that following drivers' tests hangs: EMC, Huawei, Dell and 
RBD.

It's hard to debug such failures because the lack of tooling for eventlet 
debugging. Eventlet backdoors and gdb-python helps a bit. Maybe somebody know 
better solution for it.

[1] https://review.openstack.org/#/c/320148/
[2] http://paste.openstack.org/show/539081/
[3] https://github.com/openstack/cinder/search?utf8=%E2%9C%93=impl_fake
[4] use 
https://github.com/openstack/oslo.service/blob/master/oslo_service/loopingcall.py#L162
[5] 
https://github.com/openstack/cinder/blob/cfbb5bde4d9b37c39f6813fe685f987f8a990483/cinder/tests/unit/utils.py#L289
[6] http://paste.openstack.org/show/539090/


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

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

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

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

[Potter, Nathaniel]

+1, also not a core but I agree, all I’ve seen from Scott has been super 
knowledgeable and helpful!
-Nate

From: Erlon Cruz [mailto:sombra...@gmail.com]
Sent: Tuesday, June 28, 2016 3:48 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

+1
Not a core but surely is well deserved. Congrats Scott!!

On Tue, Jun 28, 2016 at 5:06 AM, Gorka Eguileor 
> wrote:

+2

Congrats Scott!!


On 27/06, Sean McGinnis wrote:
> I would like to nominate Scott D'Angelo to core. Scott has been very
> involved in the project for a long time now and is always ready to help
> folks out on IRC. His contributions [1] have been very valuable and he
> is a thorough reviewer [2].
>
> Please let me know if there are any objects to this within the next
> week. If there are none I will switch Scott over by next week, unless
> all cores approve prior to then.
>
> Thanks!
>
> Sean McGinnis (smcginnis)
>
> [1] 
> https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
> [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
>
> __
> 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] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

[Potter, Nathaniel]

Hi all,

I did some digging into this on the cinder side, and it gets a little 
complicated. So, before the target and context are passed into the 
_authorize_show method, they’re retrieved through the get_project_hierarchy 
method in cinder.quota_utils [1]. In that method, they will only have their 
parent_id set if the parent_id isn’t the same as their domain_id [2] – if those 
two fields are equal the parent_id field for the returned generic_project 
object will be None. Based on what Henry said it seems like those two fields 
being the same implies that the project is at the top level because its parent 
is the domain itself (I’m guessing that should be true of the admin project?).

So in your example you have the admin project whose domain_id is default and 
whose parent_id is also default, meaning that the parent_id passed into 
_authorize_show is going to be None. If the target project whose quota you want 
to show is a ‘brother’ project to it and has a parent of default in the default 
domain, it should also have no parent set. Do you happen to know which of the 
three exceptions in _authorize_show  you’re hitting?

If the admin context project is the one you pasted, it definitely won’t have a 
set parent because its parent and domain are the same. That would rule out the 
exceptions on line 130 and 134 for your  issue because they both rely on the 
context project having a set parent_id [3]. That would just leave the case 
where the target project for the quota you want to be showing does have a 
non-domain parent and isn’t a part of the subtree for the admin context you’re 
making the call with.

Sorry for a bit of a braindump here, I was just trying to look at all of the 
possibilities to see if any of them could be of help ☺. I think it would 
definitely be useful to know how exactly it’s failing out for you so we can 
make sure it works the way it should, because I believe the intent is 
definitely to have admins be able to view and set all user quotas.

Thanks,
Nate

[1] 
https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L170-L175
[2] 
https://github.com/openstack/cinder/blob/master/cinder/quota_utils.py#L110-L112
[3] 
https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L125-L134



From: Matt Fischer [mailto:m...@mattfischer.com]
Sent: Tuesday, June 28, 2016 7:36 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [cinder] [keystone] cinder quota behavior 
differences after Keystone mitaka upgrade

Thanks Henry,

From a Keystone POV I think it makes sense, but it's causing some operational 
headaches, so I'm curious what the cinder team thinks about this. Not being 
able to see or set someone's quota as an admin is frustrating for dealing with 
support requests.


On Tue, Jun 28, 2016 at 12:38 AM, Henry Nash 
> wrote:
Hi Matt,

So the keystone changes were intentional. From Mitaka onwards, a domain is 
represented as a project which is “acting as a domain” (it has an attribute 
“is_domain” set to true). The situation you describe, where what were top level 
projects now have the project acting as the default domain as their parent, is 
what I would expect to happen after the update.

During Mitaka development, we  worked with the cinder folks - who were to 
re-designing their quota code anyway - and this was modified to take account of 
the project structure. I’m not sure if the quota semantics you see are what was 
intended (I’ll let the cinder team comment). Code can, if desired, distinguish 
the case of top projects that are at the top level, vs projects somewhere way 
down the hierarchy, by looking at the parent and seeing if it is a project 
acting as a domain.

Henry
keystone core
On 27 Jun 2016, at 17:13, Matt Fischer 
> wrote:

We upgraded our dev environment last week to Keystone stable/mitaka. Since then 
we're unable to show or set quotas on projects of which the admin is not a 
member. Looking at the cinder code, it seems that cinder is pulling a project 
list and attempting to determine a hierarchy.  On Liberty Keystone, projects 
seem to lack parents:

https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'}, 
name=admin, parent_id=None, subtree=None>

In Mitaka, it seems that projects are children of the default domain:

http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'}, 
name=admin, parent_id=default, subtree=None>

In Liberty since all projects were parentless, the authorize_* code blocks were 
skipped since both conditionals were false:

https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191

But now in Mitaka, the code is run, and it fails out since the projects are 
"brothers", both with the parent of the default domain, but not hierarchically 
related.

Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

[Potter, Nathaniel]

Hi Alex,

So it's looking to me like my problem was being caused by openstack-ansible 
trying to set up aodh although I didn't configure it and didn't want to use it. 
In ceilometer.conf I found that in the [database] section the metering and 
event connections were correctly looking for mongodb at the IP I set as my bind 
IP, but it was also adding an alarm connection looking for an aodh user in the 
database at localhost. This was causing the ceilometer API to time out 
repeatedly looking for the connection that didn't exist. I don't have any aodh 
configuration set up in /etc/openstack_deploy, so should that line not have 
been put into my ceilometer.conf?

Thanks,
Nate
From: Alex Cantu [mailto:miguel.ca...@rackspace.com]
Sent: Wednesday, February 17, 2016 4:48 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible 
Ceilometer Configuration


Nate,



The mongodb host can be anywhere, so long as it can reached by the ceilometer 
containers (on the same network).

What branch are you working from? Master and Liberty should have no problems as 
far as I'm aware. There is a bug open in regards to authentication with swift, 
but everything else should work fine.



Feel free to send over your ceilometer-api, ceilometer-notification-agent, and 
ceilometer-pollster logs on a pastebin that way I can take a look.



-Alex


From: Potter, Nathaniel 
<nathaniel.pot...@intel.com<mailto:nathaniel.pot...@intel.com>>
Sent: Wednesday, February 17, 2016 4:17 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible 
Ceilometer Configuration

Hi everyone,

I've been working on setting up a 10 node OpenStack installation with 
ceilometer using openstack-ansible, but the way I've configured it isn't 
working for me. I've tried following these instructions 
http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-ceilometer.html,
 doing these steps -


-I set up MongoDB on the metering-infra_host, making the bind_ip the 
br-mgmt IP of that host and creating the ceilometer user.

-In /etc/openstack_deploy/conf.d/ceilometer.yml I have a compute host 
under metering-compute_hosts and the infra host that I configured MongoDB on in 
my metering-infra_hosts.

-I also set the ceilometer_db_ip in user_variables to be equal to the 
bind_ip set on the infra host.

Running the ceilometer installation playbook is successful, but when I log into 
the utility container and try to run ceilometer meter-list it times out and 
says 'Service Unavailable (HTTP 503)'.

Does anyone see anywhere that I went wrong in these steps, should bind-ip be 
set to something else, or should I be configuring this database on the compute 
host rather than the infra? The documentation wasn't entirely clear on that 
point.

Thanks,
Nate

__
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] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

[Potter, Nathaniel]

Hi everyone,

I've been working on setting up a 10 node OpenStack installation with 
ceilometer using openstack-ansible, but the way I've configured it isn't 
working for me. I've tried following these instructions 
http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-ceilometer.html,
 doing these steps -


-I set up MongoDB on the metering-infra_host, making the bind_ip the 
br-mgmt IP of that host and creating the ceilometer user.

-In /etc/openstack_deploy/conf.d/ceilometer.yml I have a compute host 
under metering-compute_hosts and the infra host that I configured MongoDB on in 
my metering-infra_hosts.

-I also set the ceilometer_db_ip in user_variables to be equal to the 
bind_ip set on the infra host.

Running the ceilometer installation playbook is successful, but when I log into 
the utility container and try to run ceilometer meter-list it times out and 
says 'Service Unavailable (HTTP 503)'.

Does anyone see anywhere that I went wrong in these steps, should bind-ip be 
set to something else, or should I be configuring this database on the compute 
host rather than the infra? The documentation wasn't entirely clear on that 
point.

Thanks,
Nate

__
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] [puppet] proposing Alex Schultz part of core team

[Potter, Nathaniel]

I'm not a core, but Alex has been very helpful to me in the past and I think 
he's definitely earned it, +1.

Thanks,
Nate

-Original Message-
From: Emilien Macchi [mailto:emil...@redhat.com] 
Sent: Tuesday, January 5, 2016 9:55 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [puppet] proposing Alex Schultz part of core team

Hi,

Alex Schultz (mwhahaha on IRC) has been a very active contributor over the last 
months in the Puppet OpenStack group:
* He's doing a lot of reviews and they are very valuable. He's in my opinion 
fully aware of our conventions and has nice insights to improve our modules.
* He's very helpful to work on bugs or new features when needed.
* Always present during meetings and actively participating.
* Always on IRC, he never hesitates to give a hand on something or help people.

I think we're very lucky to have Alex part of our group and I would like to 
promote him core reviewer of all our modules.

Team, please vote if you like the idea,

Thanks,
--
Emilien Macchi

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

[openstack-dev] New [puppet] module for Magnum project

[Potter, Nathaniel]

Hi everyone,

I'm interested in starting up a puppet module that will handle the Magnum 
containers project. Would this be something the community might want? Thanks!

Best,
Nate Potter
__
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] New [puppet] module for Magnum project

[Potter, Nathaniel]

Hi Adrian,

Basically it would fall under the same umbrella as all of the other 
puppet-openstack projects, which use puppet automation to configure as well as 
manage various OpenStack projects. An example of a mature one is here for the 
Cinder project: https://github.com/openstack/puppet-cinder. Right now there are 
about 35-40 such puppet modules for different projects in OpenStack, so one 
example of people who might make use of this project are people who have 
already used the existing puppet modules to set up their cloud and wish to 
incorporate Magnum into their cloud using the same tool.

Thanks,
Nate

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: Thursday, October 29, 2015 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] New [puppet] module for Magnum project

Nate,

On Oct 29, 2015, at 11:26 PM, Potter, Nathaniel 
<nathaniel.pot...@intel.com<mailto:nathaniel.pot...@intel.com>> wrote:

Hi everyone,

I’m interested in starting up a puppet module that will handle the Magnum 
containers project. Would this be something the community might want? Thanks!

Best,
Nate Potter

Can you elaborate a bit more about your concept? Who would use this? What 
function would it provide? My guess is that you are suggesting a puppet config 
for adding the Magnum service to an OpenStack cloud. Is that what you meant? If 
so, could you share a reference to an existing one that we could see as an 
example of what you had in mind?

Thanks,

Adrian

__
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