Date: Wed, 03 Jun 2009 12:58:53 -0400
From: Michael DeHaan <mdehaan(a)redhat.com>
Subject: Re: Storage provisioning with cobbler
Christopher Dale wrote:
> > Can you give me a full step-by-step list of what (some new, some
> > existing, some imaginary) cobbler commands you would want to run to use
> > this feature and what
> > commands they would be running underneath (vendor tools and otherwise)
> > for each of those commands.
>
> > I think that may serve as a good starting point.
>
> > Then others can take a look and see if their conceptions differ.
>
> > --Michael
>
> So, mostly imaginary, but seems to me that it would be a reasonable
> projection of the goals of the cobbler effort...
>
> today, if a storage administrator has configured your SAN to your
> spec, you would just need to give the elements names (kind of like the
> cobbler network add)
>
> cobbler storage (or whatever noun seems to fit) add --name= --vendor=
> --class-of-service= --unit=(meaningful alias for WWN1, meaningful
> alias for WWN2, etc.)
>
> in the future, providing that there is an API that exposes the
> administrative functions of the SANs / storage device
>
> cobbler storage define (and whatever set of flags that would be
> necessary to inform cobbler how to interact with the device to
> provision, deprovision, migrate or replicate)
>
"cobbler storage add" seems more consistent with what we have, how is
define different from add above?
Define is different in that it tells cobbler how to speak to the hardware.
So if I first define the storage and the storage-access method, then I can
'cobbler storage add' based on less technically specific terms. As an
example:
cobbler storage define --name=lab2-3par --vendor=3par --model=inserv-t-class
--management-ip=192.168.0.100
Provides me what I need to know to access their management API and what
language to speak. (I have a preliminary request for info to my 3PAR guy and
a conference call with my HP guys on Friday)
cobbler storage-access define --name=b48000 --brocade --model=48000
--management-ip=192.168.0.110
Provides me what I need to know to access their management API (as above,
there needs to be an API or CLI that can be used)
So, with the storage container and storage-access 'defined'...
cobbler storage add --name=OracleData --storage-class=oracle-database-data
--storage-size=200G --hosts=dbg01,dbg02,dbg03,dbg04
cobbler storage add --name=OracleFlash --storage-class=oracle-database-flash
--storage-size=400G --hosts=dbg01,dbg02,dbg03,dbg04
When the cobbler storage add is issued, cobbler would format the request and
send it to the appropriate interface. The SAN would complete the commands,
preferably synchronously so that errors could be reported (like no more
space).
Overtime, the storage-class could include a long list of elements where SAN
best practices are implemented when the storage is created for a system. I
think that this should be imbedded so that individuals who don't speak SAN
aren't overwhelmed. So, in the above example, I would want my
oracle-database-data class to indicate that I want small LUNs on high speed
FC drives and the oracle-database-flash would be on large LUNs on SATA
drives. The point being, best practices could be invoked by someone who
doesn't have a clue about the best practices for a particular use.
With this information, cobbler could call the SAN API to create the LUN(s)
and call the Brocade to create the zones.
cobbler system add --name=dbg01 --network=oranet --network=cluster-comm
--storage=OracleData --storage=OracleFlash --ks=11g.ks --ksmeta="node=01
grid=dbg grid-size=4"
> cobbler network add (looks like this one is already in the works)
>
> maybe a future, providing that there are APIs that exposes the
> administrative functions of the networking components
>
> cobbler network define (and whatever set of flags that would be
> necessary to inform cobbler how to interact with the device to
> provision, secure, meter and whatever else you can do with the equipment)
>
> cobbler storage-access (or whatever noun seems to fit) add --name=
> --type=(FC|iSCSI|whatever) --vendor= --groups=
>
> maybe a future
> cobbler storage-acccess define (as with the networking switch)
I think I was looking for a more fleshed out example above, with
everything filled in and no --foo=blank :)
Also explaining what each step did under the covers, to the letter, and
when it did them.
Did the above get closer this time?
>
> Vendor tools and otherwise: Really skint on this one. I don't think
> anything tangible exists. But, it has been my experience that if you
> get one vendor to come to the party and it is successful, then they
> all want to come to the party. Does anyone out there know about tools
> that could provide a homogenized interface to various pieces of
equipment?
>
I'm not expecting that we /could/ find a homogenized tool, but rather
that we'd have to abstract out differences until one would exist.
Cobbler is /all/ glue around other services and apps that don't work
well together -- the point being to make them do that.
Understood.
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
------------------------------
Date: Wed, 3 Jun 2009 13:46:00 -0400
From: Owen.Mann(a)interactivedata.com
Subject: Re: Storage provisioning with cobbler
> > Can you give me a full step-by-step list of what (some new, some
> > existing, some imaginary) cobbler commands you would want to run to
use
> > this feature and what
> > commands they would be running underneath (vendor tools and otherwise)
> > for each of those commands.
>
> > I think that may serve as a good starting point.
>
> > Then others can take a look and see if their conceptions differ.
>
> > --Michael
>
> So, mostly imaginary, but seems to me that it would be a reasonable
projection of the goals of the cobbler effort...
>
> today, if a storage administrator has configured your SAN to your spec,
you would just need to give the elements names (kind of like the cobbler
network add)
>
> cobbler storage (or whatever noun seems to fit) add --name= --vendor=
--class-of-service= --unit=(meaningful alias for WWN1, meaningful alias
for WWN2, etc.)
>
> in the future, providing that there is an API that exposes the
administrative functions of the SANs / storage device
>
> cobbler storage define (and whatever set of flags that would be
necessary to inform cobbler how to interact with the device to provision,
deprovision, migrate or replicate)
>
> cobbler network add (looks like this one is already in the works)
>
> maybe a future, providing that there are APIs that exposes the
administrative functions of the networking components
>
> cobbler network define (and whatever set of flags that would be
necessary to inform cobbler how to interact with the device to provision,
secure, meter and whatever else you can do with the equipment)
>
> cobbler storage-access (or whatever noun seems to fit) add --name=
--type=(FC|iSCSI|whatever) --vendor= --groups=
>
> maybe a future
> cobbler storage-acccess define (as with the networking switch)
>
> Vendor tools and otherwise: Really skint on this one. I don't think
anything tangible exists. But, it has been my experience that if you get
one vendor to come to the party and it is successful, then they all want
to come to the party. Does anyone out there know about tools that could
provide a homogenized interface to various pieces of
equipment?_______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
The IBM CLI tool for our XIV is called "xcli" and it's somewhat documented
here:
http://www.redbooks.ibm.com/redpieces/abstracts/sg247659.html
Example to create a pool (page 101, section 5.3.2):
xcli -c Redbook pool_create pool=DBPool size=1000 snapshot_size=0
Example to create a volume (page 112, section 5.4.2):
xcli -c Redbook vol_create vol=DBVolume size=2000 pool=DBPool
Example to create a host (page 121, section 5.5.2):
xcli -c Redbook host_define host=Windows_Server1
Example to define a port (page 122, section 5.5.2):
xcli -c Redbook host_add_port host=Server1 fcaddress=10000000C92CFD36
Example to map a volume to a host (page 122, section 5.5.2):
xcli -c Redbook map_vol host=Server1 vol=DBvol1 lun=1 ovverride=yes
I hope this gives some information on how at least one SAN vendoer does
it. I'm told that our Cisco SAN switches do not have a remote API - it's
all done on the CLI locally, but this could be incorrect.
Maybe the simplest proof of concept case could be identified and kluge
scripts could show the concept without the cobbler glue to begin with. So,
if a script that added a specific set of data to the SAN and a script that
created an FC zone (or an iSCSI thing) could be demonstrated, things may
seem more tangible. Or it would be realized that it is not doable at
present.
Thanks again
Christopher (irc: Commoner)