On Mon, Jul 26, 2010 at 02:01:26PM +0200, Andrew Beekhof wrote:
On Wed, Jul 14, 2010 at 2:58 PM, Darryl L. Pierce
<dpierce(a)redhat.com> wrote:
> On Wed, Jul 14, 2010 at 01:17:26PM +0200, Andrew Beekhof wrote:
>> Not sure about this.
>> You don't think it will create confusion if half of the network
>> related API calls are in one place and the other half in another?
>>
>> What's the motivation? Security domains perhaps?
>
> I'm looking at it from a parent/child relationship. To create a new
> logical network interface, such as a bridge, what is the most intuitive
> way to go about the process? To me it seems that you would create it on
> the host, and then configure it once the device "exists". So, from that
> perspective, only the create API for network devices will exist at the
> host level.
I think it makes more sense to group API calls by their functional
area rather than which object they would be performed on in our
backend.
One doesn't use the "ip link" command to create an IP address for
example, even though thats what you're operating on.
The problem I see is that you'd have to get a reference to NetworkDevice
in order to create a logical device that might not even be related to
that device at all. I agree that grouping is best: in this case I tend
to look at creating a new logical device (such as a bridged network
device) as being a host-level operation rather than a NetworkDevice
operation.
> And, at that, I think we drop the list_network_devices API. With
QMF I
> think it's fairly trivial to ask the broker "give me all NetworkDevice
> agents for this Host agent".
Out of interest, what would that look like?
I'm not sure offhand. I can look into it and post an example.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/