Open Stack

On Thu, Sep 5, 2013 at 4:58 PM, John-Paul Robinson <jpr at uab.edu> wrote:

>  Are there any recommendations on where in OS that patch/extension would
> live.
>
> I've managed to get familiar with the OS external interfaces but don't
> have much understanding on how things are structured internally.
>
> Given the motivation for moving Cinder out of Nova due to the complexity
> of the intertwined Nova compute and volume functionality, would this make
> such a patch a bit more complicated?
>
> Were you suggesting that the patch/extension would simply focus on bumping
> the db volume size or is there a more formal extension interface that would
> keep all parts happy (e.g. the account API)?
>
> Thanks,
>
> ~jpr
>
>
> On 09/05/2013 05:36 PM, John Griffith wrote:
>
> In the scenario we are developing, we'd like to instantiate and track
>> volumes via nova-volume so we can benefit from the OS accounting API's
>> to track storage usage over time.  We'd also like to be able to grow
>> these volumes in place to add space for a user's block device and grow
>> the file system in that container to consume the newly added space.
>>
>> Is there a way to update the recognized size of the volume in OS?
>>
>
> Currently the only solution for what you describe would be to update the
> size in the db directly.  That being said you would be much better off
> writing your own custom patch/extension to do this for you in side of
> OpenStack to avoid some of the impedance mismatches that you're likely to
> encounter here.
>
>
>  So what I was suggesting is that you'd add something custom of your own
in api/contrib, and you would use that to call out to ceph to do your
resize, as well as call in to the database and modify the volume size when
succesful.  There are details that you'd need to think about here such as
quotas etc.

As far as being on nova-volume still, that does make things slightly more
difficult IMO, however for what you're talking about you don't need to
worry about things like ec2 ID mappings etc so I think it would be ok.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130905/dabb6864/attachment.html>