Inline as well On 09/09/2015 12:37, Chaitanya Huilgol wrote: > Inline > >> -----Original Message----- >> From: Loic Dachary [mailto:l...@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
signature.asc
Description: OpenPGP digital signature
