From: Loic Dachary <loic@dachary.org>
To: Chaitanya Huilgol <Chaitanya.Huilgol@sandisk.com>,
Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: ceph-disk pyudev implementation
Date: Wed, 09 Sep 2015 09:35:05 +0200 [thread overview]
Message-ID: <55EFE129.8030502@dachary.org> (raw)
In-Reply-To: <9E914F5BD7F48A4782456CEB550A422824EC8564@SACMBXIP02.sdcorp.global.sandisk.com>
[-- 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 --]
next prev parent reply other threads:[~2015-09-09 7:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 6:52 ceph-disk pyudev implementation Chaitanya Huilgol
2015-09-09 7:35 ` Loic Dachary [this message]
2015-09-09 10:37 ` Chaitanya Huilgol
2015-09-09 11:03 ` Loic Dachary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EFE129.8030502@dachary.org \
--to=loic@dachary.org \
--cc=Chaitanya.Huilgol@sandisk.com \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.