Open Stack

On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen <jim at jimrollenhagen.com> wrote:
> On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote:
>> Hi All,

>> I would like to hear everyone's thoughts and probably reach a conclusion of
>> whether be open to include more criteria or not.
>
> I think these filters make sense. An operator may want to say "RAID all
> disks of this model"; that's completely reasonable.

It is?  Do you know any operators who have actually done that in
production?  I have never heard of it. In my experience, operators
only care about hard drive mfgr/model/firmware rev for actuarial
reasons, not when building and rebuilding arrays.  When it comes to
creating arrays and rebuilding them, what matters more is media type,
interface type and speed, size, slot#, and spindle speed.  More to the
point, the exact make/model/firmware rev of disks in the system will
change over its lifetime as drives fail and get replaced -- the
default drive replacement policy at Dell (and, I would expect, most
server vendors) is that you get a compatible replacement with the same
or better specs, and getting a drive of the same model from the same
manufacturer with the same firmware rev is not guaranteed -- if you
ask and if any are in stock, it might happen, but when I did support
most people just did not care as long as the replacement was there
within 4 hours.

Given that, deciding to build and manage arrays based on drive
mfgr/model/firmware is a lot less useful than deciding to build and
manage them based on interface type/media type/size/spindle
speed/slot#.

> We've already decided we want to implement the same filters for deciding
> which disk to put the root on[0], and so we'll need to write this code
> for most/all drivers anyway. We can simply re-use this code for the RAID
> use case.

Not really -- there is no expectation that the operating system can
see the mfgr/make/firmware of the physical disks that make up a
virtual disk.  What you see instead from the OS side is made up by the
RAID controller (and if you are lucky it will be the same value as
what you see from whatever you are using to manage the RAID array, but
there is no expectation that it works that way), and assuming it
reflects the physical disks making up the array is just wrong.  To
make things even more interesting, you cannot even assume that the
interface you will use to create the virtual disk will return a unique
identifier for that virtual disk that corresponds to anything you will
see on the OS side -- that is an issue that we are having to work
around for the RAID interfaces that the DRAC exposes.  Sad to say, the
only real thing you can count on for picking the right raid volume for
a root device knowing what size it should be (or) always creating the
virtual disk for the root array first, choosing /dev/sda and hoping
your RAID controller exposes devices in the order in which they were
created.

If you are not using RAID then using mfgr/model/firmware/serial#
composed together to make a unique identifier makes sense.  If you are
using RAID it does not because there is no expectation that
information is exposed to the OS at all.

> // jim
>
> [0] http://specs.openstack.org/openstack/ironic-specs/specs/kilo/root-device-hints.html
>
>>
>> Please pour in your thoughts on the thread
>>
>> Regards,
>> Ramakrishnan (irc: rameshg87)
>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev