Hi Geert,
On Mon, 2010-09-13 at 16:00 +0200, Geert Jansen wrote:
Hi,
currently we have
GET /datacenters/xxx
200 OK
<data_center>
...
</data_center>
versus
GET /hosts/xxx
200 OK
<host>
</host>
i.e. there's an inconsistency between the resource types and the URLs
here (datacenter vs data_center).
No, it's just our URI style:
http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide#URL_Style
URLs should be alllowercasewithnopunctuation e.g.
http://foo.com/dublintours/guinnessstorehouse/
with the exception of query parameters which should be lower_case:
http://foo.com/dublintours/guinnessstorehouse/?start_date=today
Another type of (apparent) inconsistency is this:
GET /hosts/xxx/nics/yyy
200 OK
<host_nic>
...
</host_nic>
Well, we have a <nic> element which describes VM nics and this (IMHO) is
a very different concept from host NICs, so I felt it was useful to have
a distinct XML tag
i.e. <host_nic> can contain:
- id/href/name/description
- reference to logical network
- reference to the host
- MAC address, IP address/subnet/gateway and VLAN ID
- a list of bonded slaves or, in the case of a bond, a reference to
the master
whereas a VM <nic> can contain:
- id/href/name/description
- reference to the logical network
- reference to the VM
- the device type (e.g. virtio versus e1000)
- MAC address and IP address/subnet/gateway
I don't feel very strongly about it, though - perhaps there's enough
overlap here to merge the too
But it isn't really
<host_nic> wasn't a way of expressing a relationship, it was a way of
distinguishing two different concepts which go by the same name
if you make a distinction between two types of
sub-collections:
i. "Existentially dependent" subcollections. This is relationship with a
cardinality of 1...1 - 0...n. The resources in the sub-collection cannot
exist without the parent resource. An example is the NIC of a host.
ii. "Linked" subcollections. This is a relationship with a cardinality
of 0...1 (or 0...n) - 0...m, i.e. both exist indepdendent of each other.
For example, a cluster and its hosts.
The terminology doesn't do much for me, but yeah - they are two
different types of associations
More simply - moving a host between clusters makes sense as a concept,
but it doesn't make sense to talk about moving a NIC between hosts
My feeling is that for i. you need to qualify the resource type of
the
subcollection because it can't exist by itself. So e.g. "host_nic" or
"hostnic". While for ii. there is no need for qualification as there
presumably is another top-level collection that maps all the resources.
No, I think <nic> works fine to describe a host NIC except for the fact
that we already have VM NICs
(And again, it's not a cut-and-dry thing ... we could decide the
concepts aren't all that different and we can use <nic> for both)
Elaborating on ii, this would also introduce a protocol to query
linked
objects, e.g. "GET /clusters/xxx/hosts" and "GET
/datacenters/xxx/clusters". I'd go just one level deep. If you want to
get all VMs in a datacenter, that's two queries.
Yeah, I think it probably makes sense to add these eventually, but they
are just short-cuts for the API user - the information *is* already
modelled by the API
I guess it's an extension of:
https://fedorahosted.org/rhevm-api/ticket/12
What has stopped us from doing this before now is that a) it's an
optimization and b) there's the potential for dramatically increasing
the number of collections and complicating the API
If you guys like this, then the "attachments" in
datacenters could be
changed by a subcollection "storagedomains" for a datacenter. Right now
you're using an association resource "attachment" which is a bit ugly in
my view. Association resources are a necessary evil when the association
itself has attributes, but that's not the case here. In this case i feel
they are just a complication.
Yeah, we came to that conclusion recently too - attachments is a failed
experiment
I thought I'd filed a trac ticket on that already, but I must have
forgotten. Added now:
https://fedorahosted.org/rhevm-api/ticket/82
Cheers,
Mark.