Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
For reference, most of our kickstart scripts for storage bricks go by size. The little disks are system disks to be assembled into a software raid. The big ones are raid arrays to be preserved. Kickstart's ability to let you run a shell script on the host to build the partitioning instructions that kickstart uses is a very handy feature. Thanks, Kevin From: Victor Lowther [victor.lowt...@gmail.com] Sent: Thursday, January 22, 2015 1:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell tim.b...@cern.ch wrote: -Original Message- From: Victor Lowther [mailto:victor.lowt...@gmail.com] Sent: 21 January 2015 21:06 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: ... 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#. +1 - How about using the /dev/disk/by-path information which says to install the system onto the disks by their device location. Have a look at how kickstart does it. It's the same problem so we don't need to re-invent the wheel. I am aware of how kickstart detects disks and how we can pass information about which disk to install on, and that is only tangentially related to what I am talking about. What I have been talking about is how to decide which physical disks attached to a hardware RAID controller should be used to create a RAID volume, and the relative usefulness of the properties of the physical disks in doing so. My contention is that drive mfgr/model/firmware is not used in practice to make that decision -- other factors, such as disk size, spindle speed, media type, and interface type are what are used in a production setting. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
On Thu, Jan 22, 2015 at 1:44 AM, Tim Bell tim.b...@cern.ch wrote: -Original Message- From: Victor Lowther [mailto:victor.lowt...@gmail.com] Sent: 21 January 2015 21:06 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: ... 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#. +1 - How about using the /dev/disk/by-path information which says to install the system onto the disks by their device location. Have a look at how kickstart does it. It's the same problem so we don't need to re-invent the wheel. I am aware of how kickstart detects disks and how we can pass information about which disk to install on, and that is only tangentially related to what I am talking about. What I have been talking about is how to decide which physical disks attached to a hardware RAID controller should be used to create a RAID volume, and the relative usefulness of the properties of the physical disks in doing so. My contention is that drive mfgr/model/firmware is not used in practice to make that decision -- other factors, such as disk size, spindle speed, media type, and interface type are what are used in a production setting. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen j...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
-Original Message- From: Victor Lowther [mailto:victor.lowt...@gmail.com] Sent: 21 January 2015 21:06 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints On Tue, Jan 20, 2015 at 8:36 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: ... 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#. +1 - How about using the /dev/disk/by-path information which says to install the system onto the disks by their device location. Have a look at how kickstart does it. It's the same problem so we don't need to re-invent the wheel. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] RAID interface - backing disk hints
Hi All, This is regarding the RAID configuration spec that was posted for review some time back: https://review.openstack.org/#/c/135899/ This review consists of a generic RAID interface currently proposed jointly by Redhat (for DRAC hardware) and HP (for iLO hardware). This spec defines a common interface for doing RAID configuration which can be used for both drivers for now, and may be followed by any driver later on who wishes to implement RAID configuration. In the changes proposed in the spec, the driver should be able to figure out the disks to be used for creating RAID on the machine, when some hints are given by the operator to Ironic. The hints help Ironic to figure out what disks should be used for creating RAID. Initially we started with a few (namely disk type (ssd vs hdd) and interface type (scsi vs sata vs ...), etc. But later on due to request from some other folks to include some more criterias (namely filter disks based on inputs on model, firmware version, vendor due to various reasons), we added it to the list of hints. Now, we have * some set of folks *who don't want *model, firmware version, vendor as criteria because if they are added, every driver would need to implement them. * some set of folks *who want *model, firmware version, vendor as criteria because there are practical use-cases in an environment. We have confirmed that filtering based on model, firmware version and vendor can be done on both HP and DRAC hardware for now. I would like to hear everyone's thoughts and probably reach a conclusion of whether be open to include more criteria or not. Please pour in your thoughts on the thread Regards, Ramakrishnan (irc: rameshg87) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: Hi All, This is regarding the RAID configuration spec that was posted for review some time back: https://review.openstack.org/#/c/135899/ This review consists of a generic RAID interface currently proposed jointly by Redhat (for DRAC hardware) and HP (for iLO hardware). This spec defines a common interface for doing RAID configuration which can be used for both drivers for now, and may be followed by any driver later on who wishes to implement RAID configuration. In the changes proposed in the spec, the driver should be able to figure out the disks to be used for creating RAID on the machine, when some hints are given by the operator to Ironic. The hints help Ironic to figure out what disks should be used for creating RAID. Initially we started with a few (namely disk type (ssd vs hdd) and interface type (scsi vs sata vs ...), etc. But later on due to request from some other folks to include some more criterias (namely filter disks based on inputs on model, firmware version, vendor due to various reasons), we added it to the list of hints. Now, we have * some set of folks *who don't want *model, firmware version, vendor as criteria because if they are added, every driver would need to implement them. * some set of folks *who want *model, firmware version, vendor as criteria because there are practical use-cases in an environment. We have confirmed that filtering based on model, firmware version and vendor can be done on both HP and DRAC hardware for now. 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. 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. // 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
