On Tue, 2007-07-10 at 03:49 +0100, Daniel P. Berrange wrote:
> On Mon, Jul 09, 2007 at 03:43:42PM -0700, David Lutterkort wrote:
> > On Thu, 2007-06-28 at 23:59 +0100, Daniel P. Berrange wrote:
> >
> > > So <storage> is a single top level grouping for multiple <disk> elements,
> > > while <machine> and <network> are multiple top level elements with no
> > > grouping.
> > >
> > > For consistentency perhaps we should either
> > >
> > > - Kill <storage> and have <disk> at top level
> > >
> > > Or
> > >
> > > - Add <machines> and <networks> for grouping the multiple machine
> > > and network elements.
> >
> > I don't follow this - yes, in the abstract it makes sense; but when I
> > look at an actual image.xml, having the storage element there seems to
> > make the XML clearer. I'd change it if that is seen as the crucial issue
> > keeping these patches from being committed. Otherwise, I'd prefer
> > leaving <storage> as it is.
>
> I actually agree that having the storage element for grouping the invidual
> disks makes it a little clearer. What about the alternative of having a
> grouping element for <network> and <machine> too ?
Since the degenerate case (one machine/domain) will be the most common
one, those wrappers would only add unnecessary typing (as the storage
tag does, but we agree it increases readability)
So I am a little hesitant to add those grouping tags. The main reason to
add them would be if we needed to express something that applies to all
machines/networks ... and I can't think of any.
The bigger issue I am struggling with is how to express features. I
think the way the metadata does that currently stinks. From a virt-image
pov, all features are tri-state, since for running an image either (a)
the feature must be present (b) must not be present or (c) doesn't
matter. So the user needs to be able to express two sets of features,
those in (a) and those in (b).
For suppressing ACPI and enabling PAE, for example, that could be
written as
<features>
<noacpi/>
<pae/>
</feature>
Kinda silly since we'll need for each feature X a tag X and a tag noX;
or we could write
<features>
<acpi state="disabled"/>
<pae state="enabled"/>
</features>
or finally
<features>
<disabled><acpi/></disabled>
<enabled><pae/></enabled>
</features>
I like the second and third option; for the third option though, I am
not even sure we should have an 'acpi' tag ... that could just be text
content (<disable>acpi</disable>) I'll mull over this some tomorrow.
Besides markup fun, of course, there's the question of how to detect
that ACPI can be turned off; virt-install currently assumes that that
can be done for all fv guests. Ultimately, that info should come from
libvirt's capabilities.
David
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
