openstack/cinder-specs
Code Issues Proposed changes
de4308f4a7
cinder-specs/specs/liberty/extract-brick.rst
Ivan Kolodyazhny fa11db5278 Remove hardcoded releases list from unit tests 
test_titles had hardcoded releases list and 'liberty' folder was out of
scope for this test.

Also all specs were changed to fit template and pass tests.

Change-Id: Ib4c6cbb96a9f9c96dd54cff3b92a35c35df72fff
2015-10-05 23:31:43 +03:00

4.0 KiB
Raw Blame History

Extract Brick library from Cinder

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/cinder/+spec/extract-brick

This Specification talks about 2 points. First the extraction of the brick/cinder directory into it's own standalone library. Second, changing cinder to use the external library.

Problem description

The idea of 'brick' was created back in the Havana timeframe. All along it was meant to be a standalone library that Cinder, Nova and any other project in OpenStack could use. Currently brick lives in a directory inside of Cinder, which means that only Cinder can use it.

Use Cases

Use the same library code both in Nova and Cinder.

Proposed change

We want to extract the brick directory and encapsulate it into it's own pypi library that any python project can use.

So we need to do:

  • First create a separate python project and release it into pypi
  • Add brick to cinder's requirements.txt
  • Remove the existing cinder/brick directory
  • Everywhere in Cinder that uses cinder/brick will need to be modified to use the new pypi library.

Alternatives

We could simply keep brick inside of Cinder and not share it's code. The problem with this is that any changes/fixes to brick will then need to be backported into the same code in Nova. This is the existing problem.

Data model impact

This doesn't change the data model for Cinder.

REST API impact

None

Security impact

Any security related issues that impact brick may impact anything in Cinder that would use the new library. Brick will be placed into stackforge for code reviews, so anyone can contribute fixes.

Notifications impact

None

Other end user impact

None

Performance Impact

There should be no performance impact, as the same code will exist in the pypi brick library as it does today in Cinder. The import will pull the library from a system installed location instead of the cinder codebase.

Other deployer impact

Brick will be a requirement for Cinder. So whoever builds distribution packages for cinder will also need to ensure that brick gets installed.

Developer impact

Currently, any Cinder developer can add new features and fix bugs in brick as part of the Cinder project. Going forward, developers will need to clone the source of brick from stackforge and make their changes there.

The downside to this is that If there are new features, APIs or interface changes in the brick library, a release will have to be published in order for Cinder to get those changes.

Implementation

Assignee(s)

Primary assignee:

Walter A. Boring IV - walter-boring

Other contributors:

e0ne

Work Items

I have already started the work of creating a standalone brick library here: https://github.com/hemna/cinder-brick

  • This repo will need to be registered into stackforge, so brick can benefit from the community process and gerrit.
  • Once in stackforge, an official release needs to be made so that the package exists in pypi.
  • Then a patch to Cinder can be made to add it to the requirements.txt
  • The another patch to follow that removes brick/cinder and adjusts all of Cinder to use the new library.

Dependencies

None

Testing

All of the existing unit tests in cinder for brick can remain to ensure that it works as advertised. The existing Cinder brick unit tests will be migrated to the new project and run there as well.

Documentation Impact

None.

References