Hi Livnat,
On Thu, 2010-10-07 at 17:19 +0200, Livnat Peer wrote:
Hi Mark,
inline -
On 10/07/2010 11:23 AM, Mark McLoughlin wrote:
> Hey,
>
> I've posted some thoughts on how we should model import/export
> functionality here:
>
>
https://fedorahosted.org/rhevm-api/ticket/28
>
> VMs and templates can be imported/exported from/to an 'export' storage
domain.
>
> We need to do the following:
>
> 1. Add an "export" action under<vm/> and<template/>.
The
> destination export domain is implied because a data center can
> only have a single export domain. We'd have an
> collapse_snapshots parameter. Probably makes sense to make
> force_override the default since a client can query for an
> existing VM before exporting if it wants to avoid overwriting.
> 2. Support adding a pre-configured storage domain since a common
> case is to add an existing export storage domain and import
> VMs/templates from there.
> 3. Get rid of the storage domain attachment concept and just model
> it as a collection of storage domains under a data center. See
> #82
>
#82:
"...where as the status under the top-level storagedomains collection
refers to the datacenter-independent status "
when you write 'datacenter-independent status' do you mean the status of
the storage domain that combines all the statuses of the domain in the
different DCs? ( like we have today in the UI under the storage general
grid)
Yep.
If so, it can be helpful to detail for each domain it's status
for each
data center without the need to iterate over the DCs and review them one
by one.
There are many, many optimizations like this we can add to the API -
e.g. including in a cluster representation details of all the networks
attached, rather than just a URI for the collection of attached networks
- but we're holding off on adding things like this for now
Basically, for now, so long as some information is reasonably possible
with the API, we're reluctant to add an shortcut. We should add
shortcuts eventually, but only after we've thought globally about what
shortcuts make most sense.
There is no actual meaning for the status of the domain without the
context of a DC. The reason we added this "combined" status was to give
the user the ability to get the system status in a glance, but if there
is a problem the user can't tell from this status where is the problem
unless he has the details mentioned above.
Okay, so you think we should remove the context-less storage domain
status?
I think that's a good idea; it is fairly confusing
> 4. Add vms and templates collections under each storage
domain. In
> the case of data storage domains, these will be list the VMs or
> templates storage in the storage domain. In the case of export
> storage domains, they will list import candidates. DELETE will
> be supported by these collections, but not POST.
> 5. Add an import action on VMs or templates import candidates.
> Parameters include the destination storage domain and the
> destination cluster.
>
>
Why do we need destination cluster for import action?
Good question. I only put it in there because I think it's a required
parameter for the powershell command. Any ideas why that is?
Thanks,
Mark.