Re: [openstack-dev] [manila] propose adding gouthamr to manila core

[Knight, Clinton]

+2  Well earned.

From: Rodrigo Barbieri 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, November 2, 2016 at 8:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [manila] propose adding gouthamr to manila core

+2!

Goutham contributes a lot to manila in all areas and is a very active and 
skilled member of the community!



On Wed, Nov 2, 2016 at 9:36 AM, Silvan Kaiser 
> wrote:
+1!

2016-11-02 13:31 GMT+01:00 Alex Meade 
>:
+1000

On Wed, Nov 2, 2016 at 1:09 PM, Tom Barron 
> wrote:
I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
manila core team.  This is a clear case where he's already been doing
the review work, excelling both qualitatively and quantitatively, as
well as being a valuable committer to the project.  Goutham deserves to
be core and we need the additional bandwidth for the project.  He's
treated as a de facto core by the community already.  Let's make it
official!

-- Tom Barron

__
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



--
Dr. Silvan Kaiser
Quobyte GmbH
Hardenbergplatz 2, 10623 Berlin - Germany
+49-30-814 591 800 - 
www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

__
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



--
Rodrigo Barbieri
MSc Computer Scientist
OpenStack Manila Core Contributor
Federal University of São Carlos

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

Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team

[Knight, Clinton]

+1

Tom will be a great asset for Manila.

Clinton

_
From: Ravi, Goutham >
Sent: Wednesday, August 3, 2016 3:01 PM
Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team
To: OpenStack Development Mailing List (not for usage questions) 
>


(Not a core member, so plus 0.02)

I've learned a ton of things from Tom and continue to do so!

From: Rodrigo Barbieri 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, August 3, 2016 at 2:48 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team


+1

Tom contributes a lot to the Manila project.

--
Rodrigo Barbieri
Computer Scientist
OpenStack Manila Core Contributor
Federal University of S?o Carlos

On Aug 3, 2016 15:42, "Ben Swartzlander" 
> wrote:
Tom (tbarron on IRC) has been working on OpenStack (both cinder and manila) for 
more than 2 years and has spent a great deal of time on Manila reviews in the 
last release. Tom brings another package/distro point of view to the community 
as well as former storage vendor experience.

-Ben Swartzlander
Manila PTL

__
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] Volume Drivers unit tests

[Knight, Clinton]

Nate, you have to press Ctrl-C to see the in-progress test, that’s why you 
don’t see it in the logs.  The bug report shows this and points to the patch 
where it appeared to begin.  https://bugs.launchpad.net/cinder/+bug/1578986

Clinton

From: "Potter, Nathaniel" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, July 21, 2016 at 7:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

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/

Re: [openstack-dev] [Manila] Any updates on share groups?

[Knight, Clinton]

Hi, John.  In the Friday session, the community agreed that groups would 
support multiple share types in the same group, that they would be called 
‘share groups’, and that a higher-level, multi-backend grouping construct to be 
discussed later would be more flexible if based on something like metadata tags 
(allowing shares to have multiple tags).  We haven’t specified the driver 
interface yet, but we’ll aim to keep it similar to the CG interface so driver 
changes should be minimal.

And yes, the community also agreed to adopt a specs process:

* https://review.openstack.org/#/c/311853/
* https://review.openstack.org/#/c/312102/

Clinton




On 5/4/16, 7:16 AM, "John Spray"  wrote:

>Hi all,
>
>Back in the office with only minor jetlag... unfortunately I had to
>skip the discussion last Friday, I was wondering if there was much
>more discussion about how share groups were going to work, especially
>from a driver POV?  The etherpad notes are mainly recap.
>
>I'd like to get ahead of this for the cephfs driver, because we have
>CG support in the existing code.  I'm hoping we'll be able to just
>invisibly map what we used to call CGs into new share groups that
>happen to have the snapshottable group type.
>
>Related: IIRC the group was in favour of adopting a spec process, did
>we agree to do that for the Newton features?
>
>Cheers,
>John
__
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] Proposal: changes to our current testing process

[Knight, Clinton]

On 3/7/16, 10:45 AM, "Eric Harney"  wrote:

>On 03/06/2016 09:35 PM, John Griffith wrote:
>> On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant
>>>> wrote:
>> 
>>> Ivan,
>>>
>>> I agree that our testing needs improvement.  Thanks for starting this
>>> thread.
>>>
>>> With regards to adding a hacking check for tests that run too long ...
>>>are
>>> you thinking that we would have a timer that checks or long running
>>>jobs or
>>> something that checks for long sleeps in the testing code?  Just
>>>curious
>>> your ideas for tackling that situation.  Would be interested in helping
>>> with that, perhaps.
>>>
>>> Thanks!
>>> Jay
>>>
>>>
>>> On 03/02/2016 05:25 AM, Ivan Kolodyazhny wrote:
>>>
>>> Hi Team,
>>>
>>> Here are my thoughts and proposals how to make Cinder testing process
>>> better. I won't cover "3rd party CI's" topic here. I will share my
>>>opinion
>>> about current and feature jobs.
>>>
>>>
>>> Unit-tests
>>>
>>>- Long-running tests. I hope, everybody will agree that unit-tests
>>>must be quite simple and very fast. Unit tests which takes more
>>>than 3-5
>>>seconds should be refactored and/or moved to 'integration' tests.
>>>Thanks to Tom Barron for several fixes like [1]. IMO, we it would be
>>>good to have some hacking checks to prevent such issues in a future.
>>>
>>>- Tests coverage. We don't check it in an automatic way on gates.
>>>Usually, we require to add some unit-tests during code review
>>>process. Why
>>>can't we add coverage job to our CI and do not merge new patches,
>>>with
>>>will decrease tests coverage rate? Maybe, such job could be voting
>>>in a
>>>future to not ignore it. For now, there is not simple way to check
>>>coverage
>>>because 'tox -e cover' output is not useful [2].

The Manila project has a coverage job that may be of interest to Cinder.
It’s not perfect, because sometimes the periodic loopingcall routines run
during the test run and sometimes not, leading to false negatives.  But
most of the time it’s a handy confirmation that the unit test coverage
didn’t decline due to a patch.  Look at the manila-coverage job in this
example:  https://review.openstack.org/#/c/287575/

>>>
>>>
>>> Functional tests for Cinder
>>>
>>> We introduced some functional tests last month [3]. Here is a patch to
>>> infra to add new job [4]. Because these tests were moved from
>>>unit-tests, I
>>> think we're OK to make this job voting. Such tests should not be a
>>> replacement for Tempest. They even could tests Cinder with Fake Driver
>>>to
>>> make it faster and not related on storage backends issues.
>>>
>>>
>>> Tempest in-tree tests
>>>
>>> Sean started work on it [5] and I think it's a good idea to get them in
>>> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a
>>>real
>>> backend.
>>>
>>>
>>> Functional tests for python-brick-cinderclient-ext
>>>
>>> There are patches that introduces functional tests [6] and new job [7].
>>>
>>>
>>> Functional tests for python-cinderclient
>>>
>>> We've got a very limited set of such tests and non-voting job. IMO, we
>>>can
>>> run them even with Cinder Fake Driver to make them not depended on a
>>> storage backend and make it faster. I believe, we can make this job
>>>voting
>>> soon. Also, we need more contributors to this kind of tests.
>>>
>>>
>>> Integrated tests for python-cinderclient
>>>
>>> We need such tests to make sure that we won't break Nova, Heat or other
>>> python-cinderclient consumers with a next merged patch. There is a
>>>thread
>>> in openstack-dev ML about such tests [8] and proposal [9] to introduce
>>>them
>>> to python-cinderclient.
>>>
>>>
>>> Rally tests
>>>
>>> IMO, it would be good to have new Rally scenarios for every patches
>>>like
>>> 'improves performance', 'fixes concurrency issues', etc. Even if we as
>>>a
>>> Cinder community don't have enough time to implement them, we have to
>>>ask
>>> for them in reviews, openstack-dev ML, file Rally bugs and blueprints
>>>if
>>> needed.
>>>
>>>
>>> [1] https://review.openstack.org/#/c/282861/
>>> [2] http://paste.openstack.org/show/488925/
>>> [3] https://review.openstack.org/#/c/267801/
>>> [4] https://review.openstack.org/#/c/287115/
>>> [5] https://review.openstack.org/#/c/274471/
>>> [6] https://review.openstack.org/#/c/265811/
>>> [7] https://review.openstack.org/#/c/265925/
>>> [8]
>>> 
>>>http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.htm
>>>l
>>> [9] https://review.openstack.org/#/c/279432/
>>>
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>>
>>>
>>> ​We could just parse out the tox slowest tests output we already have.
>>> Do
>> something like pylint where we look at existing/current slowest test and
>> balk if that's exceeded.
>> 
>> Thoughts?
>> 
>> John​
>> 
>
>I'm not really sure that writing a "hacking" check for this is a
>worthwhile investment.  (It's not a hacking check really, but something

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Knight, Clinton]

On 2/22/16, 9:33 AM, "Sean McGinnis"  wrote:

>On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote:
>> 
>> So we can't get users to change endpoints, or write our libraries to
>>have
>> sensible defaults, but we're somehow going to magically get consumers
>>to do
>> the much harder job of doing version probes in their code/libraries so
>>that
>> they don't get surprised by unexpected results? This seems to be
>>entirely
>> nuts. If 'they' can't change endpoints (and we can't make the libraries
>>we
>> write just do the right thing without needing to change endpoints) then
>>how
>> are 'they' expected to do the probing magic that will be required at
>>some
>> unpredictable poin tin the future, but which you'll get away without
>>until
>> then?
>> 
>> This would also make us inconsistent with the other projects that have
>> implemented microversions - so we're changing a known working pattern,
>>to
>> try to avoid the problem of a user having to get their settings right if
>> they want new functionality, and hoping this doesn't introduce entirely
>> predictable and foreseeable bugs in the future that can't actually be
>>fixed
>> except by checking/changing every client library out there? There's no
>>way
>> that's a sensible API design.
>> 
>> 
>> --
>> Duncan Thomas
>
>I've spent the weekend thoroughly convincing myself one way or the
>other. The reality is, either one can _work_.
>
>I've asked Scott to proceed with the /v3 endpoint though. Ultimately,
>that is the safest route we can take to protect end users from
>accidentally doing something bad.
>
>A key thing here is that /v2 is not going away. So to an end user that
>doesn't know or doesn't care, things will just keep on working the way
>it has always worked and they don't need to worry.
>
>As far as the argument that some folks are still using /v1 - from my
>perspective they will need to migrate any way. So whether that is going
>to /v2 or /v3, it really won't make much of a difference there.

Ideally it would make no difference.  Like we did in Manila, you can
document for users that /v3 at the 3.0 microversion is functionally
identical to /v2.  So anyone still on /v1 can jump to /v3 with no extra
effort over /v2.

Clinton

>
>Sean (smcginnis)
>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>__
>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] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

[Knight, Clinton]

Hi, John.  This is but one reason the coverage job doesn¹t vote; it has
other known issues.  It is primarily a convenience tool that lets core
reviewers know if they should look more deeply into unit test coverage.
For a new driver such as yours, I typically pull the code and check
coverage for each new file in PyCharm rather than relying on the coverage
job.  Feel free to propose enhancements to the job, though.

Clinton


On 2/10/16, 1:02 PM, "John Spray"  wrote:

>Hi,
>
>I noticed that the coverage script is enforcing a hard limit of 4 on
>the number of extra missing lines introduced.  We have a requirement
>that new drivers have 90% unit test coverage, which the ceph driver
>meets[1], but it's tripping up on that absolute 4 line limit.
>
>What do folks think about tweaking the script to do a different
>calculation, like identifying new files and permitting 10% of the line
>count of the new files to be missed?  Otherwise I think the 90% target
>is going to continually conflict with the manila-coverage CI task.
>
>Cheers,
>John
>
>1. 
>http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/cover
>/manila_share_drivers_cephfs_py.html
>2. 
>http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/conso
>le.html
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Manila] Nominate Rodrigo Barbieri for core reviewer team

[Knight, Clinton]

+1  Great addition.  Welcome, Rodrigo!

Clinton


On 2/2/16, 12:30 PM, "Ben Swartzlander"  wrote:

>Rodrigo (ganso on IRC) joined the Manila project back in the Kilo
>release and has been working on share migration (an important core
>feature) for the last 2 releases. Since Tokyo he has dedicated himself
>to reviews and community participation. I would like to nominate him to
>join the Manila core reviewer team.
>
>-Ben Swartzlander
>Manila PTL
>
>__
>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] [Manila] Midcycle meetup

[Knight, Clinton]

https://etherpad.openstack.org/p/manila-mitaka-midcycle


Clinton

On 1/13/16, 9:51 AM, "Luis Pabon"  wrote:

>Is there a link to the topics or schedule?
>
>- Luis
>
>- Original Message -
>From: "Ben Swartzlander" 
>To: "OpenStack Development Mailing List (not for usage questions)"
>
>Sent: Wednesday, December 9, 2015 8:25:55 PM
>Subject: Re: [openstack-dev] [Manila] Midcycle meetup
>
>On 12/04/2015 04:42 PM, Ben Swartzlander wrote:
>> On 11/19/2015 01:00 PM, Ben Swartzlander wrote:
>>> If you planning to attend the midcycle in any capacity, please vote
>>>your
>>> preferences here:
>>>
>>> https://www.surveymonkey.com/r/BXPLDXT
>>
>> The results of the survey were clear. Most people prefer the week of Jan
>> 12-14.
>>
>> There was an offer to host in Roseville, CA by HP (thanks HP) but at the
>> meeting yesterday most people still preferred the RTP site, so we will
>> be planning on hosting the meeting in RTP that week, unless someone
>> absolutely can't make that week.
>>
>> What remains to be decided is whether we do Tuesday+Wednesday or
>> Wednesday+Thursday. We've tried both, and the 2 day length has worked
>> out very well. I personally lean towards Wednesday+Thursday, but please
>> reply back to me or the list if you have a different preference.
>>
>> We need to finalize the dates so people can make travel arrangements.
>> I'll set the deadline to decide by Tuesday Dec 8 so people will have 5
>> week to make travel plans.
>
>Okay it's final -- we will hold the midcycle meetup on Jan 13-14 at
>NetApp's RTP office.
>
>-Ben
>
>
>>> -Ben
>>>
>>> 
>>>
>>>__
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>>_
>>_
>> OpenStack 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-dev] [Openstack-dev][Manila] running tox py27 - unit tests - very slow - can i run it in parts?

[Knight, Clinton]

@Matt:  The Manila team is writing new 1st-party drivers that should be
much faster & more reliable in the gate.


@Nidhi: Here are a couple more suggestions for working with unit tests
more efficiently:

1. Use PyCharm.  You can set up test configurations to run unit tests on a
single file or a directory, and you can also step through unit tests in
the debugger.

2. Use concurrency.  Using Ubuntu in a VM on my 4-core laptop, I can run
Manila's run_tests.sh script with "--concurrency 4" in ~35 seconds.


Clinton



On 12/22/15, 9:40 AM, "Matt Riedemann"  wrote:

>
>
>On 12/22/2015 6:40 AM, nidhi.h...@wipro.com wrote:
>> Thank you very much Martin.
>>
>>
>> -Original Message-
>> From: Martin Hickey [mailto:martin.hic...@ie.ibm.com]
>> Sent: Tuesday, December 22, 2015 5:56 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>>
>> Subject: Re: [openstack-dev] [Openstack-dev][Manila] running tox py27 -
>>unit tests - very slow - can i run it in parts?
>>
>> Hi Nidhi,
>>
>> You can run particular tests as follows:
>> tox -e py27 
>>
>> For example in neutron, you could run: tox -e py27
>>neutron.tests.unit.test_manager.NeutronManagerTestCase
>>
>> I hope this helps.
>>
>> Regards,
>> Martin
>>
>>
>>
>>
>> From:   
>> To: 
>> Date:   22/12/2015 12:18
>> Subject:[openstack-dev] [Openstack-dev][Manila] running tox
>>py27 - unit
>>  tests - very slow - can i run it in parts?
>>
>>
>>
>> Hi all,
>>
>> While doing some development I changed a unit test.
>> To confirm test is passing or not I am running tox ­v ­epy27.
>> Now its very very slow .. takes a lot of time complete its run ..
>> Difficult during development to make changes and test..
>>
>>
>> Is there a way that I can run some unit tests specifically ?
>> Is there a way that I test unit test in parts .. not all ..
>>
>> during development it will be helpful ..
>>
>> Plz give any idea if you have.
>>
>>
>> Thanks
>> Nidhi
>>
>>
>>
>> The information contained in this electronic message and any
>>attachments to this message are intended for the exclusive use of the
>>addressee(s) and may contain proprietary, confidential or privileged
>>information. If you are not the intended recipient, you should not
>>disseminate, distribute or copy this e-mail. Please notify the sender
>>immediately and destroy all copies of this message and any attachments.
>>WARNING: Computer viruses can be transmitted via email. The recipient
>>should check this email and any attachments for the presence of viruses.
>>The company accepts no liability for any damage caused by any virus
>>transmitted by this email. www.wipro.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
>> The information contained in this electronic message and any
>>attachments to this message are intended for the exclusive use of the
>>addressee(s) and may contain proprietary, confidential or privileged
>>information. If you are not the intended recipient, you should not
>>disseminate, distribute or copy this e-mail. Please notify the sender
>>immediately and destroy all copies of this message and any attachments.
>>WARNING: Computer viruses can be transmitted via email. The recipient
>>should check this email and any attachments for the presence of viruses.
>>The company accepts no liability for any damage caused by any virus
>>transmitted by this email. www.wipro.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
>>
>
>There could be deeper performance issues with manila itself. The
>gate-manila-tempest-dsvm-neutron-multibackend job has been timing out in
>the gate [1].
>
>I have no idea what's taking so long, but if anyone has experience
>profiling manila it's probably worth digging into this since it's
>kicking out changes with the gate failures.
>
>[1] 
>http://logs.openstack.org/65/256865/5/gate/gate-manila-tempest-dsvm-neutro
>n-multibackend/76e7926/console.html#_2015-12-21_17_26_11_797
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__
>OpenStack Development Mailing List (not for usage 

[openstack-dev] [Manila] Generic share groups

[Knight, Clinton]

Hello, Manila-philes.

In last week's Manila IRC meeting, I briefly outlined a proposal for a generic 
share grouping facility in Manila.  It is on the agenda for tomorrow (17 Dec), 
and I've described the ideas more fully on the Manila wiki.  We think this 
would benefit every driver, improve the consistency of the user experience, and 
simplify life for us developers and testers.  Please have a look before the 
meeting!

https://wiki.openstack.org/wiki/Manila/design/manila-generic-groups

Thanks,
Clinton
__
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] [Manila] CephFS native driver

[Knight, Clinton]

Hi, John.  If you want to discuss this in Tokyo, I suggest you add it to
the etherpad:

https://etherpad.openstack.org/p/manila-mitaka-summit-topics


I look forward to meeting you at the Summit.  It¹d be great to see a demo
of your Ceph driver.

Clinton


On 10/7/15, 6:56 AM, "John Spray"  wrote:

>On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty 
>wrote:
>>>
>>> Currently, as you say, a share is accessible to anyone who knows the
>>> auth key (created a the time the share is created).
>>>
>>> For adding the allow/deny path, I'd simply create and remove new ceph
>>> keys for each entity being allowed/denied.
>>
>>
>> Ok, but how does that map to the existing Manila access types (IP, User,
>> Cert) ?
>
>None of the above :-)
>
>Compared with certs, the difference with Ceph is that ceph is issuing
>credentials, rather than authorizing existing credentials[1]. So
>rather than the tenant saying "Here's a certificate that Alice has
>generated and will use to access the filesystem, please authorize it",
>the tenant would say "Please authorize someone called Bob to access
>the share, and let me know the key he should use to prove he is Bob".
>
>As far as I can tell, we can't currently expose that in Manila: the
>missing piece is a way to tag that generated key onto a
>ShareInstanceAccessMapping, so that somebody with the right to read
>from the Manila API can go read Bob's key, and give it to Bob so that
>he can mount the filesystem.
>
>That's why the first-cut compromise is to create a single auth
>identity for accessing the share, and expose the key as part of the
>share's export location.  It's then the user application's job to
>share out that key to whatever hosts need to access it.  The lack of
>Manila-mediated 'allow' is annoying but not intrinsically insecure.
>The security problem with this approach is that we're not providing a
>way to revoke/rotate the key without destroying the share.
>
>So anyway.  This might be a good topic for a conversation at the
>summit (or catch me up on the list if it's already been discussed in
>depth) -- should drivers be allowed to publish generated
>authentication tokens as part of the API for allowing access to a
>share?
>
>John
>
>
>1. Aside: We *could* do a certificate-like model if it was assumed
>that the Manila API consumer knew how to go and talk to Ceph out of
>band to generate their auth identity.  That way, they could go and
>create their auth identity in Ceph, and then ask Manila to grant that
>identity access to the share.  However, it would be pointless, because
>in ceph, anyone who can create an identity can also set the
>capabilities of it (i.e. if they can talk directly to ceph, they don't
>need Manila's permission to access the share).
>
>__
>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] Implementation of ABC MetaClasses

[Knight, Clinton]

Funny you should mention needing all of the CG methods...

A VD group (ConsistencyGroupVD) was added to contain the 4 CG methods from 
Juno.  Then more CG methods were added to VolumeDriver in Kilo, but they 
weren’t added to ConsistencyGroupVD.

But you *can’t* add them to ConsistencyGroupVD until every driver that 
advertises ConsistencyGroupVD has implemented them, lest ConsistencyGroupVD 
imply something false.  You could add them to ‘ConsistencyGroupVD_v2’, but 
that’s ugly.

This whole VD thing seems just a little too neat, since it doesn’t lend itself 
to evolution of features over time.  I’ve wondered if a little runtime 
introspection wouldn’t be a cleaner solution.

--
Clinton Knight

From: John Griffith john.griffi...@gmail.commailto:john.griffi...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, June 19, 2015 at 7:59 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses

​Sure, I suppose that's fine for things like CG and Replication.  Although I 
would think that if somebody implemented something optional like CG's that they 
should be able to figure out they need all of the cg methods
__
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] [Manila] Question to driver maintainers

[Knight, Clinton]

Hi, Igor.  The NetApp cDOT driver can handle share extend/shrink without 
disruption.

Clinton

From: Igor Malinovskiy 
imalinovs...@mirantis.commailto:imalinovs...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, May 18, 2015 at 4:15 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Manila] Question to driver maintainers


Hello, everyone!

My letter is mainly addressed to driver maintainers, but could be interesting 
to everybody.


As you probably know, on Kilo midcycle meetup we discussed share resize 
functionality (extend and shrink) and I already have implemented 'extend' API 
in Generic driver (https://review.openstack.org/182383/). After implementation 
review we

noticed that some backends are able to resize a share without causing 
disruptions, but others might only be able to do it disruptively (Generic 
driver case).


So I want to ask driver maintainers here:

Will your driver be able to do share extending without loss of connectivity?


Depending on your answers, we will handle this situation differently.


Best regards,

Igor Malinovskiy (IRC: u_glide)

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

Re: [openstack-dev] [Manila] Mount automation using Zeroconf

[Knight, Clinton]

Thanks, Luis, I agree with your assessment that one good way to solve this
issue is a publisher-subscriber model.  The publisher would be Manila,
using zeroconf or AMQP or Zaqar (the one I¹m investigating now).  The
subscriber would be a lightweight agent running on the client that listens
for share availability events and handles the mounts.  One open question
is whether Manila needs to store a record of client mounts, without which
it could not influence the mount paths on each client.

Clinton


On 4/27/15, 1:49 PM, Luis Pabon lpa...@redhat.com wrote:

Hi Clinton,
  I think there are two main parts that are needed to automatically mount
Manila shares.  One is the share discovery model, and the other is
enabling the virtual machine to mount the share.  I think the only
benefit to using zeroconf would be as a standard way to broadcast
availability of a network share regardless of protocol.  Manila could
broadcast the availability of a share by using a name like _manila_nfs,
_manila_cifs, _manila_gluster, etc.  Although, even with zeroconf, the
virtual machine still requires an agent to be able to attach the share
for use.  I think the real benefit of using zeroconf is its simplicity.

There could still be other methods we can investigate.  For example
(don't kill me for this ;-)), have a Manila YP NIS service for NFS shares?

- Luis



 
- Original Message -
From: Clinton Knight clinton.kni...@netapp.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Wednesday, April 22, 2015 3:29:50 PM
Subject: [openstack-dev] [Manila] Mount automation using Zeroconf

Hello, Manila-philes.

Back in Paris we started talking about Manila mount automation, whereby
file shares could be automatically mounted on clients, and this will
likely be a topic in Vancouver. So in order to have an informed
discussion at the summit, I'd like to explore a few things beforehand.

Besides brute force approaches like SSH or PsExec, one of the community
suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds
attractive on the surface, but it seems to have a number of limitations:

* No standard way to specify local mount point
* Additional setup required to work beyond the 'local' domain
* Custom software needed on clients to mount advertised shares
* Same issues with network connectivity as any other mount automation
solution 

Does anyone have a clearer idea how Zeroconf might satisfy the need for
Manila mount automation?

Thanks, 
Clinton Knight 
Manila core team 

[1] http://en.wikipedia.org/wiki/Zero-configuration_networking


__
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] [Manila] Two nominations for Manila Core Reviewer Team

[Knight, Clinton]

+1

Clinton Knight

From: Ben Swartzlander b...@swartzlander.orgmailto:b...@swartzlander.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, April 22, 2015 at 2:23 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Manila] Two nominations for Manila Core Reviewer Team

I would like to nominate Thomas Bechtold to join the Manila core reviewer team. 
Thomas has been contributing to Manila for close to 6 months and has provided a 
good number of quality code reviews in addition to a substantial amount of 
contributions. Thomas brings both Oslo experience as well as a packager/distro 
perspective which is especially helpful as Manila starts to get used in more 
production scenarios.

I would also like to nominate Mark Sturdevant. He has also been active in the 
community for about 6 months and has a similar history of code reviews. Mark is 
the maintainer of the HP driver and would add vendor diversity to the core team.

-Ben Swartzlander
Manila PTL

__
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] [Manila] Mount automation using Zeroconf

[Knight, Clinton]

Hello, Manila-philes.

Back in Paris we started talking about Manila mount automation, whereby file 
shares could be automatically mounted on clients, and this will likely be a 
topic in Vancouver.  So in order to have an informed discussion at the summit, 
I'd like to explore a few things beforehand.

Besides brute force approaches like SSH or PsExec, one of the community 
suggestions was to use Zeroconf (aka Bonjour)[1].  Zeroconf sounds attractive 
on the surface, but it seems to have a number of limitations:

   * No standard way to specify local mount point
   * Additional setup required to work beyond the 'local' domain
   * Custom software needed on clients to mount advertised shares
   * Same issues with network connectivity as any other mount automation 
solution

Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila 
mount automation?

Thanks,
Clinton Knight
Manila core team

[1] http://en.wikipedia.org/wiki/Zero-configuration_networking

__
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