John Levon at 2009-2-26 0:03 wrote: > On Wed, Feb 25, 2009 at 10:15:40AM -0500, James Carlson wrote: > > >> Cecilia Hu writes: >> >>> So, before, a virt-install command line can look like: >>> #virt-install ...--mac a:b:c:d:e:f --bridge bge0 --rate 100M/s \ >>> --mac g:h:i:j:k:l --bridge bge1 --rate 200M/s... >>> Now, it looks like: >>> #virt-install ...--network mac=a:b:c:d:e:f,bridge=bge0,rate=100M/s \ >>> --network mac=g:h:i:j:k:l,bridge=bge1,rate=200M/s... >>> >> This seems a bit odd to me. If I read this correctly, the underlying >> problem is that the current parameters have positional significance, >> and this makes them harder to understand as a grouping. (In other >> words, you have to specify "--mac" first, and then can specify >> "--bridge" after.) >> >> But why add "--rate" to the mess? The existing command line doesn't >> support rate, and it seems that you're trying to mark the old usage as >> "Obsolete," so why not just drop "--rate" and force anyone who wants >> to set the bandwidth limit to use the new command format? >> > > In discussion with Max, this was in fact the plan, this is perhaps not > clear in the case. There will be no --rate option (I'm sure Max will > confirm). > Exactly. There will be no --rate option for virt-install(1M). Users will be forced to use this new syntax, if they want to set bandwidth to the virtual interface. I listed '--rate' to show the mess we can have, if we take that approach. This is just for people to understand why we take this effort to make the new style. Sorry for any confusion. > >>> | new -w/--network syntax and | | | >>> | 'rate' property of | | | >>> | virt-install(1M) | volatile | | >>> >> "Volatile" means that scripts can't safely use this new option. Is >> that intended? >> > > There's some historical confusion around virt-install. It is intended to > be usable from scripts. My forthcoming case says this: > > usr/bin/virt-install Committed > usr/bin/virt-install cmdline Committed > usr/bin/virt-install output Not-an-interface > > This reflects upstream intention, as well as how we've actually used it. > So, 'committed' makes more sense since it'll be 'committed' later anyway :). > >>> | "networkresource" and "rate" | | | >>> | elements in XML | | | >>> | configuration file | Uncommitted | | >>> >> Why do users mess with the XML file? That's what "Uncommitted" >> implies. I would have expected "Committed Private" instead. >> > > The XML is also an external standard and is therefore Committed. In many > cases it's the only way to interrogate the domain config sadly. > Although it is not necessary, user can also manually create a XML file to describe the configuration for a virtual interface and pass that file to virsh to add the interface to the domU.
Since we'll push the change to upstream later, these XML elements will become part of the standard format in the future eventually. So, 'committed' level is more appropriate in this case. Thanks, Max > regards > john >
