[openstack-dev] [Cinder]

[Pradip Mukhopadhyay]

Hi,


Is there a way to find out/list down the backends discovered for Cinder?


There is, I guess, no API for get the list of backends.



Thanks,
Pradip
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder]

[vladislav . belogrudov]

Hi,

I'm testing multinode cluster with several cinder-volume instances. The 
latter are configured with iSCSI storage (ZFSSA). To enable HA of 
cinder-volume I had to specify 'host' option, otherwise volumes will be 
bound to a specific host (only good for LVM driver). This works so far 
but I am concerned about reported issues like race conditions:


https://bugzilla.redhat.com/show_bug.cgi?id=1193229

Is Active / Passive requirement for non-local (iSCSI-like) backends 
still valid? I also see 'cluster' option for A/A which still is 'not 
supported':


https://docs.openstack.org/cinder/pike/sample_config.html

Thanks,
Vladislav Belogrudov



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

[John Griffith]

cinder service-list will show all the backends Cinder knows about and
their status.

On Sun, Dec 7, 2014 at 2:52 AM, Pradip Mukhopadhyay
 wrote:
> Hi,
>
>
> Is there a way to find out/list down the backends discovered for Cinder?
>
>
> There is, I guess, no API for get the list of backends.
>
>
>
> Thanks,
> Pradip
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [cinder][qa]

[David Kranz]

Is there a document that describes the api changes from v1 to v2, 
similar to the one documenting nova v2 to v3?


 -David

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

[openstack-dev] Cinder + taskflow

[Joshua Harlow]

Hi all,

After talking with john g. about taskflow in cinder and seeing more and
more reviews showing up I wanted to start a thread to gather all our
lessons learned and how we can improve a little before continuing to add
too many more refactoring and more reviews (making sure everyone is
understands the larger goal and larger picture of switching pieces of
cinder - piece by piece - to taskflow).

Just to catch everyone up.

Taskflow started integrating with cinder in havana and there has been some
continued work around these changes:

- https://review.openstack.org/#/c/58724/
- https://review.openstack.org/#/c/66283/
- https://review.openstack.org/#/c/62671/

There has also been a few other pieces of work going in (forgive me if I
missed any...):

- https://review.openstack.org/#/c/64469/
- https://review.openstack.org/#/c/69329/
- https://review.openstack.org/#/c/64026/

I think now would be a good time (and seems like a good idea) to create
the discussion to learn how people are using taskflow, common patterns
people like, don't like, common refactoring idioms that are occurring and
most importantly to make sure that we refactor with a purpose and not just
refactor for refactoring sake (which can be harmful if not done
correctly). So to get a kind of forward and unified momentum behind
further adjustments I'd just like to make sure we are all aligned and
understood on the benefits and yes even the drawbacks that these
refactorings bring.

So here is my little list of benefits:

- Objects that do just one thing (a common pattern I am seeing is
determining what the one thing is, without making it to granular that its
hard to read).
- Combining these objects together in a well-defined way (once again it
has to be carefully done to not create to much granularness).
- Ability to test these tasks and flows via mocking (something that is
harder when its not split up like this).
- Features that aren't currently used such as state-persistence (but will
help cinder become more crash-resistant in the future).
  - This one will itself need to be understood before doing [I started
etherpad @ https://etherpad.openstack.org/p/cinder-taskflow-persistence
for this].

List of drawbacks (or potential drawbacks):

- Having a understanding of what taskflow is doing adds on a new layer of
things to know (hopefully docs help in this area, that was there goal).
- Selecting to granular of a task or flow; makes it harder to
follow/understand the task/flow logic.
- Focuses on the long-term (not necessarily short-term) state-management
concerns (can't refactor rome in a day).
- Taskflow is being developed at the same time cinder is.

I'd be very interested in hearing about others experiences and to make
sure that we discuss the changes (in a well documented and agreed on
approach) before jumping to much into the 'deep end' with a large amount
of refactoring (aka, refactoring with a purpose). Let's make this thread
as useful as we can and try to see how we can unify all these refactorings
behind a common (and documented & agreed-on) purpose.

A thought, for the reviews above, I think it would be very useful to
etherpad/writeup more in the blueprint what the 'refactoring with a
purpose' is so that its more known to future readers (and for active
reviewers), hopefully this email can start to help clarify that purpose so
that things proceed as smoothly as possible.

-Josh


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

[openstack-dev] [Cinder][Manila]

[Alun Champion]

I'm sure this has been discussed I just couldn't find any reference to
it, perhaps someone can point me to the discussion/rationale.
Is there any reason why there needs to be another service to present a
control-plane to storage? Obviously object storage is different as
that is presenting a data-plane API but from a control-plane I'm
confused why there needs to be another service, surely control-planes
are pretty similar and the underlying networking issues for iSCSI
would be similar for NFS/CIFS.
Trove is looking to be a general purpose data container
(control-plane) service for traditional RDBMS, NoSQL, KeyValue, etc.,
why is the Cinder API not suitable for providing a general purpose
storage container (control-plane) service?

Creating separate services will complicate other services, e.g. Trove.

Thoughts?

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

[openstack-dev] [cinder] [cinderdriver]

[Mardan Raghuwanshi]

Hello All,

I developed cinder drivers for CloudByte's ElastiStor. Now we want to make
our driver as a part of core openstack release, but I am not aware of
openstack commit process.
Please help me...



Thanks,
Mardan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][nova]

[李俊波]

Hello Nova, Cinder developers,

 

I would like to ask you a question concerns a Cinder patch [1].

 

In this patch, it mentioned that RBD features were incompatible with
multi-attach, which disabled multi-attach for RBD. I would like to know
which RBD features that are incompatible?

 

In the Bug [2], yao ning also raised this question, and in his envrionment,
it proved that they did not find ant problems when enable this feature.

 

So, I also would like to know which features in ceph will make this feature
unsafe? 

 

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

[2] https://bugs.launchpad.net/cinder/+bug/1535815

 

 

Best wishes and Regards

junboli

 

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

[Jay S Bryant]

Vladislav,

Setting up the volume instances as active/passive has been done by a 
number of users for quite some time and it has been working fine, as far 
as I know.  If you are looking for an HA setup right now, that is the 
safest approach.


We have been working on getting HA (Active/Active) support into Cinder 
and much of the support is there but we are still working on determining 
how we can test and validate that drivers do functions in Active/Active 
mode.  Once we have agreement on the testing process you will see 
drivers getting marked as supporting Active/Active HA.


Hope this information helps.

Jay



On 9/12/2017 8:09 AM, vladislav.belogru...@oracle.com wrote:

Hi,

I'm testing multinode cluster with several cinder-volume instances. 
The latter are configured with iSCSI storage (ZFSSA). To enable HA of 
cinder-volume I had to specify 'host' option, otherwise volumes will 
be bound to a specific host (only good for LVM driver). This works so 
far but I am concerned about reported issues like race conditions:


    https://bugzilla.redhat.com/show_bug.cgi?id=1193229

Is Active / Passive requirement for non-local (iSCSI-like) backends 
still valid? I also see 'cluster' option for A/A which still is 'not 
supported':


    https://docs.openstack.org/cinder/pike/sample_config.html

Thanks,
Vladislav Belogrudov



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [cinder] [ceilometer]

[Jiong Liu]

Hello Cinder/Ceilometer community,

 

Is there any guideline on using `cinder-volume-usage-audit` command?

 

Search through cinder/ceilometer logs, I find some messages are sent to
ceilometer-collector.

How do I check the output of this command in ceilometer? Do you have any
suggestion?

 

Looking forward to your comments. Thanks.

 

BR,

Jeremy Liu

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

[openstack-dev] [cinder] HA issues

[Dulko, Michal]

Hi all!

At the summit during crossproject HA session there were multiple Cinder issues 
mentioned. These can be found in this etherpad: 
https://etherpad.openstack.org/p/kilo-crossproject-ha-integration

Is there any ongoing effort to fix these issues? Is there an idea how to 
approach any of them?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Kilo Deadlines

[Mike Perez]

* Blueprint/Spec approval deadline - February 15th
* Code freeze for all features - March 10th

After blueprint/spec approval deadline date has passed, you may
request exception by:

1) Email the Openstack Dev mailing list with "[cinder] Request Spec
Freeze Exception" in the subject.
2) The spec is reviewed the usual way, but should be a high priority to get in.

These deadlines were agreed on in the Cinder IRC meeting [1].

--
Mike Perez

[1] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303

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

[openstack-dev] [Cinder] Rolling upgrades

[Michał Dulko]

Hi,

At the meeting recently it was mentioned that our rolling upgrades
efforts are pursuing an "elusive unicorn" that makes development a lot
more complicated and restricted. I want to try to clarify this a bit,
explain the strategy more and give an update on the status of the whole
affair.

So first of all - it's definitely achievable, as Nova supports rolling
upgrades from Kilo. It makes developer's life harder, but the feature is
useful, e.g. CERN was able to upgrade their compute nodes after control
plane services in their enormously big environment in their Juno->Kilo
upgrade [1].

Rolling upgrades are all about interoperability of services running in
different versions. We want to give operators ability to upgrade service
instances one-by-one, starting form c-api, through c-sch to c-vol and
c-bak. Moreover we want to be sure that old and new version of a single
service can coexist. This means we need to be backward compatible with
at least one previous release. There are 3 planes on which
incompatibilities may happen:
* API of RPC methods
* Structure of composite data sent over RPC
* DB schemas

API of RPC methods
--
Here we're strictly following Nova's solution described in [2]. We need
to support RPC version pinning, so each RPC API addition needs to be
versioned and we need to be able to downgrade the request to required
version in rpcapi.py modules. On the other side manager.py should be
able to process the request even when it doesn't receive newly added
parameter. There are already some examples of this approach in tree
([3], [4]). Until the upgrade is completed the RPC API version is pinned
so everything should be compatible with older release. Once only new
services are running the pin may be released.

Structure of composite data sent over RPC
-
Again RPC version pinning is utilized with addition of versioned
objects. Before sending the object we will translate it to the lower
version - according to the version pin. This will make sure that object
can be understand by older services. Note that newer services can
translate the object back to the new version when receiving an old one.

DB schemas
--
This is a hard one. We've needed to adapt approach described in [5] to
our needs as we're calling the DB from all of our services and not only
from nova-conductor as Nova does. This means that in case of a
non-backward compatible migration we need to stretch the process through
3 releases. Good news is that we haven't needed such migration since
Juno (in M we have a few candidates… :(). Process for Cinder is
described in [6]. In general we want to ban migrations that are
non-backward compatible or exclusively lock the table for an extended
period of time ([7] is a good source of truth for MySQL) and allow them
only if they follow 3-relase period of migration (so that N+2 release
has no notion of a column or table so we can drop it).

Right now we're finishing the oslo.versionedobjects adoption -
outstanding patches can be found in [8] (there are still a few to come -
look at table at the bottom of [9]). In case of DB schemas upgrades
we've merged the spec and a test that's banning contracting migrations
is in review [10]. In case of RPC API compatibility I'm actively
reviewing the patches to make sure every change there is done properly.

Apart from that in the backlog is documenting all this in devref and
implementing partial upgrade Grenade tests that will gate on version
interoperability.

I hope this clarifies a bit how we're progressing to be able to upgrade
Cinder with minimal or no downtime.

[1]
http://openstack-in-production.blogspot.de/2015/11/our-cloud-in-kilo.html
[2] http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/
[3]
https://github.com/openstack/cinder/blob/12e4d9236/cinder/scheduler/rpcapi.py#L89-L93
[4]
https://github.com/openstack/cinder/blob/12e4d9236/cinder/scheduler/manager.py#L124-L128
[5]
http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
[6]
https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/online-schema-upgrades.html
[7]
https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html
[8]
https://review.openstack.org/#/q/branch:master+topic:bp/cinder-objects,n,z
[9] https://etherpad.openstack.org/p/cinder-rolling-upgrade
[10]
https://review.openstack.org/#/q/branch:master+topic:bp/online-schema-upgrades,n,z

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

[openstack-dev] [cinder] Brocade CI

[Mike Perez]

People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

-- 
Mike Perez

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

[openstack-dev] [Cinder] PTL Candidacy

[Sean McGinnis]

Hello everyone,

I'm announcing my candidacy for Cinder PTL for the Mitaka release.

The Cinder team has made great progress. We've not only grown the
number of supported backend drivers, but we've made significant
improvements to the core code and raised the quality of existing
and incoming code contributions. While there are still many things
that need more polish, we are headed in the right direction and
block storage is a strong, stable component to many OpenStack clouds.

Mike and John have provided the leadership to get the project where
it is today. I would like to keep that momentum going.

I've spent over a decade finding new and interesting ways to create
and delete volumes. I also work across many different product teams
and have had a lot of experience collaborating with groups to find
a balance between the work being done to best benefit all involved.

I think I can use this experience to foster collaboration both within
the Cinder team as well as between Cinder and other related projects
that interact with storage services.

Some topics I would like to see focused on for the Mitaka release
would be:

 * Complete work of making the Cinder code Python3 compatible.
 * Complete conversion to objects.
 * Sort out object inheritance and appropriate use of ABC.
 * Continued stabilization of third party CI.
 * Make sure there is a good core feature set regardless of backend type.
 * Reevaluate our deadlines to make sure core feature work gets enough
   time and allows drivers to implement support.

While there are some things I think we need to do to move the project
forward, I am mostly open to the needs of the community as a whole
and making sure that what we are doing is benefiting OpenStack and
making it a simpler, easy to use, and ubiquitous platform for the 
cloud.

Thank you for your consideration!

Sean McGinnis (smcginnis)

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

[openstack-dev] [Cinder] PTL Candidacy

[Duncan Thomas]

Hi

I'd like to announce my candidacy for Cinder PTL.

I've been actively involved in Cinder as a core since it was split out of
Nova, and with nova-volume before that. I've been involved in mentoring new
people, reviews, code and community discussions all of that time. I've been
an operator of Cinder in a large public cloud, including being called out
at 4am when something breaks, giving me a great deal of sympathy for
operational matters. Cinder has grown and matured at an impressive rate,
and I now feel the project is at an important decision point about what we
want to be going forward. With that in mind, my main aims as a PTL would be
as follows:

- Make the ideology of Cinder - standard features, good discoverability
where universal implementation of a feature isn;t possible, and keeping the
tenant experience as clean as possible - the admin experience should be as
clean as possible without compromising the tenant experience.

- Matching our bleeding edge velocity with our trailing edge velocity - we
merged a bunch of features that only work in a very, very limited number of
drivers. We need to push implementation of these features as widely as
possible, and where a reasonable generic implementation can be made then we
need to push that as a requirement for adding the feature.

- Stability and quality - our unit test test coverage has not improved
significantly in terms of lines of code or quality of tests, and our
tempest coverage has got worse. I suggest that we push for more tempest
tests to go with new features. The reliability and usability of third party
CI can also be incrementally improved - we've got nearly every driver being
tested now, lets make the test output more useful to developers.

- Communication - Mike demonstrated the great value of clear, regular and
open communication and I intend to keep building on this example

- Less bureaucracy that gets in the way - I think that the way we did
prioritisation in Liberty, while a good first attempt, can be improved,
particularly with dropping the review priority of tasks that are blocked
waiting for rework, so that more smaller patches can bubble up the priority
list. I'd also like to look at using review priority to encourage good
community behaviour (reviews of other people's code, bug fixes and triage,
test writing, documentation, etc)

- Finishing open work before starting more work - we have a large list of
part-implemented tasks, so we should avoiding taking on new work that
doesn't drive these goals forward.




The things I'd like to see finished in the M release:
- Replication. At least 5 drivers implementing it.
- Smooth upgrade experience - even if we can't get it to zero downtime, I'd
like a well documented, tested upgrade path and a well understood list of
work to be finished..
- H/A - I believe we can have and should have a cinder experience where the
failure of any one node does not affect the externals of cinder, without
requiring pacemaker.



Thank you for your consideration.

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

[openstack-dev] [Cinder] PTL Candidacy

[Walter A. Boring IV]

Cinder community,

I am announcing my candidacy for Cinder PTL for the Mitaka release.

Cinder is a fundamental piece of the puzzle for the success
of OpenStack.  I've been lucky enough to work on Cinder since the
Grizzly release cycle.  The Cinder community has grown every release,
and we've gotten a lot of great features implemented as well as many
new drivers.  We've instituted a baseline requirement for third party
CI, which is critical to the quality of Cinder.  I believe this goes
a long way to proving to deployers that Cinder is dedicated to building
a quality product.

I believe the single best component of the project, is the diverse
community itself.  We have people from all over the world helping
Cinder grow.  We have companies that compete directly with each other,
in the marketplace for customers, working together to solve complex
problems.

I would like to continue to encourage more driver developers to get
involved in Cinder core features.   This is the future of the
community itself and the lifeblood of Cinder.  We also need to get more
active in Nova to ensure that the interactions are stable.

The following is a list of a few areas of focus that I would
like to encourage the community to consider over the next release.

* Solidify all/any deadlines milestone deadlines early in the release
* Iron out the Nova <--> Cinder interactions
* Get active-active c-vol services working
* Get driver bug fixes into previous releases
* Continue the stabilization of the 3rd party CI system.
* Support any efforts to integrate with Ironic


There is always a long list of cool stuff to work on and issues to fix
in Cinder, and the more participation we have with Cinder core the better.
We have a strong and vibrant community and I look forward to working on
Cinder for many releases ahead.

Thank you for considering me.

Walter A. Boring IV (hemna)

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

[openstack-dev] [Cinder] PTL Candidacy

[Ivan Kolodyazhny]

Hello everyone,

I'm announcing my candidacy for Cinder PTL for the Mitaka release.

First of all, I would like to thank John and Mike for their great and hard
work making Cinder such a great project with good and a big community.

As a Cinder community we made a great progress not only with new features,
but with improving Cinder quality too. Our community grows quickly and
we are glad to see new contributors again and again.

I've started work with OpenStack since Diablo release. I’ve been an active
contributor to Cinder since Juno cycle [1].

As a Cinder PTL I would like to focus on the following areas of improvements
for the next release cycle:

* Finally move all projects to Cinder API v2 and prepare to remove v1 API.

* Better Cinder integration with other OpenStack projects like Nova and
  Ironic, support Keystone API v3.

* Continue to work on Cinder backups improvements like: scaling,
performance,
  etc.

* Work with driver vendors to stabilize third party CI. I believe,
  every PTL candidate will have this item on the list.

* Improve Cinder test coverage and quality: we need to get functional tests,
  better Tempest and Rally coverage, make our unit tests better

We need to continue to be open for developers community and operators
needs. Improving quality and growing the community are the tasks which
should
be done indefinitely. But we need to keep balance between new features
development and support of existing ones by all drivers and stability of
Cinder project.

[1] http://stackalytics.com/report/contribution/cinder/180

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

[openstack-dev] [Cinder] PTL Candidacy

[Sean McGinnis]

Hey everyone,

Wow, how six months flies! I'd like to announce my candidacy to continue on as
Cinder PTL for the Newton release cycle.

A lot has been accomplished in the Mitaka cycle. After a lot of work by many
folks, over a couple development cycles, we now have what we consider a "tech
preview" of rolling upgrades. It just hasn't had enough runtime and testing for
us to say it's "official". We will likely need to fix a few minor things in the
Newton timeframe before it's fully baked and reliable. But it has come a long
way and I'm really happy with the progress that has been made.

Another priority we had identified for Mitaka was active/active high
availability of the c-vol service. We were not able to complete that work, but
many pieces have been put in place to support that in Newton. We fixed several
API races and added the ability to use something like tooz for locking. These
are foundation pieces for us to be able to start breaking out things and
running in a reliable active/active configuration.

Microversion support has been added and there is now a new v3 API endpoint.
This was a bit of a controversy as we really had just started to get folks to
move off of v1 to v2. To be safe though I decided it would protect end users
better to have a clearly separate new API endpoint for the microversion
compatibility. And now hopefully it is our last.

Replication was another slightly controversial feature implemented. Late in
Liberty we finally agreed on a spec for a v2 version of replication. The v2
spec was approved so late that no one actually had time to implement it for
that release. As we started to implement it for Mitaka we found that a lot of
compromises had crept in during the spec review that it had the risk of being
too complex and having some of the issues we were trying to get rid of by
moving away from replication v1. At our midcycle we had a lot of discussion on
replication and finally decided to change course before it was too late.
Whether that ends up being the best choice when we look back a year from now or
not, I'm proud of the team that we were willing to put on the brakes and make
changes - even though it was more work for us - before we released something
out to end users that would have caused problems or a poor experience.

Other than that, there's mostly been a lot of good bug fixes. Eight new drivers
have been added from (I think) five different vendors. The os-brick library is
now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common
storage management operations so there is not a duplication and disconnect of
code between the two projects. We were also able to add a Brick cinder client
extension to be able to perform storage management on nodes without Nova (bare
metal, etc.).

None of this goodness was from me.

We have a bunch of smart and active members of the Cinder community. They are
the ones that are making a difference, working across the community, and
making sure Cinder is a solid component in an OpenStack cloud.

Being part of the Cinder community has been one of the best and most engaging
parts of my career. I am lucky enough to have support from my company to be
able to devote time to being a part of this. I would love the opportunity to
continue as PTL to not just contribute where I can, but to make sure the folks
doing the heavy lifting have the support and project organization they need to
avoid distractions and be able to focus on getting the important stuff done.

I think in Newton we need to continue the momentum and get Active/Active Cinder
volume service support implemented. We need to continue to work closely with
the Nova team to make sure our interaction is correct and solid. But also work
to make Cinder a useful storage management interface in environments without
Nova. I will continue to encourage developer involvement and vendor support.
We need to improve the user experience with better error reporting when things
go wrong. And last, but definitely not least, we need to continue to expand our
testing - unit, functional, and tempest - to make sure we can avoid those
errors and deliver a high quality and solid solution.

I really feel I'm just getting into the swing of things. I would love the
opportunity to serve as PTL for the Newton release.

Thank you for your consideration.

Sean McGinnis (smcginnis)


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

[openstack-dev] [Cinder] Summit Social

[Sean McGinnis]

The Cinder team (and friends) will be getting together for an informal
outing tonight.

The plan is to meet at Easy Tiger at 6 tonight:

http://easytigeraustin.com/

All are welcome!

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-dev] [cinder] volume replication

[Ronen Kat]

Ruijing,
hi,

Are you discussing the network/fabric
between Storage A and Storage B? 
If so, assumption in Cinder is that
this is done in advance by the storage administrator.
The design discussions for replication
resulted in that the driver is fully responsible for replication and it
is up to the driver to implement and manage replication on its own.
Hence, all vendor specific setup actions
like creating volume pools, setup network on the storage side are considered
prerequisite actions and outside the scope of the Cinder flows.

If someone feels that is not the case,
or should not be the case, feel free to chime in.

Or does this relates to setting up the
data path for accessing both Storage A and Storage B?
Should this be setup in advance? When
we attach the primary volume to the VM? Or when promoting the replica to
be primary?

-- Ronen



From:      
 "Guo, Ruijing"

To:      
 "OpenStack Development
Mailing List (not for usage questions)" 
Date:      
 16/02/2015 02:29 AM
Subject:    
   Re: [openstack-dev]
[cinder] documenting volume replication




Hi, Ronen
 
3) I mean storage based replication.
In normal, volume replication support FC or iSCSI. We need to setup FC
or iSCSI before we do volume replication.
 
Case 1)  
 
Host --FC--Storage
A ---iSCSI  Storage B FC- Host
 
Case 2)
 
Host --FC--Storage
A ---FC  Storage B FC- Host
 
As above diagram, we need
to setup connection (iSCSI or FC) between storage A and Storage B.
 
For FC, we need to zone storage
A & storage B in FC switch.
 
Thanks,
-Ruijing
 
From: Ronen Kat [mailto:ronen...@il.ibm.com]

Sent: Sunday, February 15, 2015 4:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] documenting volume replication
 
Hi Ruijing,


Thanks for the comments. 
Re (1) - driver can implement replication in any means the driver see fit.
It can be exported and be available to the scheduler/drive via the "capabilities"
or "driver" extra-spec prefixes.

Re (3) - Not sure I see how this relates to storage side replication, do
you refer to host side replication?


Ronen 



From:        "Guo,
Ruijing" <ruijing@intel.com>

To:        "OpenStack
Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>

Date:        15/02/2015
03:41 AM 
Subject:        Re:
[openstack-dev] [cinder] documenting volume replication






Hi, Ronen, 
  
I don’t know how to edit https://etherpad.openstack.org/p/cinder-replication-redoc
and add some comments in email.

  
1.     We may add asynchronized and synchronized type for replication.

2.     We may add CG for replication

3.     We may add to initialize connection for replication

  
Thanks, 
-Ruijing 
  
From: Ronen Kat [mailto:ronen...@il.ibm.com]

Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

  
As some of you are aware the spec for replication is not up to date, 
The current developer documentation, http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html,
cover replication but some folks indicated that it need additional details.


In order to get the spec and documentation up to date I created an Etherpad
to be a base for the update.

The Etherpad page is on https://etherpad.openstack.org/p/cinder-replication-redoc


I would appreciate if interested parties would take a look at the Etherpad,
add comments, details, questions and feedback.


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




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

[openstack-dev] [cinder]Driver broken

[Eduard Matei]

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which
introduced another parameter to be passed to the driver, but our driver
didn't get updated so detach_volume fails for us.

How can we get this fixed asap?

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

[openstack-dev] [Cinder] PTL Candidacy

[Mike Perez]

Hello all,

I'm announcing my candidacy for Cinder PTL for the Liberty release.

I have contributed to block storage in OpenStack since Bexar back when things
were within nova-volume, before Cinder, and the honor of serving as PTL for
Cinder in the Kilo cycle.

I've spoke in the past about focused participation, something I still feel is
needed in the projects that are the basic foundation of OpenStack. Compute,
storage and networking need to be solid. My work as core in Cinder and
continuing as PTL has involved a lot of evangelizing and making new
contributors feel comfortable with becoming part of the team. As a project
grows, communication needs to be excellent, coordination is key to making sure
reviews don't stick around too long for contributors to feel discouraged.
I think the Cinder team has done an excellent job in managing this as we grow,
based on the feedback received. I really do think participation in Cinder
is getting better, and it's wonderful to be part of that.

If we take the Kilo-3 milestone for example, we landed 44 blueprints in
a single milestone [1]. That's huge progress. I would like to believe this
happens because of focus, and that happens because of better tracking of what
is a priority and clear communication. Lastly participation, not just core
folks, but any contributor that feels welcomed by the team and not to be burnt
out on never ending patch revisions.

Most of 2014 in Cinder was a lot of discussions on third party CI's. Third
party CI's are a great way for vendors to verify if a proposed upstream patch
would break their integration. In addition, it identifies if a vendor really
does work with the current state of the OpenStack project. There have been
plenty of cases that vendors discovered that their integration in OpenStack
really didn't work until they ran these tests. Last year, there was a real lack
of coordination and communication with vendors on getting them on board with
reporting third party CI results. In 2015 I took on the responsibility of being
the point of contact for the 70+ drivers in Cinder, emailing the mailing list,
countless reminders on IRC, contacting maintainers directly, and actually
making phone calls to companies if maintainers were not responsive by email.

I'm happy to report that majority of vendors have responded back and are active
in the Cinder community to ensure their integration is solid. Compare that to
last year when we just had one or two vendors reporting and majority of vendors
not having a clue! It's very exciting to help build a better experience for
their users using OpenStack. The communities pouring support to me on this
issue was hugely appreciated, and is what keeps me coming back to help.

We added 14 new drivers to Cinder in the Kilo release. Coordination was
beautiful thanks to clear communication and coordination with the hard working
reviewers in the Cinder team.

My priorities for Cinder in the Kilo release was to make progress on rolling
upgrades. I have spent a greater deal of my time testing the work to allow
Cinder services to not be dependent on database schemas. This is a big change,
and doesn't completely solve rolling upgrades in Cinder, but is a building
block needed to begin solving the other rolling upgrade problems. I'm really
happy with the work done by the team in the Kilo release and excited with how
comfortable I feel in terms of stability of the work thanks to the amount of
testing we've done.

This work however not only benefits Cinder, but is a general solution into
Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are
a huge problem that needs to be solved across OpenStack, and I'm proud of the
Cinder team for helping do their part to help drive adoption. Long term I see
this work contributing to an ideal single upgrade solution, so that operators
aren't having to learn how to upgrade 12 different services they may deploy.

My plans for Liberty is to work with the team on creating a better use of
milestones for appropriate changes. While we started some initial requirements
like making new drivers focus on the first milestone only, I think stability
time needs to be stretched a bit longer, and I think others will agree Kilo
didn't have a lot of this as planned for Kilo-3.

Cinder  will continue on efforts for rolling upgrades by now focusing on
compatibility across Cinder services with RPC. This is a very important piece
for making rolling upgrades complete. We will continue to work through projects
like Oslo to make sure these solutions general enough to benefit other
OpenStack projects, so as a whole, we will improve together.

Cinder volumes that end up in a stuck state. This has been a problem for ages,
and I have heard from countless people at the Ops Midcycle Meetup that
I attended. I'm happy to say, as reported from my take on the Ops Midcycle
meetup [2], that this was something the Cinder team discussed at the Cinder
Midcycle Meetup this year and we will be working on

[openstack-dev] [cinder]Multiple backends

[iKhan]

Hi All,

I'm just curious on how the manager.py is choosing backend while creating
volume, I know volume type is set but where is this being processed?

I am sorry if this is a basic question, but didn't got any help from
#openstack-dev IRC channel so was left without option to post here.

-- 
Thanks,
IK
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Cinder + taskflow

[Kekane, Abhishek]

Hi John,

With reference to 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026189.html

Point #3 "unit testing / mock infrastructure is broken" is fixed 
(https://review.openstack.org/#/c/73984)

Currently we are planning to work on persisting create_volume api using 
taskflow.
I just want to confirm if any other team/developer is not working on the same 
task so that efforts will not be duplicated.

Also please let us know if you have any suggestions on the same.

Thanks & Regards,

Abhishek Kekane 

-Original Message-
From: Joshua Harlow [mailto:harlo...@yahoo-inc.com] 
Sent: Tuesday, February 04, 2014 6:11 AM
To: OpenStack Development Mailing List (not for usage questions); John Griffith
Cc: Yassine lamgarchal
Subject: Re: [openstack-dev] Cinder + taskflow

Thanks john for the input.

Hopefully we can help focus some of the refactoring on solving the 
state-management problem very soon.

For the mocking case, is there any active work being done here?

As for the state-management and persistence, I think that the goal of both of 
these will be reached and it is a good idea to focus around these problems and 
I am all in to figuring out those solutions, although my guess is that both of 
these will be long-term no matter what. Refactoring cinder from what it is to 
what it could/can be will take time (and should take time, to be careful and 
meticulous) and hopefully we can ensure that focus is retained. Since in the 
end it benefits everyone :)

Lets reform around that state-management issue (which involved a state-machine 
concept?). To me the current work/refactoring helps establish tasks objects 
that can be plugged into this machine (which is part of the problem, without 
task objects its hard to create a state-machine concept around code that is 
dispersed). To me that¹s where the current refactoring work helps (in 
identifying those tasks and adjusting code to be closer to smaller units that 
do a single task), later when a state-machine concept (or something similar) 
comes along with will be using these tasks (or variations of) to automate 
transitions based on given events (the flow concept that exists in taskflow is 
similar to this already).

The questions I had (or can currently think of) with the state-machine idea 
(versus just defined flows of tasks) are:

1. What are the events that trigger a state-machine to transition?
  - Typically some type of event causes a machine to transition to a new state 
(after performing some kind of action). Who initiates that transition.
2. What are the events that will cause this triggering? They are likely related 
directly to API requests (but may not be).
3. If a state-machine ends up being created, how does it interact with other 
state-machines that are also running at the same time (does it?)
  - This is a bigger question, and involves how one state-machine could be 
modifying a resource, while another one could be too (this is where u want only 
one state-machine to be modifying a resource at a time). This would solve some 
of the races that are currently existent (while introducing the complexity of 
distributed locking).
  - It is of my opnion that the same problem in #3 happens when using task and 
flows that also affect simulatenous resources; so its not a unique problem that 
is directly connected to flows. Part of this I am hoping the tooz project[1] 
can help with, since last time I checked they want to help make a nice API 
around distributed locking backends (among other similar APIs).

[1] https://github.com/stackforge/tooz#tooz

-Original Message-
From: John Griffith 
Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Date: Monday, February 3, 2014 at 1:16 PM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] Cinder + taskflow

>On Mon, Feb 3, 2014 at 1:53 PM, Joshua Harlow 
>wrote:
>> Hi all,
>>
>> After talking with john g. about taskflow in cinder and seeing more 
>> and more reviews showing up I wanted to start a thread to gather all 
>> our lessons learned and how we can improve a little before continuing 
>> to add too many more refactoring and more reviews (making sure 
>> everyone is understands the larger goal and larger picture of 
>> switching pieces of cinder - piece by piece - to taskflow).
>>
>> Just to catch everyone up.
>>
>> Taskflow started integrating with cinder in havana and there has been 
>>some  continued work around these changes:
>>
>> - https://review.openstack.org/#/c/58724/
>> - https://review.openstack.org/#/c/66283/
>> - https://review.openstack.org/#/c/62671/
>>
>> There has also been a few other pieces of work going in (forgive me 
>> if I missed any...):
>>
>> - https://review.openstack.org/#/c/64469/
>> - https://review.o

[openstack-dev] [Cinder] PTL Candidacy

[Mike Perez]

Hello all,

My name is Mike Perez, and I would like to be your next PTL for the OpenStack
block storage project Cinder.

I've been involved with the OpenStack community since October 2010. I'm
a senior developer for Datera which contributes to Linux Bcache and the
Linux-IO SCSI Target (LIO) in the kernel. Before that I was for seven years
a senior developer for DreamHost, working on their core products and storage in
their OpenStack public cloud.

Since November 2012 I've been a core developer for Cinder. Besides code
reviews, my main contributions include creating the v2 API, writing the v2 API
reference and spec docs and rewriting the v1 api docs. These are contributions
that I feel were were well thought out and complete. This is exactly how I 
would like to see the future of Cinder's additional contributions and would
like to lead the team that direction.

Instead of listing out the technical things that need to be improved in Cinder,
I would like to just talk about the things as PTL I would improve, which as
a side effect will allow the team to focus better on those technical issues.

Cinder is a small but a very effective team. Just like other projects, we need
more contributors to handle the requirements we get daily. First impressions
with contributors who are very excited to make their name in OpenStack can be
better helped by simple outreach in how they can be more effective with the
team. Guiding those contributors on what are the goals, and spending a little
time with them on how their interests can help those goals can go a long
way. Currently I feel like potential long term contributors are discouraged in
the time that they spend on evaluating what they could improve and to later
find out that their proposed improvements don't fit the project plans.

Focus itself can help contributors be effective in what's important. With the
support of the community, I would like to raise better guidelines on when
certain contributions are appropriate. With these community agreed guidelines,
it should be clearer on what is appropriate for review and what can be pushed
to the next release. With a better focus we can allow more time for features to
be more complete as mentioned earlier. Being complete means having confidence
something works. This can be ensured by trying changes before merge when
possible and not relying on tests alone, having performance results, and
actually having documentation so people know how to use new features. Release
notes are not enough to figure out new Cinder features.

I want to help the team realize more they can do in Cinder. I don't want to be
a single person people rely on in the project, but rather have this team help
me carry this project forward.

Thank you,
Mike Perez

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

[openstack-dev] [cinder] weekly meeting

[John Griffith]

Hi All,

Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
some interest in either changing the weekly Cinder meeting time, or
proposing a second meeting to accomodate folks in other time-zones.

A large number of folks are already in time-zones that are not
"friendly" to our current meeting time.  I'm wondering if there is
enough of an interest to move the meeting time from 16:00 UTC on
Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
willing to look at either moving the meeting for a trial period or
holding a second meeting to make sure folks in other TZ's had a chance
to be heard.

Let me know your thoughts, if there are folks out there that feel
unable to attend due to TZ conflicts and we can see what we might be
able to do.

Thanks,
John

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

Re: [openstack-dev] Cinder + taskflow

[John Griffith]

On Mon, Feb 3, 2014 at 1:53 PM, Joshua Harlow  wrote:
> Hi all,
>
> After talking with john g. about taskflow in cinder and seeing more and
> more reviews showing up I wanted to start a thread to gather all our
> lessons learned and how we can improve a little before continuing to add
> too many more refactoring and more reviews (making sure everyone is
> understands the larger goal and larger picture of switching pieces of
> cinder - piece by piece - to taskflow).
>
> Just to catch everyone up.
>
> Taskflow started integrating with cinder in havana and there has been some
> continued work around these changes:
>
> - https://review.openstack.org/#/c/58724/
> - https://review.openstack.org/#/c/66283/
> - https://review.openstack.org/#/c/62671/
>
> There has also been a few other pieces of work going in (forgive me if I
> missed any...):
>
> - https://review.openstack.org/#/c/64469/
> - https://review.openstack.org/#/c/69329/
> - https://review.openstack.org/#/c/64026/
>
> I think now would be a good time (and seems like a good idea) to create
> the discussion to learn how people are using taskflow, common patterns
> people like, don't like, common refactoring idioms that are occurring and
> most importantly to make sure that we refactor with a purpose and not just
> refactor for refactoring sake (which can be harmful if not done
> correctly). So to get a kind of forward and unified momentum behind
> further adjustments I'd just like to make sure we are all aligned and
> understood on the benefits and yes even the drawbacks that these
> refactorings bring.
>
> So here is my little list of benefits:
>
> - Objects that do just one thing (a common pattern I am seeing is
> determining what the one thing is, without making it to granular that its
> hard to read).
> - Combining these objects together in a well-defined way (once again it
> has to be carefully done to not create to much granularness).
> - Ability to test these tasks and flows via mocking (something that is
> harder when its not split up like this).
> - Features that aren't currently used such as state-persistence (but will
> help cinder become more crash-resistant in the future).
>   - This one will itself need to be understood before doing [I started
> etherpad @ https://etherpad.openstack.org/p/cinder-taskflow-persistence
> for this].
>
> List of drawbacks (or potential drawbacks):
>
> - Having a understanding of what taskflow is doing adds on a new layer of
> things to know (hopefully docs help in this area, that was there goal).
> - Selecting to granular of a task or flow; makes it harder to
> follow/understand the task/flow logic.
> - Focuses on the long-term (not necessarily short-term) state-management
> concerns (can't refactor rome in a day).
> - Taskflow is being developed at the same time cinder is.
>
> I'd be very interested in hearing about others experiences and to make
> sure that we discuss the changes (in a well documented and agreed on
> approach) before jumping to much into the 'deep end' with a large amount
> of refactoring (aka, refactoring with a purpose). Let's make this thread
> as useful as we can and try to see how we can unify all these refactorings
> behind a common (and documented & agreed-on) purpose.
>
> A thought, for the reviews above, I think it would be very useful to
> etherpad/writeup more in the blueprint what the 'refactoring with a
> purpose' is so that its more known to future readers (and for active
> reviewers), hopefully this email can start to help clarify that purpose so
> that things proceed as smoothly as possible.
>
> -Josh
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks for putting this together Josh, I just wanted to add a couple
of things from my own perspective.

The end-goals of taskflow (specifically persistence and better state
managment) are the motivating factors for going this route.  We've
made a first step with create_volume however we haven't advanced it
enough to realize the benefits that we set out to gain by this in the
first place.  I still think it's the right direction and IMO we should
keep on the path, however there are a number of things that I've
noticed that make me lean towards refraining from moving other API
calls to taskflow right now.

1. Currently taskflow is pretty much a functional equivalent
replacement of what was in the volume manager.  We're not really
gaining that much from it (yet).

2. taskflow adds quite a bit of code and indirection that currently
IMHO adds a bit of complexity and difficulty in trouble-shooting (I
think we're fixing this up and it will continue to get better, I also
think this is normal for introduction of new implementations, no
criticism intended).

3. Our unit testing / mock infrastructure is broken right now for
items that use taskflow.  Particularly cinder.test.test_volume can not
be run indepen

Re: [openstack-dev] Cinder + taskflow

[Joshua Harlow]

Thanks john for the input.

Hopefully we can help focus some of the refactoring on solving the
state-management problem very soon.

For the mocking case, is there any active work being done here?

As for the state-management and persistence, I think that the goal of both
of these will be reached and it is a good idea to focus around these
problems and I am all in to figuring out those solutions, although my
guess is that both of these will be long-term no matter what. Refactoring
cinder from what it is to what it could/can be will take time (and should
take time, to be careful and meticulous) and hopefully we can ensure that
focus is retained. Since in the end it benefits everyone :)

Lets reform around that state-management issue (which involved a
state-machine concept?). To me the current work/refactoring helps
establish tasks objects that can be plugged into this machine (which is
part of the problem, without task objects its hard to create a
state-machine concept around code that is dispersed). To me that¹s where
the current refactoring work helps (in identifying those tasks and
adjusting code to be closer to smaller units that do a single task), later
when a state-machine concept (or something similar) comes along with will
be using these tasks (or variations of) to automate transitions based on
given events (the flow concept that exists in taskflow is similar to this
already).

The questions I had (or can currently think of) with the state-machine
idea (versus just defined flows of tasks) are:

1. What are the events that trigger a state-machine to transition?
  - Typically some type of event causes a machine to transition to a new
state (after performing some kind of action). Who initiates that
transition.
2. What are the events that will cause this triggering? They are likely
related directly to API requests (but may not be).
3. If a state-machine ends up being created, how does it interact with
other state-machines that are also running at the same time (does it?)
  - This is a bigger question, and involves how one state-machine could be
modifying a resource, while another one could be too (this is where u want
only one state-machine to be modifying a resource at a time). This would
solve some of the races that are currently existent (while introducing the
complexity of distributed locking).
  - It is of my opnion that the same problem in #3 happens when using task
and flows that also affect simulatenous resources; so its not a unique
problem that is directly connected to flows. Part of this I am hoping the
tooz project[1] can help with, since last time I checked they want to help
make a nice API around distributed locking backends (among other similar
APIs).

[1] https://github.com/stackforge/tooz#tooz

-Original Message-
From: John Griffith 
Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Date: Monday, February 3, 2014 at 1:16 PM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] Cinder + taskflow

>On Mon, Feb 3, 2014 at 1:53 PM, Joshua Harlow 
>wrote:
>> Hi all,
>>
>> After talking with john g. about taskflow in cinder and seeing more and
>> more reviews showing up I wanted to start a thread to gather all our
>> lessons learned and how we can improve a little before continuing to add
>> too many more refactoring and more reviews (making sure everyone is
>> understands the larger goal and larger picture of switching pieces of
>> cinder - piece by piece - to taskflow).
>>
>> Just to catch everyone up.
>>
>> Taskflow started integrating with cinder in havana and there has been
>>some
>> continued work around these changes:
>>
>> - https://review.openstack.org/#/c/58724/
>> - https://review.openstack.org/#/c/66283/
>> - https://review.openstack.org/#/c/62671/
>>
>> There has also been a few other pieces of work going in (forgive me if I
>> missed any...):
>>
>> - https://review.openstack.org/#/c/64469/
>> - https://review.openstack.org/#/c/69329/
>> - https://review.openstack.org/#/c/64026/
>>
>> I think now would be a good time (and seems like a good idea) to create
>> the discussion to learn how people are using taskflow, common patterns
>> people like, don't like, common refactoring idioms that are occurring
>>and
>> most importantly to make sure that we refactor with a purpose and not
>>just
>> refactor for refactoring sake (which can be harmful if not done
>> correctly). So to get a kind of forward and unified momentum behind
>> further adjustments I'd just like to make sure we are all aligned and
>> understood on the benefits and yes even the drawbacks that these
>> refactorings bring.
>>
>> So here is my little list of benefits:
>>
>&g

Re: [openstack-dev] [Cinder][Manila]

[Swartzlander, Ben]

> -Original Message-
> From: Alun Champion [mailto:p...@achampion.net] 
> Sent: Saturday, April 26, 2014 7:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Cinder][Manila]
>
> I'm sure this has been discussed I just couldn't find any reference to it, 
> perhaps someone can point me to the discussion/rationale.
> Is there any reason why there needs to be another service to present a 
> control-plane to storage? Obviously object storage is
> different as that is presenting a data-plane API but from a control-plane I'm 
> confused why there needs to be another service,
> surely control-planes are pretty similar and the underlying networking issues 
> for iSCSI would be similar for NFS/CIFS.
> Trove is looking to be a general purpose data container
> (control-plane) service for traditional RDBMS, NoSQL, KeyValue, etc., why is 
> the Cinder API not suitable for providing a general
> purpose storage container (control-plane) service?
>
> Creating separate services will complicate other services, e.g. Trove.
>
> Thoughts?

There are good arguments on both sides of this question. There is substantial 
overlap between Cinder and Manila in their API constructs and backends (they 
both deal with storage, after all). In the long run it's entirely possible that 
the 2 projects could be merged.

However there are also some very important differences. In particular Cinder 
knows almost nothing about networking, but Manila needs to know a great deal 
about individual tenant networks in order to deliver NAS storage to tenants. 
Cinder can rely on hypervisors to do some of the hard work of translating block 
protocols and managing attaching/detaching whereas Manila routes around the 
hypervisor entirely and connects guest VMs with storage directly. The most 
important reason Manila ended up as a separate project from Cinder was because 
the Cinder team didn't want the distraction of dealing with some of the very 
hard technical problems that needed solving for Manila to be successful.

After working on Manila for the past year and struggling with a lot of hard 
technical decisions I think it was the right decision to split the projects. If 
Manila had remained a subproject of Cinder then it either wouldn't have 
received near the attention it needed or it would have sucked attention away 
from a lot of important issues that the Cinder team is dealing with.

If there's a future where Manila and Cinder merge back together then I'm pretty 
sure it's quite far away. The best thing we can do is strive to make both 
projects successful and keep asking these hard questions.

-Ben Swartzlander (Manila PTL)


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

Re: [openstack-dev] [cinder] [cinderdriver]

[Martin, Kurt Frederick (ESSN Storage MSDU)]

Hello Mardan,
The following Cinder wiki pages contains the information or links to the 
information that you will need to submit a new driver: 
https://wiki.openstack.org/wiki/Cinder and 
https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
~Kurt

From: Mardan Raghuwanshi [mailto:mardan.si...@cloudbyte.com]
Sent: Saturday, May 10, 2014 6:15 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [cinder] [cinderdriver]

Hello All,
I developed cinder drivers for CloudByte's ElastiStor. Now we want to make our 
driver as a part of core openstack release, but I am not aware of openstack 
commit process.
Please help me...


Thanks,
Mardan


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

[openstack-dev] [Cinder] PTL Candidacy

[Mike Perez]

Hello all,

My name is Mike Perez, and I would like to be your next PTL for the OpenStack
block storage project Cinder.

I've been involved with the OpenStack community since October 2010. I'm
a senior developer for Datera, which contributes to Linux Bcache and the
Linux-IO SCSI Target (LIO) in the Linux kernel (which some Cinder setups use
underneath for target management). Before that I was for seven years a senior
developer for DreamHost, working on their core products and storage in their
OpenStack public cloud.

Since November 2012 I've been a core developer for Cinder. Besides code
reviews, my main contributions include creating the v2 API, writing the v2 API
reference and spec docs and rewriting the v1 api docs. These are contributions
that I feel were well thought out and complete. This is exactly how I
would like to see the future of Cinder's additional contributions and would
like to lead the team in that direction.

Over the years I've advocated for OpenStack [1][2][3][4] and its community to
bring in more contributors by teaching the basics of Cinder's design, which
then can be applied to a project a potential contributor is interested in.
I also contribute to programs such as the Women Who Code event [5][6] to help
get future OpenStack interns in the Gnome Outreach Program excited to help the
project. I feel, as a leader, helping to build a healthy diverse community is
key.

I would like to continue to help the Cinder team with focusing on what the
bigger picture is. Not letting us get lost in long discussion, but come to
a consensus sooner and start making better progress now. Some of this includes
better organizing of the blueprints and better triaging of bugs so contributors
can use tools more effectively [7]. I would also like to guide folks with their
ideas early on as something that fits with the project or not.

For the Kilo release, a lot of features have a dependency on a state machine.
I agree with the rest of Cinder contributors, this needs to happen now so
that we can can progress forward. I have a summit session with an approach as
discussed in the previous Cinder Mid-cycle meet up [8] to drive this important
change forward. Lastly, rolling upgrades is being picked back up, and I will be
showing interest in reviews and discussion with helping the contributors focus
to bring this wonderful feature forward. These are the only changes I'm
mentioning as I'm sure we'll need bandwidth for other necessary features that
contributors will be bringing in.

I'm looking forward to continuing to grow, and the opportunity to contribute to
this project in new ways.

Thanks,
Mike Perez

[1] - http://www.meetup.com/OpenStack-Northwest/events/151114422
[2] - http://www.meetup.com/meetup-group-NjZdcegA/events/150630962
[3] - http://www.meetup.com/OpenStack-Seattle/events/159943872
[4] - http://www.meetup.com/openstack/events/150932582/
[5] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/
[6] - http://www.meetup.com/Women-Who-Code-SF/events/195850922/
[7] - http://status.openstack.org/reviews/
[8] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014

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

[openstack-dev] [cinder] PTL Candidacy

[Duncan Thomas]

This is an announcement of my standing for PTL of the Cinder project.

I've been an active member of the Cinder core team from day one, and
I've had the pleasure of working closely with John Griffith, the
incumbent PTL, and a large and varied collection of contributors for
that period.

My job is running block storage in HP's public cloud, as well as
working on our private cloud offering. This has give me a strong
emphasis on the day to day operational aspects of running Cinder at
scale, backward compatibility and the challenges of continuous
deployment of head-of-tree code in production.

I think Cinder is a project reaching technical maturity; it has a
strong team behind it, both core and non-core. We work well together,
and I see the main role of the PTL not as making decisions but in
enabling this community to progress as smoothly as possible. I've had
a great deal of success in driving forward the 3rd party CI
requirements, working with the infra team to work out process and
where necessary giving engineers the tools and leverage they need to
overcome roadblocks within their own companies. I feel that some
gentle shepherding in terms of review focus can help us increase our
velocity without disrupting the very successful way of working we
currently have.

The hugely successful mid-cycle meetup set the main goal of the Kilo
cycle as stability and paying down technical debt, and there are a
number of pieces of work started by myself and others that should
produce significant dividends in that area - state machine, cinder
agent, decoupling of drivers and connector types.

I have always encouraged anybody to reach out to me with questions and
concerns, and continue to do so. I look forward to continuing the
great work we've been doing.


Regards

-- 
Duncan Thomas
Cinder Core, and HP Cloud

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

[openstack-dev] Cinder pools implementation

[Singh, Navneet]

Hi,
  As per our discussions in the last meeting I have made an etherpad which 
details different pool implementations and at the end comparison between the 
approaches. Please go through it and be ready with any questions or opinions 
for tomorrow's meeting. Here is the link for etherpad:

https://etherpad.openstack.org/p/cinder-pool-impl-comparison

Best Regards
Navneet Singh
NetApp

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

[openstack-dev] [Cinder] PTL candidacy

[Duncan Thomas]

I would like to run for election as Cinder PTL for the upcoming
Icehouse release.

I've been involved with Openstack for more than 2 years, I've been an
active and vocal member of the Cinder core team since cinder was
formed and have contributed to variously to debates, reviews, designs
and code. Before that I've been involved with high-performance compute
clusters and networking both as a developer and from an ops
prospective.

I think Cinder is a strong and healthy project, and I'd like to
continue to build on the great work John Griffith has been doing as
PTL. We have at least 16 different back-ends supported, and have been
very successful in allowing many levels of contribution and
involvement.

If elected, my main drives for the Icehouse release will be:

- Cross project coordination - several features have suffered somewhat
from the fact that coordination is needed between cinder and other
projects, particularly nova and horizon. I'd like to work with the PTL
and core team of those projects to see what we can do to better align
expectations and synchronisation between projects, so that features
like volume encryption, read-only volumes, ACLs etc. can be landed
more smoothly

- Deployment issues - several large companies now deploy code from
trunk between releases, and perform regular rolling releases. I'd like
to focus on what makes that difficult and what we can do in terms of
reviews, testing and design to make that a smoother progress. This
includes tying into OSLO and other projects that are working on this.
Task-flow is a good example of a project that made significant useful
progress by working with cinder as a first user before moving out to
otehr projects.

- Grow the cinder community, and encourage new contributes in form of
testing and validation as well as new features. Generally keep the
fantastic inclusive nature of the cinder project going, and encourage
the healthy debates that have allowed us to come up with great
solutions.

- Blueprint management - Many blueprints are currently very thin
indeed, often no more than a sentence or two. I'd like to see more
push-back blueprints that do not provide a reasonable amount of detail
before the code comes along, in order to allow discussion and debate
earlier in the development cycle.

There are many other sub-projects within cinder, such as driver
validation, that I support and intend to do my best to see succeed.



-- 
Duncan Thomas

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

[openstack-dev] [Cinder] PTL candidacy

[Duncan Thomas]

I would like to run for election as Cinder PTL for the upcoming
Icehouse release.

I've been involved with Openstack for more than 2 years, I've been an
active and vocal member of the Cinder core team since cinder was
formed and have contributed to variously to debates, reviews, designs
and code. Before that I've been involved with high-performance compute
clusters and networking both as a developer and from an ops
prospective.

I think Cinder is a strong and healthy project, and I'd like to
continue to build on the great work John Griffith has been doing as
PTL. We have at least 16 different back-ends supported, and have been
very successful in allowing many levels of contribution and
involvement.

If elected, my main drives for the Icehouse release will be:

- Cross project coordination - several features have suffered somewhat
from the fact that coordination is needed between cinder and other
projects, particularly nova and horizon. I'd like to work with the PTL
and core team of those projects to see what we can do to better align
expectations and synchronisation between projects, so that features
like volume encryption, read-only volumes, ACLs etc. can be landed
more smoothly

- Deployment issues - several large companies now deploy code from
trunk between releases, and perform regular rolling releases. I'd like
to focus on what makes that difficult and what we can do in terms of
reviews, testing and design to make that a smoother progress. This
includes tying into OSLO and other projects that are working on this.
Task-flow is a good example of a project that made significant useful
progress by working with cinder as a first user before moving out to
otehr projects.

- Grow the cinder community, and encourage new contributes in form of
testing and validation as well as new features. Generally keep the
fantastic inclusive nature of the cinder project going, and encourage
the healthy debates that have allowed us to come up with great
solutions.

- Blueprint management - Many blueprints are currently very thin
indeed, often no more than a sentence or two. I'd like to see more
push-back blueprints that do not provide a reasonable amount of detail
before the code comes along, in order to allow discussion and debate
earlier in the development cycle.

There are many other sub-projects within cinder, such as driver
validation, that I support and intend to do my best to see succeed.



--
Duncan Thomas


-- 
Duncan Thomas

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

[openstack-dev] [Cinder] Logo survey

[Sean McGinnis]

Hey all,

During the midcycle we discussed a few options for a new logo mascot. I've
taken a few of the top choices and created a survey to get more input:

https://www.surveymonkey.com/r/G7JRNQB

Please vote as soon as possible. These are first come, first served, so we
should decide soon and get our selections submitted. I will probably wait
until Monday to collect responses unless we get a lot of clear responses
right away.

Thanks!
Sean


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

[openstack-dev] [Cinder] PTG Planning

[Sean McGinnis]

Hey everyone,

I've started a planning etherpad [1] for topics for the PTG. Please add any
topic ideas there, and add your name and nic if you plan on attending to
help us get an idea of who will be there.

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

Once we get some topics, we can try to organize a rough schedule to help
with planning. It won't be possible to have an exact schedule, but hopefully
we can get a rough idea to help for those trying to attend discussions with
other project teams.

Thanks,
Sean


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

[openstack-dev] [Cinder] BlockDeviceDriver deprecated?

[Pieter Baele]

Red Hat tells me the Cinder BlockDeviceDriver is going to be deprecated
upstream. It isn't supported in RHOSP in any case.
Is this true?

Bakground information:
BDD is one of the things I would have used for important HDFS DataNodes in
a private cloud.
Red Hat proposes Ceph, but running a replicated HDFS on top of Ceph RBD
which also replicated.?

So my only option left is bare-metal Hadoop DataNodes (?)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] PTG Recap

[Sean McGinnis]

I leiu of a lengthy email that very few will read, this is just a
pointer.

Jay Bryant (jungleboyj) did a great job during the PTG of capturing
notes and action items from our discussions. One of the items discussed
was around improving capturing these details and making them easier to
find months and years down the road when we've all forgotten. Basically
a way to avoid the usual statement of "Didn't we discuss this in $CITY".

As part of that, in addition to keeping our etherpads with all the
notes, we have started a section on the Cinder wiki to make this info
easy to find, with links to specific PTG and Forum notes from each
event [1].

Thanks Jay for setting this up.

The recap for the first event can be found here: [2]

Sean (smcginnis)

[1] https://wiki.openstack.org/wiki/Cinder#PTG_and_Summit_Meeting_Summaries
[2] https://wiki.openstack.org/wiki/CinderPikePTGSummary

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

[openstack-dev] [Cinder] PTL candidacy

[Sean McGinnis]

Hello everyone, 

I would like to announce my candidacy to continue as Cinder PTL for the Ocata   
release.

The Cinder project has made great strides over the last several releases
adding functionality and improving stability. I think we have a very active 
team and love being part of such a strong community.

The Ocata cycle will be a much shorter one than in the past. One thing I would  
like to encourage for this release, as much as makes sense, is to focus on  
being mostly a bug fix and stabilization cycle. One side effect of all of the   
great new work going in recently is there has been a lot of new code introduced 
and changes made. There have been fundamental changes in how some things
operate with the the change from rootwrap to privsep. I would like to take  
advantage of this shorter concentrated cycle to delay some things in order to   
make sure we have a solid foundation to build on.   

Not to say there are any major issues with the project, or that there isn't 
new work that we do want to get in to Cinder. We have an incredible team that   
has been able to introduce some pretty significant code with little to no   
impact on the rest of the system. Folks have done a great job manually testing  
as well as adding unit and other automated testing to ensure high quality. But  
even with code that has been in there untouched for years we still find certain 
conditions that bring out issues. It would be great to find some of these now   
before we build too much more on top.   

Between the Summit and holidays for most over this cycle, Ocata will really be  
a short one. But I look forward to seeing how much this team can do, even in
this quick cycle. This could be a lot of fun!   

Thank you for your consideration!   

Sean

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

[openstack-dev] cinder 13.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/rocky

Release notes for cinder can be found at:

http://docs.openstack.org/releasenotes/cinder/




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

[openstack-dev] cinder 13.0.0.0rc2 (rocky)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/rocky

Release notes for cinder can be found at:

https://docs.openstack.org/releasenotes/cinder/




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

[openstack-dev] cinder 13.0.0.0rc3 (rocky)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/rocky

Release notes for cinder can be found at:

https://docs.openstack.org/releasenotes/cinder/




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

[openstack-dev] [Cinder] Proposed logo

[Sean McGinnis]

Hey team,

Attached is the proposed new logo for the Cinder project. I think some have 
already seen this, so making sure everyone gets a chance to see it before it's 
finalized.

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

Re: [openstack-dev] [cinder] [ceilometer]

[Julien Danjou]

On Thu, Dec 08 2016, Jiong Liu wrote:

Hi Jeremy,

If I'm not mistaken, there's a new pollster in Ocata that uses the
Cinder API to get the metrics now, so I think the volume usage audit is
getting useless.

> Hello Cinder/Ceilometer community,
>
>  
>
> Is there any guideline on using `cinder-volume-usage-audit` command?
>
>  
>
> Search through cinder/ceilometer logs, I find some messages are sent to
> ceilometer-collector.
>
> How do I check the output of this command in ceilometer? Do you have any
> suggestion?
>
>  
>
> Looking forward to your comments. Thanks.
>
>  
>
> BR,
>
> Jeremy Liu
>
>
>

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


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

Re: [openstack-dev] [cinder] [ceilometer]

[Li, Xiaoyan]

The new notification reports kinds of capacity information, includes total, 
free, allocated, provisioned, visual_free. 
Detailed info please see the following specs: 

https://review.openstack.org/#/c/192542/2/specs/liberty/cinder-capacity-notifications.rst
https://review.openstack.org/#/c/249932/1/specs/mitaka/capacity-headroom.rst
https://review.openstack.org/#/c/206923/

Lisa

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Thursday, December 8, 2016 5:42 PM
To: Jiong Liu 
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] [ceilometer]

On Thu, Dec 08 2016, Jiong Liu wrote:

Hi Jeremy,

If I'm not mistaken, there's a new pollster in Ocata that uses the Cinder API 
to get the metrics now, so I think the volume usage audit is getting useless.

> Hello Cinder/Ceilometer community,
>
>  
>
> Is there any guideline on using `cinder-volume-usage-audit` command?
>
>  
>
> Search through cinder/ceilometer logs, I find some messages are sent 
> to ceilometer-collector.
>
> How do I check the output of this command in ceilometer? Do you have 
> any suggestion?
>
>  
>
> Looking forward to your comments. Thanks.
>
>  
>
> BR,
>
> Jeremy Liu
>
>
>

--
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.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-dev] [cinder] pending review

[Sam Morrison]

Hi Cinder devs,

I’ve had a review [1] waiting for some eyes for over a month now. What’s the 
process here, usually I get a response to a review in other projects in a day 
or two. 
Is there someone I need to alert or add to the review specifically for cinder 
patches?

Thanks,
Sam

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



__
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] [ceilometer]

[gordon chung]

On 12/12/16 10:13 PM, Li, Xiaoyan wrote:
> The new notification reports kinds of capacity information, includes total, 
> free, allocated, provisioned, visual_free.

that's cool. just for reference, you can easily add support to generate 
metrics from this by editing the meters.yaml file[1]. alternatively, 
just paste the notification format here and someone can build it for you.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml

-- 
gord

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

[openstack-dev] cinder authentication with authtoken

[Kanthi P]

Hi,

I need a way to access cinder apis using auth-token. I used below API to
get the cinder client and tried getting the availability zones.


cinder_client = cc.Client(1, auth_token=self.ctxt.auth_token,
 project_id=self.ctxt.tenant,
  auth_url=self.ctxt.auth_url)
cinder_client.availability_zones.list()

But authentication fails with the exception:
"cinderclient.exceptions.BadRequest: Expecting to find username or userId
in passwordCredentials - the server could not comply with the request since
it is either malformed or otherwise incorrect. The client is assumed to be
in error. (HTTP 400)"

It works fine when I use username and api_key instead of auth_token

cinder_client = cc.Client(1, username="admin", api_key="X",
  project_id="admin",
  auth_url="http://X.X.X.X:5000/v2.0";)
cinder_client.availability_zones.list()

Please help me with a means of using cinder apis with auth_token.

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

[openstack-dev] [cinder] Cinder Mitaka Deadlines

[Sean McGinnis]

Cinder Release Schedule

After some discussion at the Mitaka Design Summit, the Cinder team will be
altering our release schedule for this release to simplify deadlines and
closer align with the established OpenStack release schedule.

Overall Deadlines for Mitaka [1]

* Mitaka-1 (Dec 1-3)
* Mitaka-2 (Jan 19-21)
* Mitaka-3 (Mar 1-3)
  * Final release for client libraries
  * FeatureFreeze
  * Soft StringFreeze
* Mitaka Release (April 7)


Based on these dates, the following are the deadlines for Cinder changes to be
merged:

* New backend drivers (Jan 19, 7:59 UTC)
* Spec/blueprint approval deadline (Jan 19, 7:59 UTC)
* New features and driver functionality (Mar 1, 7:50 UTC)
  * Note: changes that require client updates will need to be
  made available in enough time for both client and
  service changes to merge.

After the stated deadlines, it will be at the discretion of the Cinder core
team whether to allow any exceptions based on scope of work and perceived risk.

To increase the odds that your code will be accepted in Mitaka - do not wait
until close to the deadlines to submit your work. Code needs to be reviewed
and CI testing performed before it merges. This may take some time. Do not
expect that code submitted prior to the deadline means that it will be
accepted.

Note to new driver submitters:
All requirements stated here [2] and in related pages still apply. Even though
the deadline has been pushed out, all third party CI and code quality
requirements must still be met.

Sean (smcginnis)

[1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[2] https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

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

[openstack-dev] [Cinder] Mitaka Midcycle Sprint

[Sean McGinnis]

Cinder Mitaka Midcycle Sprint

Dates: January 26-29 (29th will be optional hack day)
Location: NetApp Office
7301 Kit Creek Road, Research Triangle Park, NC 27709
https://www.openstreetmap.org/search?query=35.8578%2C-78.8839#map=16/35.8569/-78.8851

Contact: Tom Barron (tbarron)

Nearest airport: Raleigh-Durham International (RDU)
https://www.openstreetmap.org/way/209063360

Hours: 
9AM EST - ?
14:00 UDT - ?

If you plan on attending, either physically or virtually, please update the
planning etherpad [1].

Additional details and discounted lodging information will be added to the
etherpad as we work out the specifics.

[1] https://etherpad.openstack.org/p/mitaka-cinder-midcycle

Thanks!
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-dev] [Cinder] Listing of backends

[Pradip Mukhopadhyay]

Hi,


Is there a way to find out/list down the backends discovered for Cinder?


There is, I guess, no API for get the list of backends.



Thanks,
Pradip
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] HA issues

[John Griffith]

On Mon, Dec 8, 2014 at 8:18 AM, Dulko, Michal  wrote:
> Hi all!
>
>
>
> At the summit during crossproject HA session there were multiple Cinder
> issues mentioned. These can be found in this etherpad:
> https://etherpad.openstack.org/p/kilo-crossproject-ha-integration
>
>
>
> Is there any ongoing effort to fix these issues? Is there an idea how to
> approach any of them?
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Thanks for the nudge on this, personally I hadn't seen this.  So the
items are pretty vague, there are def plans to try and address a
number of race conditions etc.  I'm not aware of any specific plans to
focus on HA from this perspective, or anybody stepping up to work on
it but certainly would be great for somebody to dig in and start
flushing this out.

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

Re: [openstack-dev] [cinder] HA issues

[Dulko, Michal]

And what about no recovery in case of failure mid-task? I can see that there's 
some TaskFlow integration done. This lib seems to address these issues (if used 
with taskflow.persistent submodule, which Cinder isn't using). Any plans for 
further integration with TaskFlow?

-Original Message-
From: John Griffith [mailto:john.griffi...@gmail.com] 
Sent: Monday, December 8, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] HA issues

On Mon, Dec 8, 2014 at 8:18 AM, Dulko, Michal  wrote:
> Hi all!
>
>
>
> At the summit during crossproject HA session there were multiple 
> Cinder issues mentioned. These can be found in this etherpad:
> https://etherpad.openstack.org/p/kilo-crossproject-ha-integration
>
>
>
> Is there any ongoing effort to fix these issues? Is there an idea how 
> to approach any of them?
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Thanks for the nudge on this, personally I hadn't seen this.  So the items are 
pretty vague, there are def plans to try and address a number of race 
conditions etc.  I'm not aware of any specific plans to focus on HA from this 
perspective, or anybody stepping up to work on it but certainly would be great 
for somebody to dig in and start flushing this out.

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

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

Re: [openstack-dev] [cinder] HA issues

[Duncan Thomas]

There are some significant limitations to the pure taskflow approach,
however some combination of atomic micro-state management and taskflow
persistence is being looked at

Duncan Thomas
On Dec 9, 2014 6:24 PM, "Dulko, Michal"  wrote:

> And what about no recovery in case of failure mid-task? I can see that
> there's some TaskFlow integration done. This lib seems to address these
> issues (if used with taskflow.persistent submodule, which Cinder isn't
> using). Any plans for further integration with TaskFlow?
>
> -Original Message-
> From: John Griffith [mailto:john.griffi...@gmail.com]
> Sent: Monday, December 8, 2014 11:28 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder] HA issues
>
> On Mon, Dec 8, 2014 at 8:18 AM, Dulko, Michal 
> wrote:
> > Hi all!
> >
> >
> >
> > At the summit during crossproject HA session there were multiple
> > Cinder issues mentioned. These can be found in this etherpad:
> > https://etherpad.openstack.org/p/kilo-crossproject-ha-integration
> >
> >
> >
> > Is there any ongoing effort to fix these issues? Is there an idea how
> > to approach any of them?
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> Thanks for the nudge on this, personally I hadn't seen this.  So the items
> are pretty vague, there are def plans to try and address a number of race
> conditions etc.  I'm not aware of any specific plans to focus on HA from
> this perspective, or anybody stepping up to work on it but certainly would
> be great for somebody to dig in and start flushing this out.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] [driver] DB operations

[Amit Das]

Hi Stackers,

I have been developing a Cinder driver for CloudByte storage and have come
across some scenarios where the driver needs to do create, read & update
operations on cinder database (volume_admin_metadata table). This is
required to establish a mapping between OpenStack IDs with the backend
storage IDs.

Now, I have got some review comments w.r.t the usage of DB related
operations esp. w.r.t raising the context to admin.

In short, it has been advised not to use "*context.get_admin_context()*".

https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py

However, i get errors trying to use the default context as shown below:

*2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher   File
"/opt/stack/cinder/cinder/db/sqlalchemy/api.py", line 103, in
is_admin_context*
*2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return
context.is_admin*
*2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher
AttributeError: 'module' object has no attribute 'is_admin'*

So what is the proper way to run these DB operations from within a driver ?


Regards,
Amit
*CloudByte Inc.* 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] volume / host coupling

[Arne Wiebalck]

Hi,

The fact that volume requests (in particular deletions) are coupled with 
certain Cinder hosts is not ideal from an operational perspective:
if the node has meanwhile disappeared, e.g. retired, the deletion gets stuck 
and can only be unblocked by changing the database. Some
people apparently use the ‘host’ option in cinder.conf to make the hosts 
indistinguishable, but this creates problems in other places.

From what I see, even for backends that would support it (such as Ceph), Cinder 
currently does not provide means to ensure that any of
the hosts capable of performing a volume operation would be assigned the 
request in case the original/desired one is no more available,
right?

If that is correct, how about changing the scheduling of delete operation to 
use the same logic as create operations, that is pick any of the
available hosts, rather than the one which created a volume in the first place 
(for backends where that is possible, of course)?

Thanks!
 Arne 

—
Arne Wiebalck
CERN IT
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] documenting volume replication

[Ronen Kat]

As some of you are aware the spec for replication
is not up to date, 
The current developer documentation,
http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html,
cover replication but some folks indicated that it need additional details.

In order to get the spec and documentation
up to date I created an Etherpad to be a base for the update.
The Etherpad page is on https://etherpad.openstack.org/p/cinder-replication-redoc

I would appreciate if interested parties
would take a look at the Etherpad, add comments, details, questions and
feedback.

Ronen,


__
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] Rolling upgrades

[Sean McGinnis]

On Tue, Dec 15, 2015 at 01:09:10PM +0100, Micha?? Dulko wrote:
> Hi,
> 
> At the meeting recently it was mentioned that our rolling upgrades
> efforts are pursuing an "elusive unicorn" that makes development a lot
> more complicated and restricted. I want to try to clarify this a bit,
> explain the strategy more and give an update on the status of the whole
> affair.

Thanks for the overview Michal. This is such a large and complicated
effort - this helps a lot.

I do think (hope) it is worth the extra effort. This will be a big win
for long term usability.

Thanks!
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-dev] [cinder] oslo_config.PortOp is undefined

[Pradip Mukhopadhyay]

Hello,


I have a devstack created on 12/22/15. Just seeing that (after a vacation)
it stops working.

Tried to restart the cinder services, getting the error:

stack@openstack4:~/devstack$ /usr/local/bin/cinder-api --config-file
/etc/cinder/cinder.conf & echo $! >/opt/stack/status/stack/c-api.pid; fg ||
echo "c-api failed to start" | tee "/opt/stack/status/stack/c-api.failure"
[1] 23828
/usr/local/bin/cinder-api --config-file /etc/cinder/cinder.conf
Traceback (most recent call last):
  File "/usr/local/bin/cinder-api", line 6, in 
from cinder.cmd.api import main
  File "/opt/stack/cinder/cinder/cmd/api.py", line 37, in 
from cinder import service
  File "/opt/stack/cinder/cinder/service.py", line 65, in 
cfg.PortOpt('osapi_volume_listen_port',
AttributeError: 'module' object has no attribute 'PortOpt'
c-api failed to start
stack@openstack4:~/devstack$



Looks like something to do with oslo_config.PortOpt.

I dont have any port mentioned in cinder.conf (tried also specifying 8070 -
same failure).

When commenting out the lines, getting the following for rabbit:

2016-01-05 05:44:10.421 TRACE cinder plugin = ep.resolve()
2016-01-05 05:44:10.421 TRACE cinder   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2016-01-05 05:44:10.421 TRACE cinder module =
__import__(self.module_name, fromlist=['__name__'], level=0)
2016-01-05 05:44:10.421 TRACE cinder   File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/impl_rabbit.py",
line 94, in 
2016-01-05 05:44:10.421 TRACE cinder cfg.PortOpt('rabbit_port',
2016-01-05 05:44:10.421 TRACE cinder AttributeError: 'module' object has no
attribute 'PortOpt'
2016-01-05 05:44:10.421 TRACE cinder



Any workaround (unstack and stacking want to avoid) would be hightly
appreciated.



Thanks in advance,
Pradip
__
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] Brocade CI

[Tim O'Konski]

Mike:

We are looking into the CI issues now, thank you for bringing to our attention.

Tim

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Sunday, August 09, 2015 5:35 PM
To: OpenStack Development Mailing List 
Cc: DL-GRP-ENG-Brocade-Openstack-CI 
Subject: [cinder] Brocade CI

People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

-- 
Mike Perez

__
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] Brocade CI

[Nagendra Jaladanki]

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday
but looks like didn't get posted on the lists.openstack.org. Hence posting
it here again.

We reviewed your comments and following issues were identified and some of
them are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build
sucucess or failures. The report tool is not seeing these. We are working
on correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs
from the generated report.  If you have any specific uses where it failed
to post logs link, please share with us. But we did see that CI not posted
the comment at all for some review patch sets. Root causing the issue why
CI not posted the comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We
also observed that CI was not posting the failures in some cases where CI
failed due non openstack issues. We corrected this. Now the CI should be
posting the results for all patch sets either success or failure.

We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to
post this list on the updates.

Thanks & Regards,

Nagendra Rao Jaladanki

Manager, Software Engineering Manageability Brocade

130 Holger Way, San Jose, CA 95134

On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez  wrote:

> People have asked me at the Cinder midcycle sprint to look at the Brocade
> CI
> to:
>
> 1) Keep the zone manager driver in Liberty.
> 2) Consider approving additional specs that we're submitted before the
>deadline.
>
> Here are the current problems with the last 100 runs [1]:
>
> 1) Not posting success or failure.
> 2) Not posting a result link to view logs.
> 3) Not consistently doing runs. If you compare with other CI's there are
> plenty
>missing in a day.
>
> This CI does not follow the guidelines [2]. Please get help [3].
>
> [1] - http://paste.openstack.org/show/412316/
> [2] -
> http://docs.openstack.org/infra/system-config/third_party.html#requirements
> [3] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions
>
> --
> Mike Perez
>
> __
> 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] Brocade CI

[Asselin, Ramy]

Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: brocade-openstack...@brocade.com
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org<http://lists.openstack.org>. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to post 
this list on the updates.

Thanks & Regards,

Nagendra Rao Jaladanki

Manager, Software Engineering Manageability Brocade

130 Holger Way, San Jose, CA 95134

On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez 
mailto:thin...@gmail.com>> wrote:
People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] Brocade CI

[Nagendra Jaladanki]

Ramy,

Thanks for providing the correct message. We will update our commit message
accordingly.

Thanks,
Nagendra Rao


On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy  wrote:

> Hi Nagendra,
>
>
>
> Seems one of the issues is the format of the posted comments. The correct
> format is documented here [1]
>
>
>
> Notice the format is not correct:
>
> Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at:
> http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
>
> Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE]
> some comment about the test
>
>
>
> Ramy
>
>
>
> [1]
> http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit
>
>
>
> *From:* Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
> *Sent:* Wednesday, August 12, 2015 4:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Cc:* brocade-openstack...@brocade.com
> *Subject:* Re: [openstack-dev] [cinder] Brocade CI
>
>
>
> Mike,
>
> Thanks for your feedback and suggestions. I had send my response yesterday
> but looks like didn't get posted on the lists.openstack.org. Hence
> posting it here again.
>
> We reviewed your comments and following issues were identified and some of
> them are fixed and some fix plans in progress:
>
>
> 1) Not posting success or failure
>
>  The Brocade CI is a non-voting CI. The CI is posting the comment for
> build sucucess or failures. The report tool is not seeing these. We are
> working on correcting this.
> 2) Not posting a result link to view logs.
>
>We could not find any cases where CI is failed to post the link to logs
> from the generated report.  If you have any specific uses where it failed
> to post logs link, please share with us. But we did see that CI not posted
> the comment at all for some review patch sets. Root causing the issue why
> CI not posted the comment at all.
> 3) Not consistently doing runs.
>
>There were planned down times and CI not posted during those periods.
> We also observed that CI was not posting the failures in some cases where
> CI failed due non openstack issues. We corrected this. Now the CI should be
> posting the results for all patch sets either success or failure.
>
> We are also doing the following:
>
> - Enhance the message format to be inline with other CIs.
>
> - Closely monitoring the incoming Jenkin's request vs out going builds and
> correcting if there are any issues.
>
>
>
> Once again thanks for your feedback and suggestions. We will continue to
> post this list on the updates.
>
>
> Thanks & Regards,
>
> Nagendra Rao Jaladanki
>
> Manager, Software Engineering Manageability Brocade
>
> 130 Holger Way, San Jose, CA 95134
>
>
>
> On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez  wrote:
>
> People have asked me at the Cinder midcycle sprint to look at the Brocade
> CI
> to:
>
> 1) Keep the zone manager driver in Liberty.
> 2) Consider approving additional specs that we're submitted before the
>deadline.
>
> Here are the current problems with the last 100 runs [1]:
>
> 1) Not posting success or failure.
> 2) Not posting a result link to view logs.
> 3) Not consistently doing runs. If you compare with other CI's there are
> plenty
>missing in a day.
>
> This CI does not follow the guidelines [2]. Please get help [3].
>
> [1] - http://paste.openstack.org/show/412316/
> [2] -
> http://docs.openstack.org/infra/system-config/third_party.html#requirements
> [3] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Midcycle Sprint Summary

[Mike Perez]

A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
Full meeting notes available [1].

Image Caching
=
Glance Cinder backend store + Cinder Image Caching are so similar, it would
just be confusing to operators. We'll document only about the Cinder Image
Caching since the Glance backend store is limited in comparison.


Revisit Spec Review
===
The PTL in the future will be the only one to +2/A specs after sufficient +1's
have been given, and notice of approval to follow in the Cinder meeting.


When Specs and Blueprints are needed

Done https://wiki.openstack.org/wiki/Cinder/how-to-contribute-new-feature


People can guess UUID's that don't belong to them
=
Who cares. In past security discussions this has been a moot point.


Update Hypervisor about extending attached volumes
==
Add support to os-brick, but the Nova team has to be fine with this only
supporting Libvirt for now.


Microversions
=
We're doing it.


Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


Third Party CI for target drivers and zone manager drivers
==
Yes. This is already happening for Brocade and Cisco in Liberty!


Cinder <-> Nova API communication
=
Agreed on how the Cinder API should be used. It requires changes and
a Microversion bump on the Nova side. Design summit session to follow.


Out of tree drivers
===
No.


Exposing force-detach of a volumes
==
Yes, this will be in nova-manage in Liberty.


HA and Cinder
=
We need cross project consensus first. There are existing issues that can be
fixed without a DLM. Fix those first. Mike Perez will be leading cross project 
discussion at the summit.


Replication V2
==
John Griffith did extreme programming with the group and posted a review.
A limited replication feature with async and manual failover should be in
Liberty.


ABC classes for each driver feature
===
Keeping the current solution [2].


[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-June/067563.html

-- 
Mike Perez

__
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] Brocade CI

[Angela Smith]

Mike,
I wanted to update you on our progress on the Brocade CI.
We are currently working on the remaining requirements of adding recheck and 
adding link to wiki page for a failed result.
Also, the CI is now consistently testing and reporting on all cinder reviews 
for the past 3 days.
Thanks,
Angela

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Thursday, August 13, 2015 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: Re: [openstack-dev] [cinder] Brocade CI

Ramy,
Thanks for providing the correct message. We will update our commit message 
accordingly.
Thanks,
Nagendra Rao

On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki 
[mailto:nagendra.jalada...@gmail.com<mailto:nagendra.jalada...@gmail.com>]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Cc: brocade-openstack...@brocade.com<mailto:brocade-openstack...@brocade.com>
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org<http://lists.openstack.org>. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to post 
this list on the updates.

Thanks & Regards,

Nagendra Rao Jaladanki

Manager, Software Engineering Manageability Brocade

130 Holger Way, San Jose, CA 95134

On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez 
mailto:thin...@gmail.com>> wrote:
People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

--
Mike Perez

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

__
OpenStack Developmen

Re: [openstack-dev] [cinder] Brocade CI

[Angela Smith]

Mike,
An update on Brocade CI progress.  We are now using the format required for 
results to show in lastcomment script.
We have been consistently reporting for last 9 days.  See results here: [1].
We are still working on resolving recheck issue and adding link to wiki page in 
the failed result comment message.   Update will be sent when that is completed.
Thanks,
Angela

[1] http://paste.openstack.org/show/430074/

From: Angela Smith
Sent: Friday, August 21, 2015 1:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
I wanted to update you on our progress on the Brocade CI.
We are currently working on the remaining requirements of adding recheck and 
adding link to wiki page for a failed result.
Also, the CI is now consistently testing and reporting on all cinder reviews 
for the past 3 days.
Thanks,
Angela

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Thursday, August 13, 2015 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: Re: [openstack-dev] [cinder] Brocade CI

Ramy,
Thanks for providing the correct message. We will update our commit message 
accordingly.
Thanks,
Nagendra Rao

On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki 
[mailto:nagendra.jalada...@gmail.com<mailto:nagendra.jalada...@gmail.com>]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Cc: brocade-openstack...@brocade.com<mailto:brocade-openstack...@brocade.com>
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org<http://lists.openstack.org>. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to post 
this list on the updates.

Thanks & Regards,

Nagendra Rao Jaladanki

Manager, Software Engineering Manageability Brocade

130 Holger Way, San Jose, CA 95134

On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez 
mailto:thin...@gmail.com>> wrote:
People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists

Re: [openstack-dev] [cinder] Brocade CI

[Angela Smith]

The full results of lastcomment script are here for last 400 commits: [1][2]

[1] http://paste.openstack.org/show/430074/
[2] http://paste.openstack.org/show/430088/


From: Angela Smith
Sent: Thursday, August 27, 2015 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
An update on Brocade CI progress.  We are now using the format required for 
results to show in lastcomment script.
We have been consistently reporting for last 9 days.  See results here: [1].
We are still working on resolving recheck issue and adding link to wiki page in 
the failed result comment message.   Update will be sent when that is completed.
Thanks,
Angela

[1] http://paste.openstack.org/show/430074/

From: Angela Smith
Sent: Friday, August 21, 2015 1:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
I wanted to update you on our progress on the Brocade CI.
We are currently working on the remaining requirements of adding recheck and 
adding link to wiki page for a failed result.
Also, the CI is now consistently testing and reporting on all cinder reviews 
for the past 3 days.
Thanks,
Angela

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Thursday, August 13, 2015 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: Re: [openstack-dev] [cinder] Brocade CI

Ramy,
Thanks for providing the correct message. We will update our commit message 
accordingly.
Thanks,
Nagendra Rao

On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki 
[mailto:nagendra.jalada...@gmail.com<mailto:nagendra.jalada...@gmail.com>]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Cc: brocade-openstack...@brocade.com<mailto:brocade-openstack...@brocade.com>
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org<http://lists.openstack.org>. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to post 
this list on the updates.

Thanks & Regards,

Nagendra Rao Jaladanki

Manager, Software Engineering Manageability Brocade

130 Holger Way, San Jose, CA 95134

On Sun, Aug 9, 2015 at 5:34 PM, Mike Perez 
mailto:thin...@gmail.com>> wrote:
People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.or

Re: [openstack-dev] [cinder] Brocade CI

[Angela Smith]

Mike,

Brocade OpenStack CI is now complying with requirements mentioned in your mail.

1.   Reporting success/failure. (FYI, we had been doing this prior to your 
email, but the results were not visible using lastcomment script unless use the 
–m option)

2.   Link is now posted for logs in comment and in right hand results 
column, per the message format requirement.

3.   Reporting consistently on all patchsets.

4.   Recheck is working.

5.   Failed message contains wiki link, and recheck message.

6.   Brocade OpenStack CI will remain non-voting.

Thanks,
Angela

From: Angela Smith
Sent: Thursday, August 27, 2015 2:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

The full results of lastcomment script are here for last 400 commits: [1][2]

[1] http://paste.openstack.org/show/430074/
[2] http://paste.openstack.org/show/430088/


From: Angela Smith
Sent: Thursday, August 27, 2015 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
An update on Brocade CI progress.  We are now using the format required for 
results to show in lastcomment script.
We have been consistently reporting for last 9 days.  See results here: [1].
We are still working on resolving recheck issue and adding link to wiki page in 
the failed result comment message.   Update will be sent when that is completed.
Thanks,
Angela

[1] http://paste.openstack.org/show/430074/

From: Angela Smith
Sent: Friday, August 21, 2015 1:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: RE: [openstack-dev] [cinder] Brocade CI

Mike,
I wanted to update you on our progress on the Brocade CI.
We are currently working on the remaining requirements of adding recheck and 
adding link to wiki page for a failed result.
Also, the CI is now consistently testing and reporting on all cinder reviews 
for the past 3 days.
Thanks,
Angela

From: Nagendra Jaladanki [mailto:nagendra.jalada...@gmail.com]
Sent: Thursday, August 13, 2015 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: DL-GRP-ENG-Brocade-Openstack-CI
Subject: Re: [openstack-dev] [cinder] Brocade CI

Ramy,
Thanks for providing the correct message. We will update our commit message 
accordingly.
Thanks,
Nagendra Rao

On Thu, Aug 13, 2015 at 4:43 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Hi Nagendra,

Seems one of the issues is the format of the posted comments. The correct 
format is documented here [1]

Notice the format is not correct:
Incorrect: Brocade Openstack CI (non-voting) build SUCCESS logs at: 
http://144.49.208.28:8000/build_logs/2015-08-13_18-19-19/
Correct: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some 
comment about the test

Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit

From: Nagendra Jaladanki 
[mailto:nagendra.jalada...@gmail.com<mailto:nagendra.jalada...@gmail.com>]
Sent: Wednesday, August 12, 2015 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Cc: brocade-openstack...@brocade.com<mailto:brocade-openstack...@brocade.com>
Subject: Re: [openstack-dev] [cinder] Brocade CI

Mike,

Thanks for your feedback and suggestions. I had send my response yesterday but 
looks like didn't get posted on the 
lists.openstack.org<http://lists.openstack.org>. Hence posting it here again.

We reviewed your comments and following issues were identified and some of them 
are fixed and some fix plans in progress:

1) Not posting success or failure
 The Brocade CI is a non-voting CI. The CI is posting the comment for build 
sucucess or failures. The report tool is not seeing these. We are working on 
correcting this.
2) Not posting a result link to view logs.
   We could not find any cases where CI is failed to post the link to logs from 
the generated report.  If you have any specific uses where it failed to post 
logs link, please share with us. But we did see that CI not posted the comment 
at all for some review patch sets. Root causing the issue why CI not posted the 
comment at all.
3) Not consistently doing runs.
   There were planned down times and CI not posted during those periods. We 
also observed that CI was not posting the failures in some cases where CI 
failed due non openstack issues. We corrected this. Now the CI should be 
posting the results for all patch sets either success or failure.
We are also doing the following:
- Enhance the message format to be inline with other CIs.
- Closely monitoring the incoming Jenkin's request vs out going builds and 
correcting if there are any issues.

Once again thanks for your feedback and suggestions. We will continue to

[openstack-dev] [cinder] Design Summit Topics

[Mike Perez]

Propose your topics:

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

Next Cinder meeting, we'll discuss them:

https://wiki.openstack.org/wiki/CinderMeetings

--
Mike Perez

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

[openstack-dev] [cinder] PTL Non-Candidacy

[Mike Perez]

Hello all,

I will not be running for Cinder PTL this next cycle. Each cycle I ran
was for a reason [1][2], and the Cinder team should feel proud of our
accomplishments:

* Spearheading the Oslo work to allow *all* OpenStack projects to have
their database being independent of services during upgrades.
* Providing quality to OpenStack operators and distributors with over
60 accepted block storage vendor drivers with reviews and enforced CI
[3].
* Helping other projects with third party CI for their needs.
* Being a welcoming group to new contributors. As a result we grew greatly [4]!
* Providing documentation for our work! We did it for Kilo [5], and I
was very proud to see the team has already started doing this on their
own to prepare for Liberty.

I would like to thank this community for making me feel accepted in
2010. I would like to thank John Griffith for starting the Cinder
project, and empowering me to lead the project through these couple of
cycles.

With the community's continued support I do plan on continuing my
efforts, but focusing cross project instead of just Cinder. The
accomplishments above are just some of the things I would like to help
others with to make OpenStack as a whole better.


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046788.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-April/060530.html
[3] - 
http://superuser.openstack.org/articles/what-you-need-to-know-about-openstack-cinder
[4] - http://thing.ee/cinder/active_contribs.png
[5] - https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Key_New_Features_7

--
Mike Perez

__
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] PTL Candidacy

[hao wang]

Thanks Sean, Vote +1.

2015-09-14 22:49 GMT+08:00 Sean McGinnis :
> Hello everyone,
>
> I'm announcing my candidacy for Cinder PTL for the Mitaka release.
>
> The Cinder team has made great progress. We've not only grown the
> number of supported backend drivers, but we've made significant
> improvements to the core code and raised the quality of existing
> and incoming code contributions. While there are still many things
> that need more polish, we are headed in the right direction and
> block storage is a strong, stable component to many OpenStack clouds.
>
> Mike and John have provided the leadership to get the project where
> it is today. I would like to keep that momentum going.
>
> I've spent over a decade finding new and interesting ways to create
> and delete volumes. I also work across many different product teams
> and have had a lot of experience collaborating with groups to find
> a balance between the work being done to best benefit all involved.
>
> I think I can use this experience to foster collaboration both within
> the Cinder team as well as between Cinder and other related projects
> that interact with storage services.
>
> Some topics I would like to see focused on for the Mitaka release
> would be:
>
>  * Complete work of making the Cinder code Python3 compatible.
>  * Complete conversion to objects.
>  * Sort out object inheritance and appropriate use of ABC.
>  * Continued stabilization of third party CI.
>  * Make sure there is a good core feature set regardless of backend type.
>  * Reevaluate our deadlines to make sure core feature work gets enough
>time and allows drivers to implement support.
>
> While there are some things I think we need to do to move the project
> forward, I am mostly open to the needs of the community as a whole
> and making sure that what we are doing is benefiting OpenStack and
> making it a simpler, easy to use, and ubiquitous platform for the
> cloud.
>
> Thank you for your consideration!
>
> Sean McGinnis (smcginnis)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best Wishes For 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

Re: [openstack-dev] [Cinder] PTL Candidacy

[Nikesh Kumar Mahalka]

Thanks Sean, Vote +1.

On Tue, Sep 15, 2015 at 8:36 AM, hao wang  wrote:

> Thanks Sean, Vote +1.
>
> 2015-09-14 22:49 GMT+08:00 Sean McGinnis :
> > Hello everyone,
> >
> > I'm announcing my candidacy for Cinder PTL for the Mitaka release.
> >
> > The Cinder team has made great progress. We've not only grown the
> > number of supported backend drivers, but we've made significant
> > improvements to the core code and raised the quality of existing
> > and incoming code contributions. While there are still many things
> > that need more polish, we are headed in the right direction and
> > block storage is a strong, stable component to many OpenStack clouds.
> >
> > Mike and John have provided the leadership to get the project where
> > it is today. I would like to keep that momentum going.
> >
> > I've spent over a decade finding new and interesting ways to create
> > and delete volumes. I also work across many different product teams
> > and have had a lot of experience collaborating with groups to find
> > a balance between the work being done to best benefit all involved.
> >
> > I think I can use this experience to foster collaboration both within
> > the Cinder team as well as between Cinder and other related projects
> > that interact with storage services.
> >
> > Some topics I would like to see focused on for the Mitaka release
> > would be:
> >
> >  * Complete work of making the Cinder code Python3 compatible.
> >  * Complete conversion to objects.
> >  * Sort out object inheritance and appropriate use of ABC.
> >  * Continued stabilization of third party CI.
> >  * Make sure there is a good core feature set regardless of backend type.
> >  * Reevaluate our deadlines to make sure core feature work gets enough
> >time and allows drivers to implement support.
> >
> > While there are some things I think we need to do to move the project
> > forward, I am mostly open to the needs of the community as a whole
> > and making sure that what we are doing is benefiting OpenStack and
> > making it a simpler, easy to use, and ubiquitous platform for the
> > cloud.
> >
> > Thank you for your consideration!
> >
> > Sean McGinnis (smcginnis)
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Best Wishes For 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] [Cinder] PTL Candidacy

[Duncan Thomas]

Voting is done by formal ballot just before the summit. All Cinder ATCs
will be invited to vote. Voting on the mailing list is just noise.

On 15 September 2015 at 23:40, Nikesh Kumar Mahalka <
nikeshmaha...@vedams.com> wrote:

> Thanks Sean, Vote +1.
>
> On Tue, Sep 15, 2015 at 8:36 AM, hao wang  wrote:
>
>> Thanks Sean, Vote +1.
>>
>> 2015-09-14 22:49 GMT+08:00 Sean McGinnis :
>> > Hello everyone,
>> >
>> > I'm announcing my candidacy for Cinder PTL for the Mitaka release.
>> >
>> > The Cinder team has made great progress. We've not only grown the
>> > number of supported backend drivers, but we've made significant
>> > improvements to the core code and raised the quality of existing
>> > and incoming code contributions. While there are still many things
>> > that need more polish, we are headed in the right direction and
>> > block storage is a strong, stable component to many OpenStack clouds.
>> >
>> > Mike and John have provided the leadership to get the project where
>> > it is today. I would like to keep that momentum going.
>> >
>> > I've spent over a decade finding new and interesting ways to create
>> > and delete volumes. I also work across many different product teams
>> > and have had a lot of experience collaborating with groups to find
>> > a balance between the work being done to best benefit all involved.
>> >
>> > I think I can use this experience to foster collaboration both within
>> > the Cinder team as well as between Cinder and other related projects
>> > that interact with storage services.
>> >
>> > Some topics I would like to see focused on for the Mitaka release
>> > would be:
>> >
>> >  * Complete work of making the Cinder code Python3 compatible.
>> >  * Complete conversion to objects.
>> >  * Sort out object inheritance and appropriate use of ABC.
>> >  * Continued stabilization of third party CI.
>> >  * Make sure there is a good core feature set regardless of backend
>> type.
>> >  * Reevaluate our deadlines to make sure core feature work gets enough
>> >time and allows drivers to implement support.
>> >
>> > While there are some things I think we need to do to move the project
>> > forward, I am mostly open to the needs of the community as a whole
>> > and making sure that what we are doing is benefiting OpenStack and
>> > making it a simpler, easy to use, and ubiquitous platform for the
>> > cloud.
>> >
>> > Thank you for your consideration!
>> >
>> > Sean McGinnis (smcginnis)
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Best Wishes For 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
>
>


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

[openstack-dev] [CINDER] [PTL Candidates] Questions

[John Griffith]

​PTL nomination emails are good, but I have a few questions that I'd like
to ask to help me in making my vote.  Some of these are covered in the
general proposal announcements, but I'd love to hear some more detail.

It would be awesome if the Cinder candidates could spend some time and
answer these to help me (and maybe others) make an informed choice:

1. Do you actually have the time to spend to be PTL

I don't think many people realize the time commitment. Between being on top
of reviews and having a pretty consistent view of what's going on and in
process; to meetings, questions on IRC, program management type stuff etc.
Do you feel you'll have the ability for PTL to be your FULL Time job?
Don't forget you're working with folks in a community that spans multiple
time zones.

2. What are your plans to make the Cinder project as a core component
better (no... really, what specifically and how does it make Cinder better)?

Most candidates are representing a storage vendor naturally.  Everyone says
"make Cinder better"; But how do you intend to balance vendor interest and
the interest of the general project?  Where will your focus in the M
release be?  On your vendor code or on Cinder as a whole?  Note; I'm not
suggesting that anybody isn't doing the "right" thing here, I'm just asking
for specifics.

3. ​Why do you want to be PTL for Cinder?

Seems like a silly question, but really when you start asking that question
the answers can be surprising and somewhat enlightening.  There's different
motivators for people, what's yours?  By the way, "my employer pays me a
big bonus if I win" is a perfectly acceptable answer in my opinion, I'd
prefer honesty over anything else.  You may not get my vote, but you'd get
respect.

Thanks,
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] PTL Candidacy

[Gorka Eguileor]

Thanks for your leadership Sean, I think you've done a terrific job.

Gorka.

On 11/03, Sean McGinnis wrote:
> Hey everyone,
> 
> Wow, how six months flies! I'd like to announce my candidacy to continue on as
> Cinder PTL for the Newton release cycle.
> 
> A lot has been accomplished in the Mitaka cycle. After a lot of work by many
> folks, over a couple development cycles, we now have what we consider a "tech
> preview" of rolling upgrades. It just hasn't had enough runtime and testing 
> for
> us to say it's "official". We will likely need to fix a few minor things in 
> the
> Newton timeframe before it's fully baked and reliable. But it has come a long
> way and I'm really happy with the progress that has been made.
> 
> Another priority we had identified for Mitaka was active/active high
> availability of the c-vol service. We were not able to complete that work, but
> many pieces have been put in place to support that in Newton. We fixed several
> API races and added the ability to use something like tooz for locking. These
> are foundation pieces for us to be able to start breaking out things and
> running in a reliable active/active configuration.
> 
> Microversion support has been added and there is now a new v3 API endpoint.
> This was a bit of a controversy as we really had just started to get folks to
> move off of v1 to v2. To be safe though I decided it would protect end users
> better to have a clearly separate new API endpoint for the microversion
> compatibility. And now hopefully it is our last.
> 
> Replication was another slightly controversial feature implemented. Late in
> Liberty we finally agreed on a spec for a v2 version of replication. The v2
> spec was approved so late that no one actually had time to implement it for
> that release. As we started to implement it for Mitaka we found that a lot of
> compromises had crept in during the spec review that it had the risk of being
> too complex and having some of the issues we were trying to get rid of by
> moving away from replication v1. At our midcycle we had a lot of discussion on
> replication and finally decided to change course before it was too late.
> Whether that ends up being the best choice when we look back a year from now 
> or
> not, I'm proud of the team that we were willing to put on the brakes and make
> changes - even though it was more work for us - before we released something
> out to end users that would have caused problems or a poor experience.
> 
> Other than that, there's mostly been a lot of good bug fixes. Eight new 
> drivers
> have been added from (I think) five different vendors. The os-brick library is
> now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common
> storage management operations so there is not a duplication and disconnect of
> code between the two projects. We were also able to add a Brick cinder client
> extension to be able to perform storage management on nodes without Nova (bare
> metal, etc.).
> 
> None of this goodness was from me.
> 
> We have a bunch of smart and active members of the Cinder community. They are
> the ones that are making a difference, working across the community, and
> making sure Cinder is a solid component in an OpenStack cloud.
> 
> Being part of the Cinder community has been one of the best and most engaging
> parts of my career. I am lucky enough to have support from my company to be
> able to devote time to being a part of this. I would love the opportunity to
> continue as PTL to not just contribute where I can, but to make sure the folks
> doing the heavy lifting have the support and project organization they need to
> avoid distractions and be able to focus on getting the important stuff done.
> 
> I think in Newton we need to continue the momentum and get Active/Active 
> Cinder
> volume service support implemented. We need to continue to work closely with
> the Nova team to make sure our interaction is correct and solid. But also work
> to make Cinder a useful storage management interface in environments without
> Nova. I will continue to encourage developer involvement and vendor support.
> We need to improve the user experience with better error reporting when things
> go wrong. And last, but definitely not least, we need to continue to expand 
> our
> testing - unit, functional, and tempest - to make sure we can avoid those
> errors and deliver a high quality and solid solution.
> 
> I really feel I'm just getting into the swing of things. I would love the
> opportunity to serve as PTL for the Newton release.
> 
> Thank you for your consideration.
> 
> Sean McGinnis (smcginnis)
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_

Re: [openstack-dev] [Cinder] PTL Candidacy

[Tom Barron]

On 03/11/2016 01:41 PM, Sean McGinnis wrote:
> Hey everyone,
> 
> Wow, how six months flies! I'd like to announce my candidacy to continue on as
> Cinder PTL for the Newton release cycle.
> 
> A lot has been accomplished in the Mitaka cycle. After a lot of work by many
> folks, over a couple development cycles, we now have what we consider a "tech
> preview" of rolling upgrades. It just hasn't had enough runtime and testing 
> for
> us to say it's "official". We will likely need to fix a few minor things in 
> the
> Newton timeframe before it's fully baked and reliable. But it has come a long
> way and I'm really happy with the progress that has been made.
> 
> Another priority we had identified for Mitaka was active/active high
> availability of the c-vol service. We were not able to complete that work, but
> many pieces have been put in place to support that in Newton. We fixed several
> API races and added the ability to use something like tooz for locking. These
> are foundation pieces for us to be able to start breaking out things and
> running in a reliable active/active configuration.
> 
> Microversion support has been added and there is now a new v3 API endpoint.
> This was a bit of a controversy as we really had just started to get folks to
> move off of v1 to v2. To be safe though I decided it would protect end users
> better to have a clearly separate new API endpoint for the microversion
> compatibility. And now hopefully it is our last.
> 
> Replication was another slightly controversial feature implemented. Late in
> Liberty we finally agreed on a spec for a v2 version of replication. The v2
> spec was approved so late that no one actually had time to implement it for
> that release. As we started to implement it for Mitaka we found that a lot of
> compromises had crept in during the spec review that it had the risk of being
> too complex and having some of the issues we were trying to get rid of by
> moving away from replication v1. At our midcycle we had a lot of discussion on
> replication and finally decided to change course before it was too late.
> Whether that ends up being the best choice when we look back a year from now 
> or
> not, I'm proud of the team that we were willing to put on the brakes and make
> changes - even though it was more work for us - before we released something
> out to end users that would have caused problems or a poor experience.
> 
> Other than that, there's mostly been a lot of good bug fixes. Eight new 
> drivers
> have been added from (I think) five different vendors. The os-brick library is
> now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common
> storage management operations so there is not a duplication and disconnect of
> code between the two projects. We were also able to add a Brick cinder client
> extension to be able to perform storage management on nodes without Nova (bare
> metal, etc.).
> 
> None of this goodness was from me.
> 
> We have a bunch of smart and active members of the Cinder community. They are
> the ones that are making a difference, working across the community, and
> making sure Cinder is a solid component in an OpenStack cloud.
> 
> Being part of the Cinder community has been one of the best and most engaging
> parts of my career. I am lucky enough to have support from my company to be
> able to devote time to being a part of this. I would love the opportunity to
> continue as PTL to not just contribute where I can, but to make sure the folks
> doing the heavy lifting have the support and project organization they need to
> avoid distractions and be able to focus on getting the important stuff done.
> 
> I think in Newton we need to continue the momentum and get Active/Active 
> Cinder
> volume service support implemented. We need to continue to work closely with
> the Nova team to make sure our interaction is correct and solid. But also work
> to make Cinder a useful storage management interface in environments without
> Nova. I will continue to encourage developer involvement and vendor support.
> We need to improve the user experience with better error reporting when things
> go wrong. And last, but definitely not least, we need to continue to expand 
> our
> testing - unit, functional, and tempest - to make sure we can avoid those
> errors and deliver a high quality and solid solution.
> 
> I really feel I'm just getting into the swing of things. I would love the
> opportunity to serve as PTL for the Newton release.

FWIW, you have my support.  Thanks for your service!

-- Tom

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

__

[openstack-dev] [Cinder] Newton Summit Sessions

[Sean McGinnis]

Hey everyone,

This was announced in our weekly meeting, but putting it out here to get
a wider audience and make sure it's seen. I probably should have start
here.

We have started an etherpad [1] for planning out our design summit sessions.
Please feel free to add any additional topics there. If we end up with
too many we'll just have to defer some to a queue to go through on the
final working day on Friday.

Please leave comments there or ping me on IRC if you have any questions
or concerns.

Thanks!
Sean (smcginnis)

[1] https://etherpad.openstack.org/p/newton-cinder-summit-ideas


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

[openstack-dev] [Cinder] Mitaka RC1 available

[Thierry Carrez]

Hello everyone,

Cinder is the next project team to produce a release candidate for the 
end of the Mitaka cycle! You can find the RC1 source code tarball at:


https://tarballs.openstack.org/cinder/cinder-8.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release 
candidate respin, this RC1 will be formally released as the final Mitaka 
Cinder release on April 7th. You are therefore strongly encouraged to 
test and validate this tarball !


Alternatively, you can directly test the stable/mitaka release branch at:

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please 
file it at:


https://bugs.launchpad.net/cinder/+filebug

and tag it *mitaka-rc-potential* to bring it to the Cinder release 
crew's attention.


Note that the "master" branch of Cinder is now open for Newton 
development, and feature freeze restrictions no longer apply there !


Regards,

--
Thierry Carrez (ttx)

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

[openstack-dev] [Cinder] About snapshot Rollback?

[Chenzongliang]

Hi all:
We are condering add a fucntion rollback_snapshot when we use backup. In 
the end user's scenario. If a vm fails, we hope that we can use snapshot to to 
recovery the volume's data.
Beacuse it can quickly recovery our vm. But if we use the remote data to 
recovery. We will spend more time.
But i'm not sure if the data was recoveried from the backend. whether the 
host need to rescan the volumes? At the same time. If a volume have been 
extended, whether it can be roolback?

   I want to know whether the topic have been discussed or have other 
recommendations to us?

   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] [Cinder] Mitaka RC2 available

[Thierry Carrez]

Due to release-critical issues spotted in Cinder during RC1 testing, a 
new release candidate was created for Mitaka. You can find the RC2 
source code tarballs at:


https://tarballs.openstack.org/cinder/cinder-8.0.0.0rc2.tar.gz

Unless new release-critical issues are found that warrant a last-minute 
release candidate respin, this tarball will be formally released as the 
final "Mitaka" version on April 7th. You are therefore strongly 
encouraged to test and validate this tarball !


Alternatively, you can directly test the mitaka release branches at:

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/cinder/+filebug

and tag it *mitaka-rc-potential* to bring it to the Cinder release 
crew's attention.


--
Thierry Carrez

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

[openstack-dev] [Cinder] About snapshot Rollback?

[Chenzongliang]

Dear Cruz:

 Thanks for you kind support, I will review the previous spec according 
to the following links.  May be more user scenario we should considered,such as 
backup,create volume from snapshot,consistency group and etc,we will spend some 
time to gather
the user's scenarios and determin what to do next step.

Sincerely,
zongliang chen

发件人: Erlon Cruz [mailto:sombra...@gmail.com]
发送时间: 2016年4月5日 2:50
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Zhangli (ISSP); Shenhong (C)
主题: Re: [openstack-dev] [Cinder] About snapshot Rollback?

Hi Chen,

Not sure if I got you right but I brought this topic in #openstack-cinder some 
days ago. The idea is to be able to rollback a snapshot in Cinder. Today what 
is possible to do is to create a volume from a snapshot. From the user point of 
view, this is not ideal, as there are several cases, if not the majority of, 
that the purpose of the snapshot is to revert to a desired state, and not keep 
the original volume. For some backends, keeping the original volume means space 
consumption. This space problem becomes bold when we think about consistency 
groups. For consistency groups, some backends might have to copy an entire 
filesystem for each snapshot, consuming space and time. So, I think it would be 
desired to have the ability to revert snapshots.

I know there have been efforts in the past[1] to implement that, but for some 
reason the work was stopped. If you want to retake the effort please create a 
spec[2]  sol everybody can provide feedback.

Erlon


[1] 
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
[2] https://github.com/openstack/cinder-specs

On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang 
mailto:chenzongli...@huawei.com>> wrote:
Hi all:
We are condering add a fucntion rollback_snapshot when we use backup. In 
the end user's scenario. If a vm fails, we hope that we can use snapshot to to 
recovery the volume's data.
Beacuse it can quickly recovery our vm. But if we use the remote data to 
recovery. We will spend more time.
But i'm not sure if the data was recoveried from the backend. whether the 
host need to rescan the volumes? At the same time. If a volume have been 
extended, whether it can be roolback?

   I want to know whether the topic have been discussed or have other 
recommendations to us?

   Thanks

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

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

[openstack-dev] [Cinder] Newton Midcycle Planning

[Sean McGinnis]

Hey Cinder team (and those interested),

We've had a few informal conversations on the channel and in meetings,
but wanted to capture some things here and spread awareness.

I think it would be good to start planning for our Newton midcycle.
These have been incredibly productive in the past (at least in my
opinion) so I'd like to get it on the schedule so folks can start
planning for it.

For Mitaka we held our midcycle in the R-10 week. That seemed to work
out pretty well, but I also think it might be useful to hold it a little
earlier in the cycle to keep some momentum going and make sure things
stay pretty focused for the rest of the cycle.

For reference, here is the current release schedule for Newton:

http://releases.openstack.org/newton/schedule.html

R-10 puts us in the last week of July.

I would have a conflict R-16, R-15. We probably want to avoid US
Independence Day R-13, and milestone weeks R-18 and R12.

So potential weeks look like:

* R-17
* R-14
* R-11
* R-10
* R-9

Nova is in the process of figuring out their date. If we have that, it
would be good to try to avoid an overlap there. Our linked midcycle
session worked out well, but probably better if they don't conflict.

We also need to work out locations. Anyone able and willing to host,
just let me know. We need a facility with wifi, able to hold ~30-40
people, wifi, close to an airport. And wifi.

At some point I still think it would be nice for our international folks
to be able to do a non-US midcycle, but I'm fine if we end up back in Ft
Collins our somewhere similar.

Thanks!

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-dev] [Cinder] API features discoverability

[Michał Dulko]

Hi,

When looking at bug [1] I've thought that we could simply use
/v2//extensions to signal features available in the
deployment - in this case backups, as these are implemented as API
extension too. Cloud admin can disable an extension if his cloud doesn't
support a particular feature and this is easily discoverable using
aforementioned call. Looks like that solution weren't proposed when the
bug was initially raised.

Now the problem is that we're actually planning to move all API
extensions to the core API. Do we plan to keep this API for features
discovery? How to approach API compatibility in this case if we want to
change it? Do we have a plan for that?

We could keep this extensions API controlled from the cinder.conf,
regardless of the fact that we've moved everything to the core, but that
doesn't seem right (API will still be functional, even if administrator
disables it in configuration, am I right?)

Anyone have thoughts on that?

Thanks,
Michal

[1] https://bugs.launchpad.net/cinder/+bug/1334856

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

[openstack-dev] [Cinder] API features discoverability

[D'Angelo, Scott]

I don't think we actually should be moving all the extensions to core, just the 
ones that are supported by all vendors and fully vetted. In other words, we 
should be moving extensions to core based on the original intent of extensions.
That would mean that for backups we could continue to use 
/v2|3//extensions to determine backup support (and anything else 
that is not supported by all vendors, and therefore in core).
As to whether or not the admin disables extensions that are not support by the 
deployment, I believe that admin should be responsible for their own 
deployment's UX.
Perhaps Deepti's new API has a use here, but I think it's worth discussing 
whether we can get the desired functionality out of the extensions, and whether 
we should strive to use extensions the way they were originally intended.

Scott (scottda)


Ramakrishna, Deepti deepti.ramakrishna at intel.com 
<mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BCinder%5D%20API%20features%20discoverability&In-Reply-To=%3CEEF613A4FA911D48911298B78DC42A533A65B666%40ORSMSX109.amr.corp.intel.com%3E>
Mon Apr 18 07:17:41 UTC 2016


Hi Michal,

This seemed like a good idea when I first read it. What more, the server code 
for extension listing [1]
 does not do any authorization, so it can be used for any logged in user.

However, I don't know if requiring the admin to manually disable an extension 
is practical. First, admins
 can always forget to do that. Second, even if they wanted to, it is not clear 
how they could disable specific
 extensions. I assume they would need to edit the cinder.conf file. This file 
currently lists the set of
 extensions to load as cinder.api.contrib.standard_extensions. The server code 
[2] implements this by walking
 the cinder/api/contrib directory and loading all discovered extensions. How is 
it possible to subtract just
one extension from the "standard extensions"? Also, system capabilities and 
extensions may not have a 1:1
 relationship in general.

Having a new extension API (as proposed by me in [3]) for returning the 
available services/functionality does
 not have the above problems. It will dynamically check the existence of the 
cinder-backup service, so it does
 not need manual action from admin. I have published a BP [4] related to this. 
Can you please comment on that?

Thanks,
Deepti

[1] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L152
[2] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L312
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077209.html
[4] https://review.openstack.org/#/c/306930/

-Original Message-
From: Michał Dulko [mailto:michal.dulko at 
intel.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>]
Sent: Thursday, April 14, 2016 7:06 AM
To: OpenStack Development Mailing List (not for usage questions) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
Subject: [openstack-dev] [Cinder] API features discoverability

Hi,

When looking at bug [1] I've thought that we could simply use 
/v2//extensions to signal features
 available in the deployment - in this case backups, as these are implemented 
as API extension too. Cloud admin
 can disable an extension if his cloud doesn't support a particular feature and 
this is easily discoverable using
aforementioned call. Looks like that solution weren't proposed when the bug was 
initially raised.

Now the problem is that we're actually planning to move all API extensions to 
the core API. Do we plan to keep this
 API for features discovery? How to approach API compatibility in this case if 
we want to change it? Do we have a plan
 for that?

We could keep this extensions API controlled from the cinder.conf, regardless 
of the fact that we've moved everything
 to the core, but that doesn't seem right (API will still be functional, even 
if administrator disables it in configuration,
 am I right?)

Anyone have thoughts on that?

Thanks,
Michal

[1] https://bugs.launchpad.net/cinder/+bug/1334856


__
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] Kilo Deadlines

[Mike Perez]

On Sat, Jan 31, 2015 at 1:53 PM, Mike Perez  wrote:
> * Blueprint/Spec approval deadline - February 15th
> * Code freeze for all features - March 10th
>
> After blueprint/spec approval deadline date has passed, you may
> request exception by:
>
> 1) Email the Openstack Dev mailing list with "[cinder] Request Spec
> Freeze Exception" in the subject.
> 2) The spec is reviewed the usual way, but should be a high priority to get 
> in.
>
> These deadlines were agreed on in the Cinder IRC meeting [1].
>
> --
> Mike Perez
>
> [1] - 
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303

February 15th is the last day to get a feature proposed for Kilo in
Cinder. Any blueprints that are not approved after February 15th will
need to request Feature Freeze Exception on this list, with the
subject "[cinder] FFE ". Yes, I changed the format, and
we are terribly oversubscribed as it is.

At this point I've gone through specs and left comments on the ones
that I think that have a chance in Kilo.

A blueprint will be removed from K-3 [1] if it does not have code
proposed and passing Jenkins by March 1st as agreed in the Cinder
meeting [2].

We will not be doing anymore merges, except for bug fixes after March
10th, as explained earlier in this thread and agreed in the Cinder
meeting [3].

Cinder K-3 priorities have been set for people to sign up on [4].

[1] - https://launchpad.net/cinder/+milestone/kilo-3
[2] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-11-16.00.log.html#l-328
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303
[4] - https://etherpad.openstack.org/p/cinder-k3-priorities

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

[Zhipeng Huang]

Hi Ronen,

Xingyang mentioned there's another etherpad on rep and CG, which etherpad
should we mainly follow ?

On Mon, Feb 16, 2015 at 2:38 PM, Ronen Kat  wrote:

> Ruijing, hi,
>
> Are you discussing the network/fabric between Storage A and Storage B?
> If so, assumption in Cinder is that this is done in advance by the storage
> administrator.
> The design discussions for replication resulted in that the driver is
> fully responsible for replication and it is up to the driver to implement
> and manage replication on its own.
> Hence, all vendor specific setup actions like creating volume pools, setup
> network on the storage side are considered prerequisite actions and outside
> the scope of the Cinder flows.
>
> If someone feels that is not the case, or should not be the case, feel
> free to chime in.
>
> Or does this relates to setting up the data path for accessing both
> Storage A and Storage B?
> Should this be setup in advance? When we attach the primary volume to the
> VM? Or when promoting the replica to be primary?
>
> -- Ronen
>
>
>
> From:"Guo, Ruijing" 
> To:"OpenStack Development Mailing List (not for usage questions)"
> 
> Date:16/02/2015 02:29 AM
> Subject:Re: [openstack-dev] [cinder] documenting volume
> replication
> --
>
>
>
> Hi, Ronen
>
> 3) I mean storage based replication. In normal, volume replication support
> FC or iSCSI. We need to setup FC or iSCSI before we do volume replication.
>
> Case 1)
>
> Host --FC--Storage A ---iSCSI  Storage B FC-
> Host
>
> Case 2)
>
> Host --FC--Storage A ---FC  Storage B FC- Host
>
> As above diagram, we need to setup connection (iSCSI or FC) between
> storage A and Storage B.
>
> For FC, we need to zone storage A & storage B in FC switch.
>
> Thanks,
> -Ruijing
>
> *From:* Ronen Kat [mailto:ronen...@il.ibm.com ]
> * Sent:* Sunday, February 15, 2015 4:46 PM
> * To:* OpenStack Development Mailing List (not for usage questions)
> * Subject:* Re: [openstack-dev] [cinder] documenting volume replication
>
> Hi Ruijing,
>
> Thanks for the comments.
> Re (1) - driver can implement replication in any means the driver see fit.
> It can be exported and be available to the scheduler/drive via the
> "capabilities" or "driver" extra-spec prefixes.
> Re (3) - Not sure I see how this relates to storage side replication, do
> you refer to host side replication?
>
> Ronen
>
>
>
> From:"Guo, Ruijing" <*ruijing@intel.com*
> >
> To:"OpenStack Development Mailing List (not for usage questions)"
> <*openstack-dev@lists.openstack.org* >
> Date:15/02/2015 03:41 AM
> Subject:Re: [openstack-dev] [cinder] documenting volume
> replication
> --
>
>
>
>
> Hi, Ronen,
>
> I don’t know how to edit
> *https://etherpad.openstack.org/p/cinder-replication-redoc*
> <https://etherpad.openstack.org/p/cinder-replication-redoc> and add some
> comments in email.
>
> 1. We may add asynchronized and synchronized type for replication.
> 2. We may add CG for replication
> 3. We may add to initialize connection for replication
>
> Thanks,
> -Ruijing
>
> * From:* Ronen Kat [*mailto:ronen...@il.ibm.com* ]
> * Sent:* Tuesday, February 3, 2015 9:41 PM
> * To:* OpenStack Development Mailing List (
> *openstack-dev@lists.openstack.org* )
> * Subject:* [openstack-dev] [cinder] documenting volume replication
>
> As some of you are aware the spec for replication is not up to date,
> The current developer documentation,
> *http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html*
> <http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html>,
> cover replication but some folks indicated that it need additional details.
>
> In order to get the spec and documentation up to date I created an
> Etherpad to be a base for the update.
> The Etherpad page is on
> *https://etherpad.openstack.org/p/cinder-replication-redoc*
> <https://etherpad.openstack.org/p/cinder-replication-redoc>
>
> I would appreciate if interested parties would take a look at the
> Etherpad, add comments, details, questions and feedback.
>
> Ronen,
> __
> 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 replication

[Ronen Kat]

Good question, I have:

https://etherpad.openstack.org/p/cinder-replication-redoc
https://etherpad.openstack.org/p/cinder-replication-cg
https://etherpad.openstack.org/p/volume-replication-fix-planning

Jay seems to be the champion for moving
replication forward, I will let Jay point the way.

-- Ronen



From:      
 Zhipeng Huang 
To:      
 "OpenStack Development
Mailing List (not for usage questions)" 
Date:      
 16/02/2015 09:14 AM
Subject:    
   Re: [openstack-dev]
[cinder] volume replication




Hi Ronen,

Xingyang mentioned there's another etherpad on rep and
CG, which etherpad should we mainly follow ?

On Mon, Feb 16, 2015 at 2:38 PM, Ronen Kat <ronen...@il.ibm.com>
wrote:
Ruijing,
hi, 

Are you discussing the network/fabric between Storage A and Storage B?

If so, assumption in Cinder is that this is done in advance by the storage
administrator. 
The design discussions for replication resulted in that the driver is fully
responsible for replication and it is up to the driver to implement and
manage replication on its own. 
Hence, all vendor specific setup actions like creating volume pools, setup
network on the storage side are considered prerequisite actions and outside
the scope of the Cinder flows. 

If someone feels that is not the case, or should not be the case, feel
free to chime in. 

Or does this relates to setting up the data path for accessing both Storage
A and Storage B? 
Should this be setup in advance? When we attach the primary volume to the
VM? Or when promoting the replica to be primary? 

-- Ronen 



From:        "Guo,
Ruijing" <ruijing@intel.com>

To:        "OpenStack
Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>

Date:        16/02/2015
02:29 AM 
Subject:        Re:
[openstack-dev] [cinder] documenting volume replication





Hi, Ronen 
  
3) I mean storage based replication. In normal, volume replication support
FC or iSCSI. We need to setup FC or iSCSI before we do volume replication.

  
Case 1)   
  
Host --FC--Storage A ---iSCSI  Storage B FC-
Host 
  
Case 2) 
  
Host --FC--Storage A ---FC  Storage B FC- Host

  
As above diagram, we need to setup connection (iSCSI or FC) between storage
A and Storage B. 
  
For FC, we need to zone storage A & storage B in FC switch.

  
Thanks, 
-Ruijing 
  
From: Ronen Kat [mailto:ronen...@il.ibm.com]

Sent: Sunday, February 15, 2015 4:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] documenting volume replication

  
Hi Ruijing,


Thanks for the comments. 
Re (1) - driver can implement replication in any means the driver see fit.
It can be exported and be available to the scheduler/drive via the "capabilities"
or "driver" extra-spec prefixes.

Re (3) - Not sure I see how this relates to storage side replication, do
you refer to host side replication?


Ronen 



From:        "Guo,
Ruijing" <ruijing@intel.com>

To:        "OpenStack
Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>

Date:        15/02/2015
03:41 AM 
Subject:        Re:
[openstack-dev] [cinder] documenting volume replication







Hi, Ronen, 
 
I don’t know how to edit https://etherpad.openstack.org/p/cinder-replication-redoc
and add some comments in email.

 
1.     We may add asynchronized and synchronized type for replication.

2.     We may add CG for replication

3.     We may add to initialize connection for replication

 
Thanks, 
-Ruijing 
 
From: Ronen Kat [mailto:ronen...@il.ibm.com]

Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

 
As some of you are aware the spec for replication is not up to date, 
The current developer documentation, http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html,
cover replication but some folks indicated that it need additional details.


In order to get the spec and documentation up to date I created an Etherpad
to be a base for the update.

The Etherpad page is on https://etherpad.openstack.org/p/cinder-replication-redoc


I would appreciate if interested parties would take a look at the Etherpad,
add comments, details, questions and feedback.


Ronen, __
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

Re: [openstack-dev] [cinder] volume replication

[Zhipeng Huang]

Great :)

On Mon, Feb 16, 2015 at 3:46 PM, Ronen Kat  wrote:

> Good question, I have:
>
> https://etherpad.openstack.org/p/cinder-replication-redoc
> https://etherpad.openstack.org/p/cinder-replication-cg
> https://etherpad.openstack.org/p/volume-replication-fix-planning
>
> Jay seems to be the champion for moving replication forward, I will let
> Jay point the way.
>
> -- Ronen
>
>
>
> From:Zhipeng Huang 
> To:"OpenStack Development Mailing List (not for usage questions)"
> 
> Date:        16/02/2015 09:14 AM
> Subject:Re: [openstack-dev] [cinder] volume replication
> --
>
>
>
> Hi Ronen,
>
> Xingyang mentioned there's another etherpad on rep and CG, which etherpad
> should we mainly follow ?
>
> On Mon, Feb 16, 2015 at 2:38 PM, Ronen Kat <*ronen...@il.ibm.com*
> > wrote:
> Ruijing, hi,
>
> Are you discussing the network/fabric between Storage A and Storage B?
> If so, assumption in Cinder is that this is done in advance by the storage
> administrator.
> The design discussions for replication resulted in that the driver is
> fully responsible for replication and it is up to the driver to implement
> and manage replication on its own.
> Hence, all vendor specific setup actions like creating volume pools, setup
> network on the storage side are considered prerequisite actions and outside
> the scope of the Cinder flows.
>
> If someone feels that is not the case, or should not be the case, feel
> free to chime in.
>
> Or does this relates to setting up the data path for accessing both
> Storage A and Storage B?
> Should this be setup in advance? When we attach the primary volume to the
> VM? Or when promoting the replica to be primary?
>
> -- Ronen
>
>
>
> From:"Guo, Ruijing" <*ruijing@intel.com*
> >
> To:"OpenStack Development Mailing List (not for usage questions)"
> <*openstack-dev@lists.openstack.org* >
> Date:16/02/2015 02:29 AM
> Subject:Re: [openstack-dev] [cinder] documenting volume
> replication
>  --
>
>
>
> Hi, Ronen
>
> 3) I mean storage based replication. In normal, volume replication support
> FC or iSCSI. We need to setup FC or iSCSI before we do volume replication.
>
> Case 1)
>
> Host --FC--Storage A ---iSCSI  Storage B FC-
> Host
>
> Case 2)
>
> Host --FC--Storage A ---FC  Storage B FC- Host
>
> As above diagram, we need to setup connection (iSCSI or FC) between
> storage A and Storage B.
>
> For FC, we need to zone storage A & storage B in FC switch.
>
> Thanks,
> -Ruijing
>
> * From:* Ronen Kat [*mailto:ronen...@il.ibm.com* ]
> * Sent:* Sunday, February 15, 2015 4:46 PM
> * To:* OpenStack Development Mailing List (not for usage questions)
> * Subject:* Re: [openstack-dev] [cinder] documenting volume replication
>
> Hi Ruijing,
>
> Thanks for the comments.
> Re (1) - driver can implement replication in any means the driver see fit.
> It can be exported and be available to the scheduler/drive via the
> "capabilities" or "driver" extra-spec prefixes.
> Re (3) - Not sure I see how this relates to storage side replication, do
> you refer to host side replication?
>
> Ronen
>
>
>
> From:"Guo, Ruijing" <*ruijing@intel.com*
> >
> To:"OpenStack Development Mailing List (not for usage questions)"
> <*openstack-dev@lists.openstack.org* >
> Date:15/02/2015 03:41 AM
> Subject:Re: [openstack-dev] [cinder] documenting volume
> replication
> --
>
>
>
>
>
> Hi, Ronen,
>
> I don’t know how to edit
> *https://etherpad.openstack.org/p/cinder-replication-redoc*
> <https://etherpad.openstack.org/p/cinder-replication-redoc> and add some
> comments in email.
>
> 1. We may add asynchronized and synchronized type for replication.
> 2. We may add CG for replication
> 3. We may add to initialize connection for replication
>
> Thanks,
> -Ruijing
>
> * From:* Ronen Kat [*mailto:ronen...@il.ibm.com* ]
> * Sent:* Tuesday, February 3, 2015 9:41 PM
> * To:* OpenStack Development Mailing List (
> *openstack-dev@lists.openstack.org* )
> * Subject:* [openstack-dev] [cinder] documenting volume replication
>
> As some of you are aware the spec for replication is not up to date,
> The current developer documentation,
> *http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html*
> <http://docs

Re: [openstack-dev] [cinder]Driver broken

[Asselin, Ramy]

Hi Eduard,

Your third party ci reported success on that patch. The tempest volume tests 
include attached & detaches. Seems your CI is not running them?
http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html

CloudFounders OpenvStorage CI check

Mar 10, 2015 9:14 AM

openvstorage-cinder-functionality<http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9>

SUCCESS in 37m 16s


Ramy

From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Wednesday, March 25, 2015 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder]Driver broken

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which introduced 
another parameter to be passed to the driver, but our driver didn't get updated 
so detach_volume fails for us.

How can we get this fixed asap?

Thanks,
Eduard

__
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]Driver broken

[Jordan Pittier]

Hey,

From
http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
:
"Running ` python setup.py testr --testr-args='--subunit --concurrency 1
 test_openvstorage'`"

==
Totals
==
Ran: 10 tests in 2. sec.
 - Passed: 10
 - Skipped: 0
 - Expected Fail: 0
 - Unexpected Success: 0
 - Failed: 0
Sum of execute time for each test: 0.4477 sec.


So his CI did run :)

Jordan


On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy  wrote:

>  Hi Eduard,
>
>
>
> Your third party ci reported success on that patch. The tempest volume
> tests include attached & detaches. Seems your CI is not running them?
>
>
> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
>
>
>
> *CloudFounders OpenvStorage CI check*
>
> *Mar 10, 2015 9:14 AM*
>
> openvstorage-cinder-functionality
> <http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9>
>
> SUCCESS in 37m 16s
>
>
>
> Ramy
>
>
>
> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
> *Sent:* Wednesday, March 25, 2015 8:05 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [cinder]Driver broken
>
>
>
> Hi,
>
>
>
> Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
>
> Seems to be related to https://review.openstack.org/#/c/85847/ which
> introduced another parameter to be passed to the driver, but our driver
> didn't get updated so detach_volume fails for us.
>
>
>
> How can we get this fixed asap?
>
>
>
> Thanks,
>
> Eduard
>
>
>
> __
> 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]Driver broken

[Anita Kuno]

On 03/25/2015 11:44 AM, Jordan Pittier wrote:
> Hey,
> 
> From
> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
> :
> "Running ` python setup.py testr --testr-args='--subunit --concurrency 1
>  test_openvstorage'`"
> 
> ==
> Totals
> ==
> Ran: 10 tests in 2. sec.
>  - Passed: 10
>  - Skipped: 0
>  - Expected Fail: 0
>  - Unexpected Success: 0
>  - Failed: 0
> Sum of execute time for each test: 0.4477 sec.
> 
> 
> So his CI did run :)
> 
> Jordan
Part of the process of running a CI is to be able to answer questions
about your own system.

As a operator of a system maintaining a driver, Eduard, the solution for
fixing your driver is to offer a patch to fix it.

Thanks,
Anita.
> 
> 
> On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy  wrote:
> 
>>  Hi Eduard,
>>
>>
>>
>> Your third party ci reported success on that patch. The tempest volume
>> tests include attached & detaches. Seems your CI is not running them?
>>
>>
>> http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html
>>
>>
>>
>> *CloudFounders OpenvStorage CI check*
>>
>> *Mar 10, 2015 9:14 AM*
>>
>> openvstorage-cinder-functionality
>> <http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9>
>>
>> SUCCESS in 37m 16s
>>
>>
>>
>> Ramy
>>
>>
>>
>> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
>> *Sent:* Wednesday, March 25, 2015 8:05 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [cinder]Driver broken
>>
>>
>>
>> Hi,
>>
>>
>>
>> Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
>>
>> Seems to be related to https://review.openstack.org/#/c/85847/ which
>> introduced another parameter to be passed to the driver, but our driver
>> didn't get updated so detach_volume fails for us.
>>
>>
>>
>> How can we get this fixed asap?
>>
>>
>>
>> Thanks,
>>
>> Eduard
>>
>>
>>
>> __
>> 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]Driver broken

[Eduard Matei]

Hi,

Indeed our CI runs, and it reported SUCCESS, but it didn't run the tempest
tests, only the openvstorage tests (my bad, looking into it as we speak).

Meanwhile i'll create a patch to fix this.

Thanks,
Eduard
__
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]Driver broken

[Walter A. Boring IV]

This is a real defect related to the multiattach patch that I worked 
on.   I have posted a fix for your driver.


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

Walt

Hi,

Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367
Seems to be related to https://review.openstack.org/#/c/85847/ which 
introduced another parameter to be passed to the driver, but our 
driver didn't get updated so detach_volume fails for us.


How can we get this fixed asap?

Thanks,
Eduard



__
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]Driver broken

[Eduard Matei]

Thanks,

Indeed, our CI doesn't test this code path, we focused mainly on our
internal functionality tests (which don't test for this), and the tempest
tests are not running.
This will be fixed asap.

Thanks everyone,
Eduard
__
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] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/02/2015 02:46 PM, Mike Perez wrote:
> Hello all,
> 
> I'm announcing my candidacy for Cinder PTL for the Liberty release.
> 
> I have contributed to block storage in OpenStack since Bexar back when things
> were within nova-volume, before Cinder, and the honor of serving as PTL for
> Cinder in the Kilo cycle.
> 
> I've spoke in the past about focused participation, something I still feel is
> needed in the projects that are the basic foundation of OpenStack. Compute,
> storage and networking need to be solid. My work as core in Cinder and
> continuing as PTL has involved a lot of evangelizing and making new
> contributors feel comfortable with becoming part of the team. As a project
> grows, communication needs to be excellent, coordination is key to making sure
> reviews don't stick around too long for contributors to feel discouraged.
> I think the Cinder team has done an excellent job in managing this as we grow,
> based on the feedback received. I really do think participation in Cinder
> is getting better, and it's wonderful to be part of that.
> 
> If we take the Kilo-3 milestone for example, we landed 44 blueprints in
> a single milestone [1]. That's huge progress. I would like to believe this
> happens because of focus, and that happens because of better tracking of what
> is a priority and clear communication. Lastly participation, not just core
> folks, but any contributor that feels welcomed by the team and not to be burnt
> out on never ending patch revisions.
> 
> Most of 2014 in Cinder was a lot of discussions on third party CI's. Third
> party CI's are a great way for vendors to verify if a proposed upstream patch
> would break their integration. In addition, it identifies if a vendor really
> does work with the current state of the OpenStack project. There have been
> plenty of cases that vendors discovered that their integration in OpenStack
> really didn't work until they ran these tests. Last year, there was a real 
> lack
> of coordination and communication with vendors on getting them on board with
> reporting third party CI results. In 2015 I took on the responsibility of 
> being
> the point of contact for the 70+ drivers in Cinder, emailing the mailing list,
> countless reminders on IRC, contacting maintainers directly, and actually
> making phone calls to companies if maintainers were not responsive by email.
> 
> I'm happy to report that majority of vendors have responded back and are 
> active
> in the Cinder community to ensure their integration is solid. Compare that to
> last year when we just had one or two vendors reporting and majority of 
> vendors
> not having a clue! It's very exciting to help build a better experience for
> their users using OpenStack. The communities pouring support to me on this
> issue was hugely appreciated, and is what keeps me coming back to help.
> 
> We added 14 new drivers to Cinder in the Kilo release. Coordination was
> beautiful thanks to clear communication and coordination with the hard working
> reviewers in the Cinder team.
> 
> My priorities for Cinder in the Kilo release was to make progress on rolling
> upgrades. I have spent a greater deal of my time testing the work to allow
> Cinder services to not be dependent on database schemas. This is a big change,
> and doesn't completely solve rolling upgrades in Cinder, but is a building
> block needed to begin solving the other rolling upgrade problems. I'm really
> happy with the work done by the team in the Kilo release and excited with how
> comfortable I feel in terms of stability of the work thanks to the amount of
> testing we've done.
> 
> This work however not only benefits Cinder, but is a general solution into
> Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are
> a huge problem that needs to be solved across OpenStack, and I'm proud of the
> Cinder team for helping do their part to help drive adoption. Long term I see
> this work contributing to an ideal single upgrade solution, so that operators
> aren't having to learn how to upgrade 12 different services they may deploy.
> 
> My plans for Liberty is to work with the team on creating a better use of
> milestones for appropriate changes. While we started some initial requirements
> like making new drivers focus on the first milestone only, I think stability
> time needs to be stretched a bit longer, and I think others will agree Kilo
> didn't have a lot of this as planned for Kilo-3.
> 
> Cinder  will continue on efforts for rolling upgrades by now focusing on
> compatibility across Cinder services with RPC. This is a very important piece
> for making rolling upgrades complete. We will continue to work through 
> projects
> like Oslo to make sure these solutions general enough to benefit other
> OpenStack projects, so as a whole, we will improve together.
> 
> Cinder volumes that end up in a stuck state. This has been a problem for ages,
> and I have heard from countless people at the O

[openstack-dev] [Cinder] ABCMeta driver porting

[Marc Koderer]

Dear cinder driver maintainers,

the abc driver porting bp got merged [1] and with this we need to refactor all
cinder driver classes slightly. I hope we will manage to deprecate the usage of
driver.VolumeDriver during Liberty.
The porting should be very trivial (~ 2 LOC) in the most cases (see [2]).

I would like to use this Etherpad to coordinate the work:

  https://etherpad.openstack.org/p/cinder-abc-driver-update

So, I need an assignee for each driver :)

Regards
Marc

[1]: https://review.openstack.org/#/c/177114/
[2]: https://review.openstack.org/#/c/138661/

—
Deutsche Telekom



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

[openstack-dev] [cinder] Liberty Midcycle Meetup

[Mike Perez]

Survey: https://www.surveymonkey.com/s/6QRKV6Z

This will determine, when, where and get a rough count.

We will review the results in the next Cinder Meeting [1], which is
2015-05-16 at 16:00 UTC on #openstack-meeting

[1] - https://wiki.openstack.org/wiki/CinderMeetings

--
Mike Perez

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

[openstack-dev] [cinder] Rebranded Volume Drivers

[Mike Perez]

There are a couple of cases [1][2] I'm seeing where new Cinder volume
drivers for Liberty are rebranding other volume drivers. This involves
inheriting off another volume driver's class(es) and providing some
config options to set the backend name, etc.

Two problems:

1) There is a thought of no CI [3] is needed, since you're using
another vendor's driver code which does have a CI.

2) IMO another way of satisfying a check mark of being OpenStack
supported and disappearing from the community.

What gain does OpenStack get from these kind of drivers?

Discuss.

[1] - https://review.openstack.org/#/c/187853/
[2] - https://review.openstack.org/#/c/187707/4
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers

--
Mike Perez

__
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