|
xen-devel
Re: [Xen-devel] Xen Management API Draft, version 0.4
On Fri, 2006-07-07 at 15:31 +0100, Ewan Mellor wrote:
> That said, I don't think that that approach is suitable here. Every one of
> these use cases that we are using to drive the dynamic model has the
> additional caveat that the system must be permanently monitorable. In other
> words, this API isn't just for _doing_ things, it's for watching what's going
> on, too. This means that you need access to every field that we've exposed,
> all the time.
No. I absolutely disagree. Monitoring the system is just another
use-case and you need to consider what needs to be monitored and how it
is exposed and this should be a stable, versioned part of the API that
status reporting tools can depend on.
In general, it simply doesn't make sense to monitor some things in some
states and the API should reflect that.
Debugging the system is something else and should have a separate
interface that gives you arbitrary access (but isn't versioned or
guaranteed stable).
>
> Furthermore, this approach implies that it's possible to enumerate all your
> use cases. This is all very well within a program, when you can add a new
> method to an object when it becomes necessary, but this API doesn't have that
> luxury -- it must be possible to support arbitrary and unanticipated use cases
> without coming back and forcing additional methods upon the API. This means
> that all the fields must be available directly and through the API.
Again, I disagree.
You aren't going to get it right first time whatever you do. Exposing
everything R/O isn't going to help that, it's just going to make it
harder to maintain backwards compatibility when you want to change
something.
Exposing unnecessary stuff R/W is even more dangerous because it allows
your clients to break your dynamic model. Which is going to make it
impossible to support the system.
If you want to be able to support Xen, the dynamic model should be such
that it is impossible for your clients to break you. If that means that
it is impossible to support a use case with the API and it's necessary
to add a feature to the API and do another version. That's fine because
you can do it in a controlled supportable way.
The alternative is that to support unforseen use-cases all the different
proprietary management tools start messing with your bits in ill defined
undocumented ways that you don't know about and when you want to add a
new feature to Xen you can't change anything for fear of breaking the
world.
Having said this, it might be that you've already thought quite
carefully about what you want to expose and monitor and your current API
may be quite well thought out anyway. I'm just arguing the principle of
exposing everything by default. I'm not arguing in the context of how
that has actually fallen out in the specific cases you have documented.
Harry.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home