On 04/09/2012 05:14 PM, Ori Liel wrote:
The "Floating Disks" feature makes disks into stand-alone entities: a given
disk may be attached to a VM (as all disks are today), or it may be not attached to any
VM, which makes it a floating disk (http://www.ovirt.org/wiki/Features/FloatingDisk)
To
On 04/10/2012 04:46 PM, Ori Liel wrote:
I assume that a floating disk can be attached to 0 VMs as well, right?
So i would assume we get a top-level /disks collection correct?? And I
assume that collection would only list floating disks?
Indeed, there will be a root collection. but I do not se
On 04/11/2012 02:53 PM, Itamar Heim wrote:
Detach a disk from VM (becomes floating):
DELETE api/vms/{vm:id}/disks/{disk:id}
Delete a disk ('real' delete)"
DELETE api/disks/{disk:id}
Assuming this also works when the disk is attached to a VM then the
above seems to me like the simplest and cl
On 04/11/2012 11:02 AM, Eoghan Glynn wrote:
* Inconsistent with other flows. We do not normally update status
fields to perform actions. For example to run a VM, we do not update
it's status to 'activated', we run an action (start).
I think this point is the crux of the matter.
IMO the co
ssionManagement
Please review and comment.
Thank you,
Oved
--
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
Red Hat S.r.L. O: +39 095 916287
Via G. Fara 26 C: +39 348 1980079 (when in US: 415-623-0542)
Milan 20124, Ita
On 04/16/2012 10:04 AM, Miki Kenneth wrote:
I Agree on that, although I'm not sure whether it is really needed to
release the session, rather then rely on timeout.
If we indeed need to provide a way to release the session then I
agree this is the best alternative. But if we don't then it will
m
On 04/16/2012 01:03 PM, Yaniv Kaul wrote:
So (unless someone objects) let's go for option #2 (using the Prefer
header on each and every request, and release the session once it is
not there).
My only objection is that you implement a draft spec and implement a
header without even bothering to
E .../api/vms/{vm:id}/disks/{disk:id}/detach=> detach disk
Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using action.
No solution is perfect but we need to decide.
Thanks,
Ori.
--
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virt
On 04/16/2012 02:39 PM, Andrew Cathrow wrote:
Is there a 3rd option based on #1 where we just detach the disk rather than
detaching and deleting?
That could be further extended by adding an optional delete flag
This was discussed and the problem with that is that it's not backwards
compatib
On 04/16/2012 04:34 PM, Yaniv Kaul wrote:
The alternative to HTTP Prefer would be creating a new header (as i am
not aware of any other /approved/ header that fits the bill). This
requires writing an RFC and get it approved, which would take much
longer, and which would likely get the comment o
On 04/17/2012 02:27 PM, Ori Liel wrote:
My idea for that was to introducetrue|false as well.
Without force=true, we won't delete a disk if it's currently floating.
If the disk is floating it will only appear in root collection (...api/disks),
and DELETE from
there is non-ambiguous, as ther
Floating disks should be both in the root context, and also in the VM
context for each VM the floating disk is attached to, right? So floating
disks would appear 1+N_attach times in the API, once in the root
context, and once for each VM they are attached to.
IIUC a floating disk is not assoc
On 04/17/2012 04:53 PM, Ori Liel wrote:
iirc, shared disk is a flag on the disk to allow it to be shared.
doesn't mean it is shared yet, rather can be shared.
Right, but there's no contradiction: a disk can have 'shared' flag and
also show the list of VMs it's attached to. The flag tells you
On 04/17/2012 05:54 PM, Itamar Heim wrote:
If we can expose the "shared" flag though, i think the API gets more
natural. We can then only show the shared disks in the root context.
Itamar, can we expose this flag, or do you consider this flag is
internal to the BE?
we have to expose this fla
On 04/30/2012 02:43 PM, Dor Laor wrote:
I would go for 4 or 2
Current CPU topology for the hosts is a new commit, thus it may be
allowed to change it now since no one is using it yet. This works in
favour of 2. In any case only 3 discloses all the information in all
possible cases.
Thoughts?
On 04/30/2012 05:19 PM, Geert Jansen wrote:
If you touch any of this, please be prepared for the future:
- Use hyperthreads (exists in kvm today)
- Add numa topology for guest and the hosts
- Add Cache info (for VMs too)
- Add number of DIMMs, especially for VMs, for the upcoming memory hot
On 05/10/2012 03:28 PM, Einav Cohen wrote:
From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage
domain (e.g. "server:/dir1/dir2"), *or* to a path provided when creating a Local storage domain
(e.g. "/tmp/dir3"), meaning, without ":".
@Ay
On 05/10/2012 09:46 PM, Ayal Baron wrote:
device is what is being mounted and in the case of NFS is server:path
There is a reason why we termed it PosixFS and not SharedFS and that users can
specify local devices/FS's (and there is no reason to limit it).
Note that if user defines a local FS
Hi,
On 05/21/2012 12:34 PM, Einav Cohen wrote:
Please review the mock-up on the feature page:
http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience
Comments are welcome.
i was wondering why you have pulled out retrans and timeout? Are these
the most important ones?
Regards,
On 05/21/2012 12:44 PM, Einav Cohen wrote:
i was wondering why you have pulled out retrans and timeout? Are
these
the most important ones?
Sorry - not sure I got you. Can you please clarify your question?
Sorry, I meant, why do retrans and timeout have their own input boxes,
while the othe
from:
http://localhost:8080/api/capabilities
...
...
to:
http://localhost:8080/api/capabilities/xxx
...
(where xxx is a version number)
--
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
Red Hat S.r.L. O: +39 095 916287
On 05/29/2012 12:12 PM, Michael Pasternak wrote:
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version and some other metadata,
i.e it used by developers during the coding and it's not real system resource.
I'm
On 05/29/2012 03:44 PM, Michael Pasternak wrote:
On 05/29/2012 04:14 PM, Geert Jansen wrote:
On 05/29/2012 12:12 PM, Michael Pasternak wrote:
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version and some
On 05/30/2012 08:45 AM, Michael Pasternak wrote:
as about/currently/ non-version specific capabilities: should be
version specific as in new version
will be added new permits and same for the, can you remind
me what was the reasons for
making them such.
I don't know, you should ask Mark o
24 matches
Mail list logo
