Open Stack

On Tue, 14 May 2013, Robert Collins wrote:

> On 14 May 2013 09:44, Devananda van der Veen <devananda.vdv at gmail.com> wrote:
>
> > Any hardware which doesn't support mounting virtual media and exposing it to
> > the guest -- this is, afaict, not part of the IPMI specification, though
> > most large hw vendors have implemented it anyway.
> >
> > Also, this approach would be unsuitable for high-density compute where many
> > SOCs share a single management board, even if that BMC supports virtual
> > media, since this would serialize the deployment process.
> >
> >  (caveat: I'm assuming that HDC systems whose BMC support virtual media
> > would only support mounting a small number of, or just one, virtual media at
> > a time. I base this assumption on the knowledge that some HDC systems have a
> > limitation to the number of concurrent SOL sessions, which is considerably
> > lower than the number of SOCs they contain.)
>
> We could put the config 'drive' in as a partition, like we do swap
> (though I want to delete the swap code: it's not our business to
> fiddle with that).

Yeah, I clearly did not explain myself correctly.  I 100% agree to "no
fiddling".  Instead, I suggested that the to-be-installed image should be
configured with a partition table, and that partition table should be
either DOS or GPT.  If DOS, it would contain one partition of id '99' (or
some agreed upon number, and a vfat filesystem on it).  The "installer"
would recognize that partition to be the place to write data to.  If
you're concerned about false positives, we can also add that the partition
must have a file inside it named "PLACE_CFG_DRIVE_DATA_HERE.txt" (which
probably ends up as PLACE~1.TXT, but you get the picture :).

For GPT, you can I think actually put a label on the partition (in addtion
to the filesystem label).

Secondly, we could specify that the installer may also opt to *not* write
the data there, but rather on any other partition in a disk attached to
the system.  That would allow a bare metal installer that could manipulate
block volumes "behind the scenes" to
a.) fast clone a source image and attach
b.) create / populate the config drive and attach.

with fancy SAN or other controllers that "install" could literally then be
tenths of a second, and doesn't ever have to boot anything.