ceph-disk pyudev implementation

ceph-disk pyudev implementation

[Chaitanya Huilgol]

Hi Loic,

As discussed in the multipath tracker, please find the port of ceph-disk which is based on pyudev (https://pyudev.readthedocs.org/en/latest/  python libudev binding)

Here is a short summary on the approach:
- Current ceph-disk determines various properties on block device by path string manipulations and /sys/dev properties
- These are difficult to implement and fragile for device types such as DM multipath.
- Since different code needs to be added based on the device type, a Block device class based approach has been used.
- Based on the device type supplied a block device object is instantiated (currently GenericBlockDev or DMBlockDev).
- Each class implements device specific functionality as an implementation of the abstract BlockDevBase base class.
        a. Get partition device from base device
        b. Get base device from partition
        c. Get Part UUID and Type
        d. Determine if device path is partition
        e. Determine if device is referenced
         f. Get HW sector size
        g. List partitions

In Prepare/Activate/List code paths, the required device object is instantiated and hence these code paths remain clean

This port also support multipath devices with the DMBlockDev Class.

https://github.com/chaitanyahuilgol/ceph-disk-udev.git

Let us know your thoughts.

Regards,
Chaitanya


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

Re: ceph-disk pyudev implementation

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

Hi,

The approach you describe makes sense to me. And you've done a nice job with the refactor.

I'm not familiar with pyudev though and other Ceph developers may already have an opinion (or answers). When adding new dependencies to Ceph, I think we need to assert how stable / reliable those dependencies are. How well tested do you think it is ? https://github.com/pyudev/pyudev/blob/master/Vagrantfile suggests there are tests with good coverage, https://github.com/pyudev/pyudev/pulls and https://github.com/pyudev/pyudev/issues?q=is%3Aopen+is%3Aissue have few open issues and a number of resolved ones. The timeline is a bit strange : a burst of recent commits and a large gap back to 2012. But maybe it's widely used and this really is not a concern ? 

Is there a particular reason why you did not re-use the json format for ceph-disk list ?

Could you make your new ceph-disk into a pull request so that it can run integration tests ?

Cheers

On 09/09/2015 08:52, Chaitanya Huilgol wrote:
> Hi Loic,
> 
> As discussed in the multipath tracker, please find the port of ceph-disk which is based on pyudev (https://pyudev.readthedocs.org/en/latest/  python libudev binding)
> 
> Here is a short summary on the approach:
> - Current ceph-disk determines various properties on block device by path string manipulations and /sys/dev properties
> - These are difficult to implement and fragile for device types such as DM multipath.
> - Since different code needs to be added based on the device type, a Block device class based approach has been used.
> - Based on the device type supplied a block device object is instantiated (currently GenericBlockDev or DMBlockDev).
> - Each class implements device specific functionality as an implementation of the abstract BlockDevBase base class.
>         a. Get partition device from base device
>         b. Get base device from partition
>         c. Get Part UUID and Type
>         d. Determine if device path is partition
>         e. Determine if device is referenced
>          f. Get HW sector size
>         g. List partitions
> 
> In Prepare/Activate/List code paths, the required device object is instantiated and hence these code paths remain clean
> 
> This port also support multipath devices with the DMBlockDev Class.
> 
> https://github.com/chaitanyahuilgol/ceph-disk-udev.git
> 
> Let us know your thoughts.
> 
> Regards,
> Chaitanya
> 
> 
> ________________________________
> 
> PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: ceph-disk pyudev implementation

[Chaitanya Huilgol]

Inline

> -----Original Message-----
> From: Loic Dachary [mailto:loic@dachary.org]
> Sent: Wednesday, September 09, 2015 1:05 PM
> To: Chaitanya Huilgol; Ceph Development
> Subject: Re: ceph-disk pyudev implementation
>
> Hi,
>
> The approach you describe makes sense to me. And you've done a nice job
> with the refactor.
>
> I'm not familiar with pyudev though and other Ceph developers may already
> have an opinion (or answers). When adding new dependencies to Ceph, I
> think we need to assert how stable / reliable those dependencies are. How
> well tested do you think it is ?
> https://github.com/pyudev/pyudev/blob/master/Vagrantfile suggests there
> are tests with good coverage, https://github.com/pyudev/pyudev/pulls and
> https://github.com/pyudev/pyudev/issues?q=is%3Aopen+is%3Aissue have
> few open issues and a number of resolved ones. The timeline is a bit strange
> : a burst of recent commits and a large gap back to 2012. But maybe it's
> widely used and this really is not a concern ?
>

Did not hit any pyudev issues in our tests, but cannot comment on the overall stability.
Almost all major distros package this and hence inferred that it must be stable enough.
However, there is no list of projects using this package in the project site, but lot of references and downloads https://crate.io/packages/pyudev/#history


> Is there a particular reason why you did not re-use the json format for ceph-
> disk list ?
>
Its ported from a slightly dated giant version, will add this when porting to master

> Could you make your new ceph-disk into a pull request so that it can run
> integration tests ?

Yes, will merge it with master and send out a pull request after tests.

>
> Cheers
>
> On 09/09/2015 08:52, Chaitanya Huilgol wrote:
> > Hi Loic,
> >
> > As discussed in the multipath tracker, please find the port of ceph-disk
> which is based on pyudev (https://pyudev.readthedocs.org/en/latest/
> python libudev binding)
> >
> > Here is a short summary on the approach:
> > - Current ceph-disk determines various properties on block device by path
> string manipulations and /sys/dev properties
> > - These are difficult to implement and fragile for device types such as DM
> multipath.
> > - Since different code needs to be added based on the device type, a Block
> device class based approach has been used.
> > - Based on the device type supplied a block device object is instantiated
> (currently GenericBlockDev or DMBlockDev).
> > - Each class implements device specific functionality as an implementation
> of the abstract BlockDevBase base class.
> >         a. Get partition device from base device
> >         b. Get base device from partition
> >         c. Get Part UUID and Type
> >         d. Determine if device path is partition
> >         e. Determine if device is referenced
> >          f. Get HW sector size
> >         g. List partitions
> >
> > In Prepare/Activate/List code paths, the required device object is
> instantiated and hence these code paths remain clean
> >
> > This port also support multipath devices with the DMBlockDev Class.
> >
> > https://github.com/chaitanyahuilgol/ceph-disk-udev.git
> >
> > Let us know your thoughts.
> >
> > Regards,
> > Chaitanya
> >
> >
> > ________________________________
> >
> > PLEASE NOTE: The information contained in this electronic mail message is
> intended only for the use of the designated recipient(s) named above. If the
> reader of this message is not the intended recipient, you are hereby notified
> that you have received this message in error and that any review,
> dissemination, distribution, or copying of this message is strictly prohibited. If
> you have received this communication in error, please notify the sender by
> telephone or e-mail (as shown above) immediately and destroy any and all
> copies of this message in your possession (whether hard copies or
> electronically stored copies).
> >
>
> --
> Loïc Dachary, Artisan Logiciel Libre


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

Re: ceph-disk pyudev implementation

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 5486 bytes --]

Inline as well

On 09/09/2015 12:37, Chaitanya Huilgol wrote:
> Inline
> 
>> -----Original Message-----
>> From: Loic Dachary [mailto:loic@dachary.org]
>> Sent: Wednesday, September 09, 2015 1:05 PM
>> To: Chaitanya Huilgol; Ceph Development
>> Subject: Re: ceph-disk pyudev implementation
>>
>> Hi,
>>
>> The approach you describe makes sense to me. And you've done a nice job
>> with the refactor.
>>
>> I'm not familiar with pyudev though and other Ceph developers may already
>> have an opinion (or answers). When adding new dependencies to Ceph, I
>> think we need to assert how stable / reliable those dependencies are. How
>> well tested do you think it is ?
>> https://github.com/pyudev/pyudev/blob/master/Vagrantfile suggests there
>> are tests with good coverage, https://github.com/pyudev/pyudev/pulls and
>> https://github.com/pyudev/pyudev/issues?q=is%3Aopen+is%3Aissue have
>> few open issues and a number of resolved ones. The timeline is a bit strange
>> : a burst of recent commits and a large gap back to 2012. But maybe it's
>> widely used and this really is not a concern ?
>>
> 
> Did not hit any pyudev issues in our tests, but cannot comment on the overall stability.
> Almost all major distros package this and hence inferred that it must be stable enough.
> However, there is no list of projects using this package in the project site, but lot of references and downloads https://crate.io/packages/pyudev/#history
> 

On Ubuntu 14.04 there is one package depending on pyudev.

loic@fold:~$ apt-cache rdepends python-pyudev
python-pyudev
Reverse Depends:
  solaar

> 
>> Is there a particular reason why you did not re-use the json format for ceph-
>> disk list ?
>>
> Its ported from a slightly dated giant version, will add this when porting to master

Ha, cool.

>> Could you make your new ceph-disk into a pull request so that it can run
>> integration tests ?
> 
> Yes, will merge it with master and send out a pull request after tests.

I suggest you create the pull request even before testing anything. Such a large refactor is easier to handle with baby steps. I think we will end up splitting your pull request in a series of smaller pull request that can gradually be integrated in the existing code base.

It's very exciting to go in this direction and I look forward to a better codebase for ceph-disk :-)

Cheers

>>
>> Cheers
>>
>> On 09/09/2015 08:52, Chaitanya Huilgol wrote:
>>> Hi Loic,
>>>
>>> As discussed in the multipath tracker, please find the port of ceph-disk
>> which is based on pyudev (https://pyudev.readthedocs.org/en/latest/
>> python libudev binding)
>>>
>>> Here is a short summary on the approach:
>>> - Current ceph-disk determines various properties on block device by path
>> string manipulations and /sys/dev properties
>>> - These are difficult to implement and fragile for device types such as DM
>> multipath.
>>> - Since different code needs to be added based on the device type, a Block
>> device class based approach has been used.
>>> - Based on the device type supplied a block device object is instantiated
>> (currently GenericBlockDev or DMBlockDev).
>>> - Each class implements device specific functionality as an implementation
>> of the abstract BlockDevBase base class.
>>>         a. Get partition device from base device
>>>         b. Get base device from partition
>>>         c. Get Part UUID and Type
>>>         d. Determine if device path is partition
>>>         e. Determine if device is referenced
>>>          f. Get HW sector size
>>>         g. List partitions
>>>
>>> In Prepare/Activate/List code paths, the required device object is
>> instantiated and hence these code paths remain clean
>>>
>>> This port also support multipath devices with the DMBlockDev Class.
>>>
>>> https://github.com/chaitanyahuilgol/ceph-disk-udev.git
>>>
>>> Let us know your thoughts.
>>>
>>> Regards,
>>> Chaitanya
>>>
>>>
>>> ________________________________
>>>
>>> PLEASE NOTE: The information contained in this electronic mail message is
>> intended only for the use of the designated recipient(s) named above. If the
>> reader of this message is not the intended recipient, you are hereby notified
>> that you have received this message in error and that any review,
>> dissemination, distribution, or copying of this message is strictly prohibited. If
>> you have received this communication in error, please notify the sender by
>> telephone or e-mail (as shown above) immediately and destroy any and all
>> copies of this message in your possession (whether hard copies or
>> electronically stored copies).
>>>
>>
>> --
>> Loïc Dachary, Artisan Logiciel Libre
> 
> 
> ________________________________
> 
> PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]