<div dir="ltr">Dear Sean,<div><br></div><div>Great compilation, this will help for sure!!</div><div>Thank you!!</div><div><br></div><div>Best Regards,</div><div>Sheel Rana</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 6, 2016 at 10:38 PM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At the Design Summit in Austin, the Cinder team met over three days<br>
to go over a variety of topics. This is a general summary of the<br>
notes captured from each session.<br>
<br>
We were also able to record most sessions. Please see the<br>
openstack-cinder YouTube channel for all its minute and tedious<br>
glory:<br>
<br>
<a href="https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ" rel="noreferrer" target="_blank">https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ</a><br>
<br>
Replication Next Steps<br>
======================<br>
Replication v2.1 was added in Mitaka. This was a first step in supporting<br>
a simplified use case. A few drivers were able to implement support for<br>
this in Mitaka, with a few already in the queue for support in Newton.<br>
<br>
There is a desire to add the ability to replicate smaller groups of volumes<br>
and control them individually for failover, failback, etc. Eventually we<br>
would also want to expose this functionality to non-admin users. This will<br>
allow tenants to group their volumes by application workload or other user<br>
specific constraint and give them control over managing that workload.<br>
<br>
It was agreed that it is too soon to expose this at this point. We would<br>
first like to get broader vendor support for the current replication<br>
capabilities before we add anything more. We also want to improve the admin<br>
experience with handling full site failover. As it is today, there is a lot<br>
of manual work that the admin would need to do to be able to fully recover<br>
from a failover. There are ways we can make this experience better. So before<br>
we add additional things on top of replication, we want to make sure what<br>
we have is solid and at least slightly polished.<br>
<br>
Personally, I would like to see some work done with Nova or some third party<br>
entity like Smaug or other projects to be able to coordinate activities on<br>
the compute and storage sides in order to fail over an environment completely<br>
from a primary to secondary location.<br>
<br>
Related to the group replication (tiramisu) work was the idea of generic<br>
volume groups. Some sort of grouping mechanism would be required to tie in<br>
to that. We have a grouping today with consistency groups, but that has its<br>
own set of semantics and expectations that doesn't always fully mesh with<br>
what users would want for group replication.<br>
<br>
There have also been others looking at using consistency groups to enable<br>
vendor specific functionality not quite inline with the intent of what<br>
CGs are meant for.<br>
<br>
We plan on creating a new concept of a group that has a set of possible types.<br>
One of these types will be consistency, with the goal that internally we can<br>
shift things around to convert our current CG concept to be a group of type<br>
consistency while still keeping the API interface that users are used to for<br>
working with them.<br>
<br>
But beyond that we will be able to add things like a "replication" type that<br>
will allow users to group volumes, that may or not be able to be snapped in<br>
a IO order consistent manner, but that can be acted on as a group to be<br>
replicated. We can also expand this group type to other concepts moving<br>
forward to meet other use cases without needing to introduce a wholly new<br>
concept. The mechanisms for managing groups will already be in place and a new<br>
type will be able to be added using existing plumbing.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-replication" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-replication</a><br>
<br>
Active/Active High Availability<br>
===============================<br>
Work continues on HA. Gorka gave an overview of the work completed so far and<br>
the work left to do. We are still on the plan proposed at the Tokyo Summit,<br>
just a lot of work to get it all implemented. The biggest variations are around<br>
the host name used for the "clustered" service nodes and the idea that we will<br>
not attempt to do any sort of automatic cleanup for in-progress work that gets<br>
orphaned due to a node failure.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-activeactiveha" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-activeactiveha</a><br>
<br>
Mitaka Recap<br>
============<br>
Two sessions were devoted to going over what had changed in Mitaka. There were<br>
a lot of things introduced that developers and code reviewers now need to be<br>
aware of, so we wanted to spend some time educating everyone on these things.<br>
<br>
Conditional DB Updates<br>
----------------------<br>
To try to eliminate races (partly related to the HA work) we will now use<br>
conditional updates. This will eliminate the gap between checking a value in<br>
setting it, making it one atomic DB update. Better performance than locking<br>
around operations.<br>
<br>
Microversions<br>
-------------<br>
API microversions was implemented in Mitaka. The new /v3 endpoint should be<br>
used. Any change in the API should now be implemented as a micrversion bump.<br>
Devref in Cinder with details of how to use this and more detail as to when<br>
a microversion is needed and when it is not.<br>
<br>
Rolling Upgrades<br>
----------------<br>
Devref added for rolling upgrades and versioned objects. Discussed need to make<br>
incremental DB changes rather than all in one release. First release add new<br>
colume - write to both, read from original. Second release - write to both,<br>
read from new column. Third release - original column can now be deleted.<br>
<br>
Recommended service upgrade order: cinder-api, cinder-scheduler, cinder-volume,<br>
cinder-backup. After all services upgraded, send SIGHUP to each to release<br>
version pins.<br>
<br>
Multinode grenade tests need to be set up to get regular testing on rolling<br>
upgrades to ensure we don't let anything through that will cause problems.<br>
<br>
Some additional patches are in progress to fix a few internal things like<br>
unversioned dicts that are passed around. This will help us make sure we don't<br>
change one of those structures in an incompatible way.<br>
<br>
Etherpads:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-mitakarecap" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-mitakarecap</a><br>
<a href="https://etherpad.openstack.org/p/cinder-newton-rollingupgrades" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-rollingupgrades</a><br>
<br>
Scalable Backup<br>
===============<br>
The backup service was decoupled from the c-vol service in Mitaka. This allows<br>
us to move backup to other nodes to offload that work. We can also scale out<br>
to allow more backup operations to work in parallel.<br>
<br>
Also some discussion of whether KVMs change block tracking could be used to<br>
further optimize this process.<br>
<br>
Some other issues were identified with backup. It is currently a sequential<br>
process, so backups can take a long time. Some work is being done to break out<br>
the backup chunks into separate processes to allow concurrent processing.<br>
<br>
The idea of having different backup types was brought up. This will require<br>
more discussion. The idea is to have a way to configure different volumes to<br>
be able to be backed up to different backup target types (i.e., one to Swift<br>
backend, one to Ceph backend, one to GCS, etc.).<br>
<br>
There are some implications for the HA work being done and how to do clean up.<br>
Those issues will need to be fully identified and worked through.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-scalablebackup" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-scalablebackup</a><br>
<br>
Testing Process<br>
===============<br>
We discussed our various available testing and how we can get better test<br>
coverage. We also want to optimize the testing process so everyone isn't stuck<br>
running long running tests just to validate small changes.<br>
<br>
For unit tests, tests that take more than 3-5 seconds to run will be moved out<br>
to our integration tests. Most of these are doing more than just "unit" testing<br>
so makes more sense for them to be separated out.<br>
<br>
There's some desire to gate on coverage, but it was discussed how that can be<br>
a difficult thing to enforce. There was a lot of concern that a hard policy<br>
around coverage would lead to a lot of useless unit tests that don't really add<br>
valuable testing, just adds coverage over a given path to get the numbers up.<br>
<br>
It may be nice to have something like our non-voting pylint jobs to help<br>
detect when our test coverage decreases, but not sure if the additional infra<br>
load to run this would be worth it.<br>
<br>
We have a functional test job that is currently non-voting. It has been broken<br>
recently and due to it being non-voting it was missed for some time. This needs<br>
to be fixed and the job changed to be voting. Since the majority of these tests<br>
were moved from the unit tests, they should be fine to make voting once passing<br>
again.<br>
<br>
Having in-tree tempest tests were also discussed. We've used tempest for<br>
testing things not in line with the mission of tempest. We also have tests in<br>
there that may not really be relevant or needed for other projects getting<br>
them by running all tempest tests. For the ones that are really Cinder specific<br>
we should migrate them from being in tempest to being in tree with Cinder. That<br>
also gives us full control over what is included.<br>
<br>
We also discussed plans for how to test API microversions and adding pylint<br>
testing to os-brick.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-testingprocess" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-testingprocess</a><br>
<br>
CinderClient and OpenStackClient<br>
================================<br>
A group of folks are working through a list of commands to make sure osc has<br>
functional parity with cinderclient. We need to have the same level of support<br>
in osc before we can even consider deprecating the cinder client CLI.<br>
<br>
The idea was raised to create a wiki page giving a "lookup" of cinder client<br>
commands to openstackclient commands to help users migrate over to the new<br>
client. Will need to decided how to support this given long term plans for the<br>
wiki, but having the lookup posted somewhere should help.<br>
<br>
We do have an extra challenge in that we added a cinderclient extension for<br>
working with os-brick as a stand alone storage management tool. We will work<br>
with the osc team to see what the options are for supporting something like<br>
this and decide what the best end user experience would be for this. It may be<br>
that we don't deprecate python-cinderclient CLI just for this use case.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-cinderclienttoosc" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-cinderclienttoosc</a><br>
<br>
Unconference<br>
============<br>
Made midcycle plans based on survey results. (Has since changed since we ran in<br>
to complications with hotal availability)<br>
<br>
Talked breifly about non-Cinder volume replication and how to recover during<br>
DR. Discussed whether all backends support managing existing volumes. How to<br>
discover available volumes. What to do with snapshots on manage.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-unconference" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-unconference</a><br>
<br>
Nova Cross Project<br>
==================<br>
All about multiattach. Matt Riedman wrote up a nice recap of this discussion<br>
already:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/094018.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/094018.html</a><br>
<br>
Contributors Meetup<br>
===================<br>
API capability and feature discovery.<br>
What to do for backends that only support allocation in units greater than 1G.<br>
Next steps for user message reporting.<br>
Release priorities:<br>
 - User messaging<br>
 - Active/Active HA<br>
 - Improved functional test coverage<br>
 - Better support for cheesecake (repl v2.1)<br>
Extending attached volume.<br>
Discussed qemu-img convert error a couple drivers were seeing.<br>
FICON protocol support.<br>
Generic group discussion.<br>
Force detach.<br>
Replication questions.<br>
QoS support for IOPs per GB.<br>
Per tenant QoS.<br>
Cinder callbacks to Nova for task completion.<br>
Config options inheritance (defined in Default, apply to subsections)<br>
Deadlines (<a href="http://releases.openstack.org/newton/schedule.html" rel="noreferrer" target="_blank">http://releases.openstack.org/newton/schedule.html</a>)<br>
Status of image caching.<br>
Driver interface compliance checks and interface documentation.<br>
<br>
Etherpad:<br>
<a href="https://etherpad.openstack.org/p/cinder-newton-contributorsmeetup" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-newton-contributorsmeetup</a><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>