Re: [ovirt-devel] 3.5.1 RC schedule [was Re: [ovirt-users] oVirt Weekly Sync Meeting: Dec. 10, 2014]
On Thu, Dec 11, 2014 at 08:36:46AM +0100, Sandro Bonazzola wrote: Il 10/12/2014 16:54, Brian Proffitt ha scritto: (On time this week!) = #ovirt: oVirt Weekly Sync = [cut] * 3.5.z updates Two blockers have postponed RC again. New RC date will be discussed and decided in mailing list. (bkp, 15:30:01) [cut] Let's start the discussion and decision task. We have an ETA on the last pending blocker for 3.5.1 on next week. I suggest to postpone RC and GA after winter holidays. What about: RC - 2015-01-07 GA - 2015-01-14 Can we have a vdsm respin before that? We get repeated reports of bugs that are already solved in the stable branch. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Wednesday, December 10, 2014 4:59:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/10, Nir Soffer wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: devel@ovirt.org Cc: Oved Ourfali ov...@redhat.com, infra in...@ovirt.org Sent: Wednesday, December 10, 2014 10:40:47 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, December 10, 2014 8:30:30 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: devel@ovirt.org Sent: Tuesday, December 9, 2014 7:02:44 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org Sent: Tuesday, December 9, 2014 3:40:30 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Tuesday, December 9, 2014 3:21:43 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 09/12/14 13:47, Oved Ourfali wrote: safe up to 95% or so. You just made up that number. I don't really understand why you would want to downgrade your code quality by circumventing tests. Maybe someone can elaborate on this a bit? It doesn't downgrade the code quality. It is just a way to ensure developers can both merge changes, and do it as safely as possible without relying on post-submit tools. The number is indeed invented... as I don't have real statistics, but it comes to say that it would be safe most of the time. After the patch is merged, if CI will fail, it is the responsibility of the developer to check that out and fix that. This thread was started to avoid getting to that point, as getting a failed patch inside the code means breaking all the other tests that run on top of it and that blocks all the development, not only that specific patch. The issue that started the discussion was an issue in which there was a Tests -1 flag, and it was ignored. My suggestion will enforce that it won't be ignored. In more rare cases, in which the rebase is the source of the tests issue, then you'll find about it later. I started the discussion, and I started it because a developer complained about not being able to merge a patch because it was failing the tests due to an already merged patch that was making all the builds to fail. And was trying to get a solution to avoid getting to that point where a patch is merged while breaking the tests. So in summary, you are suggestion this: Creating a new flag 'tested' with values +1, 0 and -1 that only jenkins and managers can set Block form submitting any patches that have a -1 Carry the value of that flag to following patches only if the flag was -1 +1, we need a way to block bad patches from being merged, even with a rebase in gerrit. going forward we're planning a few changes to the way jenkins jobs are run on ovirt ci, which will help reduce noise and imrove resources usages. 1. moving into a flow process, where critical jobs like unit tests/checkstyle will run first and only then other heavy jobs will run (integration/rpms/findbugs) This is already implemented in vdsm for few months - running make check will run the fast tests first and will not run the slower tests if a fast test failed. Please change to be able to run only fast tests or only slow tests, that way we can separate the job into two and give feedback about the fast tests before the slows have finished running. These are the available targets (from faster to slower): - gitignore - check that certain files are ignored - pyflakes - check common Python errors (e.g. unused imports) - pep8 - style check - check - run the fast checks
[ovirt-devel] where vm obeject be deleted from vmContainer when shutdown
Hi, Guys
I am studying ovirt, and now I am checking how vdsm manage VM.
But now I have a trouble about the process shutdown VM.
I know that when start up a VM, a vm object will be added to the
vmContainer.
And I think the vm object will be deleted from vmContainer when
shutdown/poweroff since
the code will check whether the vm object exist in vmContainer when
start up VM.
-
# cat vdsm/API.py
def create(self, vmParams):
Start up a virtual machine.
:param vmParams: required and optional VM parameters.
:type vmParams: dict
vmParams['vmId'] = self._UUID
try:
if vmParams.get('vmId') in self._cif.vmContainer:
self.log.warning('vm %s already exists' % vmParams['vmId'])
return errCode['exist']
... snip ...
-
I found the vm object will be deleted from vmContainer when poweroff.
but I did not find where vm obeject be deleted from vmContainer when
shutdown.
Does someone can help me?
-
# cat vdsm/virt/vm.py
def destroy(self):
self.log.debug('destroy Called')
response = self.doDestroy()
if response['status']['code']:
return response
# Clean VM from the system
self.deleteVm()
... snip ...
def deleteVm(self):
Clean VM from the system
try:
del self.cif.vmContainer[self.conf['vmId']]
self.log.debug(Total desktops after destroy of %s is %d,
self.conf['vmId'], len(self.cif.vmContainer))
except Exception:
self.log.error(Failed to delete VM %s, self.conf['vmId'],
exc_info=True)
... snip ...
-
Regards,
Jian
--
--
Zhang Jian
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8526
FUJITSU INTERNAL: 7998-8526
FAX: +86+25-83317685
MAIL: zhangjian2...@cn.fujitsu.com
--
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Thursday, December 11, 2014 12:06:24 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/11, Nir Soffer wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Wednesday, December 10, 2014 4:59:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/10, Nir Soffer wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: devel@ovirt.org Cc: Oved Ourfali ov...@redhat.com, infra in...@ovirt.org Sent: Wednesday, December 10, 2014 10:40:47 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, December 10, 2014 8:30:30 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: devel@ovirt.org Sent: Tuesday, December 9, 2014 7:02:44 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org Sent: Tuesday, December 9, 2014 3:40:30 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Tuesday, December 9, 2014 3:21:43 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 09/12/14 13:47, Oved Ourfali wrote: safe up to 95% or so. You just made up that number. I don't really understand why you would want to downgrade your code quality by circumventing tests. Maybe someone can elaborate on this a bit? It doesn't downgrade the code quality. It is just a way to ensure developers can both merge changes, and do it as safely as possible without relying on post-submit tools. The number is indeed invented... as I don't have real statistics, but it comes to say that it would be safe most of the time. After the patch is merged, if CI will fail, it is the responsibility of the developer to check that out and fix that. This thread was started to avoid getting to that point, as getting a failed patch inside the code means breaking all the other tests that run on top of it and that blocks all the development, not only that specific patch. The issue that started the discussion was an issue in which there was a Tests -1 flag, and it was ignored. My suggestion will enforce that it won't be ignored. In more rare cases, in which the rebase is the source of the tests issue, then you'll find about it later. I started the discussion, and I started it because a developer complained about not being able to merge a patch because it was failing the tests due to an already merged patch that was making all the builds to fail. And was trying to get a solution to avoid getting to that point where a patch is merged while breaking the tests. So in summary, you are suggestion this: Creating a new flag 'tested' with values +1, 0 and -1 that only jenkins and managers can set Block form submitting any patches that have a -1 Carry the value of that flag to following patches only if the flag was -1 +1, we need a way to block bad patches from being merged, even with a rebase in gerrit. going forward we're planning a few changes to the way jenkins jobs are run on ovirt ci, which will help reduce noise and imrove resources usages. 1. moving into a flow process, where critical jobs like unit tests/checkstyle
Re: [ovirt-devel] Creating a new gerrit flag
On 12/11, Nir Soffer wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Thursday, December 11, 2014 12:06:24 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/11, Nir Soffer wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Wednesday, December 10, 2014 4:59:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/10, Nir Soffer wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: devel@ovirt.org Cc: Oved Ourfali ov...@redhat.com, infra in...@ovirt.org Sent: Wednesday, December 10, 2014 10:40:47 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, December 10, 2014 8:30:30 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: devel@ovirt.org Sent: Tuesday, December 9, 2014 7:02:44 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org Sent: Tuesday, December 9, 2014 3:40:30 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Tuesday, December 9, 2014 3:21:43 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 09/12/14 13:47, Oved Ourfali wrote: safe up to 95% or so. You just made up that number. I don't really understand why you would want to downgrade your code quality by circumventing tests. Maybe someone can elaborate on this a bit? It doesn't downgrade the code quality. It is just a way to ensure developers can both merge changes, and do it as safely as possible without relying on post-submit tools. The number is indeed invented... as I don't have real statistics, but it comes to say that it would be safe most of the time. After the patch is merged, if CI will fail, it is the responsibility of the developer to check that out and fix that. This thread was started to avoid getting to that point, as getting a failed patch inside the code means breaking all the other tests that run on top of it and that blocks all the development, not only that specific patch. The issue that started the discussion was an issue in which there was a Tests -1 flag, and it was ignored. My suggestion will enforce that it won't be ignored. In more rare cases, in which the rebase is the source of the tests issue, then you'll find about it later. I started the discussion, and I started it because a developer complained about not being able to merge a patch because it was failing the tests due to an already merged patch that was making all the builds to fail. And was trying to get a solution to avoid getting to that point where a patch is merged while breaking the tests. So in summary, you are suggestion this: Creating a new flag 'tested' with values +1, 0 and -1 that only jenkins and managers can set Block form submitting any patches that have a -1 Carry the value of that flag to following patches only if the flag was -1 +1, we need a way to block bad patches from being merged, even with a rebase in gerrit. going forward we're planning a few changes to the way jenkins jobs are
Re: [ovirt-devel] where vm obeject be deleted from vmContainer when shutdown
Hi, - Original Message - From: zhangjian2011 zhangjian2...@cn.fujitsu.com To: devel@ovirt.org Sent: Thursday, December 11, 2014 10:58:22 AM Subject: [ovirt-devel] where vm obeject be deleted from vmContainer when shutdown Hi, Guys I am studying ovirt, and now I am checking how vdsm manage VM. But now I have a trouble about the process shutdown VM. I know that when start up a VM, a vm object will be added to the vmContainer. And I think the vm object will be deleted from vmContainer when shutdown/poweroff since the code will check whether the vm object exist in vmContainer when start up VM. There is one caveat. When The VM is powered off for whatever reason, will be still kept in Down status, to let the oVirt Engine collect the data and make informed decision about how to do next. How to do next could be just report to the user or spawn a new VM instance elsewhere, or maybe something else. Up to Engine. Once Engine collected the data, it sends 'destroy' to VDSM, which must now drop the remainings of the VM and free the entry from vmContainer. Bests, -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org, Dan Kenigsberg dan...@redhat.com Sent: Thursday, December 11, 2014 1:22:01 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/11, Nir Soffer wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Thursday, December 11, 2014 12:06:24 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/11, Nir Soffer wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Eyal Edri ee...@redhat.com, Oved Ourfali ov...@redhat.com, infra in...@ovirt.org, devel@ovirt.org Sent: Wednesday, December 10, 2014 4:59:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/10, Nir Soffer wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: devel@ovirt.org Cc: Oved Ourfali ov...@redhat.com, infra in...@ovirt.org Sent: Wednesday, December 10, 2014 10:40:47 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: Oved Ourfali ov...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, December 10, 2014 8:30:30 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: devel@ovirt.org Sent: Tuesday, December 9, 2014 7:02:44 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: David Caro dcaro...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org Sent: Tuesday, December 9, 2014 3:40:30 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 12/09, Oved Ourfali wrote: - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Tuesday, December 9, 2014 3:21:43 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag On 09/12/14 13:47, Oved Ourfali wrote: safe up to 95% or so. You just made up that number. I don't really understand why you would want to downgrade your code quality by circumventing tests. Maybe someone can elaborate on this a bit? It doesn't downgrade the code quality. It is just a way to ensure developers can both merge changes, and do it as safely as possible without relying on post-submit tools. The number is indeed invented... as I don't have real statistics, but it comes to say that it would be safe most of the time. After the patch is merged, if CI will fail, it is the responsibility of the developer to check that out and fix that. This thread was started to avoid getting to that point, as getting a failed patch inside the code means breaking all the other tests that run on top of it and that blocks all the development, not only that specific patch. The issue that started the discussion was an issue in which there was a Tests -1 flag, and it was ignored. My suggestion will enforce that it won't be ignored. In more rare cases, in which the rebase is the source of the tests issue, then you'll find about it later. I started the discussion, and I started it because a developer complained about not being able to merge a patch because it was failing the tests due to an already merged patch that was making all the builds to fail. And was trying to get a solution to avoid getting to that point where a patch is merged while breaking the tests. So in
Re: [ovirt-devel] Really slow VDSM on F21
Hey Petr, I have just ran a few functional tests on my laptop after upgrading it to F21. Both 'service vdsmd stop sudo service vdsmd start' and 'systemctl vdsmd restart' return fast and succeed. Also, running the entire networkTest suite takes about 628 sec which is reasonable compared to F20 on the same laptop. I think that hints in the direction of the Jenkins instance is a VM. Ido - Original Message - From: Petr Horacek phora...@redhat.com To: devel@ovirt.org, Francesco Romani from...@redhat.com Sent: Wednesday, December 3, 2014 11:09:03 AM Subject: Re: [ovirt-devel] Really slow VDSM on F21 Cc: Dan. - Original Message - From: Petr Horacek phora...@redhat.com To: devel@ovirt.org, Francesco Romani from...@redhat.com Sent: Tuesday, 2 December, 2014 12:39:58 PM Subject: Really slow VDSM on F21 Hello, has anyone else noticed VDSM's problems on Fedora 21? The problem is that when I start vdsmd via systemd, it takes about a minute to start the listener (returning Connection to 0.0.0.0:54321 refused) and next few minutes it returns 'Recovering from crash or Initializing'. After that, `getVdsCaps` takes cca 20 secs to finish. I tried to change niceness in vdsmd.service but it's still the same. When I start vdsm directly (/usr/share/vdsm/vdsm as vdsm user) it starts within a second as it should. Have you an idea why this happens? Best regards, Petr ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
Hi Juan,
Incorporated the review comments.
Kindly have a look and let us know if everything looks well and good.
Thanks and Regards,
Shubhendu
Thanks for making the changes. I have some additional comments:
1. URL segments shouldn't have underscores. For example, you are
proposing URLs like this:
/clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
The last component should be volumesnapshots, without the underscore.
Note that on the other hand XML element should have underscores, like in
volume_snapshots, that is correct.
2. Try to avoid abbreviations. For example, instead of whatever_params
use whatever_parameters, and instead of scheduling_det use
scheduling_details, use cron_expression instead of cronexpr, so on.
3. If possible the action to delete a snapshot shouldn't receive any
parameters, not even an empty action/ element.
4. The schedulesnapshot action should be modeled using REST style, not
an action. My understanding is that you plan to have for each volume a
set of rules that define when the snapshots will be created. This should
be implemented as a sub-collection of the volume, so that these rules
can be queried, added, modified and deleted:
To query:
GET ...{volume:id}/snapshotrules
snapshot_rules
snapshot_rule id=... href=...
crontab_expression.../crontab_expression
/snapshot_rule
...
/snapshot_rules
To add:
POST ...{volume:id{/snapshotrules
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To modify:
PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To delete (note that there is no body):
DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
If there will be only one of these rules per volume then you can model
them as attributes of the volume itself, without the sub-collection.
5. The snapshotconfigs should be modeled as an attribute of the
volume, not as an action.
On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
Thanks Juan for the comments. I would update the wiki accordingly and send
for confirmation.
Regards
Shubhendu
Sent from Samsung Mobile
Original message
From: Juan Hernández jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael
Pasternak mpast...@redhat.com
Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
Hi Juan/Michael,
This is a gentle reminder for the review of the REST api design for the
below feature.
We would be starting the REST development for the same soon (probably by
Dec 2014 end).
If there are specific comments, please pass it on. If no comments we
would go ahead with the current design and implement accordingly.
Request your time for this.
Thanks and Regards,
Shubhendu
On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
Hi All,
Please help us to review the design of Gluster Volume Snapshots in oVirt,
Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/GlusterVolumeSnapshots
Detailed Design
http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
We target it in ovirt 3.6 release.
Marked Juan/Michael specifically for REST review.
Best Regards,
Shubhendu Tripathi
My comments about the RESTAPI:
1. You can't use the snapshot and snapshots XML elements, as those
are already in use for disk snapshots, and we don't have name space
support in the RESTAPI. You will have to use something different, for
example gluster_volume_snapshots and gluster_volume_snapshot.
2. When adding a volume snapshot the name of the volume shouldn't be a
parameter, as that is implicit. Only the name and description of the
snapshot should be provided.
3. The operation to delete a snapshot should be performed on the
snapshot resource, not on the collection:
DELETE
/clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
Ideally this operation shouldn't receive any parameters (thus no body).
If it does require parameters then they should be contained inside an
action element.
4. The operation to update the snapshot configuration should be the PUT
operation of the volume, not a new snapshotconfig sub-resource, as
these kind of sub-resources aren't well supported by the SDKs and the CLI.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Really slow VDSM on F21
Hello Ido, thanks for your response! I installed the latest Fedora 21 Server on a VM, builded VDSM's master branch and now it works as it should :) Petr - Original Message - From: Ido Barkan ibar...@redhat.com To: Petr Horacek phora...@redhat.com Cc: devel@ovirt.org, Francesco Romani from...@redhat.com Sent: Thursday, December 11, 2014 2:21:58 PM Subject: Re: [ovirt-devel] Really slow VDSM on F21 Hey Petr, I have just ran a few functional tests on my laptop after upgrading it to F21. Both 'service vdsmd stop sudo service vdsmd start' and 'systemctl vdsmd restart' return fast and succeed. Also, running the entire networkTest suite takes about 628 sec which is reasonable compared to F20 on the same laptop. I think that hints in the direction of the Jenkins instance is a VM. Ido - Original Message - From: Petr Horacek phora...@redhat.com To: devel@ovirt.org, Francesco Romani from...@redhat.com Sent: Wednesday, December 3, 2014 11:09:03 AM Subject: Re: [ovirt-devel] Really slow VDSM on F21 Cc: Dan. - Original Message - From: Petr Horacek phora...@redhat.com To: devel@ovirt.org, Francesco Romani from...@redhat.com Sent: Tuesday, 2 December, 2014 12:39:58 PM Subject: Really slow VDSM on F21 Hello, has anyone else noticed VDSM's problems on Fedora 21? The problem is that when I start vdsmd via systemd, it takes about a minute to start the listener (returning Connection to 0.0.0.0:54321 refused) and next few minutes it returns 'Recovering from crash or Initializing'. After that, `getVdsCaps` takes cca 20 secs to finish. I tried to change niceness in vdsmd.service but it's still the same. When I start vdsm directly (/usr/share/vdsm/vdsm as vdsm user) it starts within a second as it should. Have you an idea why this happens? Best regards, Petr ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Call for Presentations: OSCON 2015
OSCON is returning to Portland July 20-24, 2015, and we want to make sure it's on your radar. As you probably know, the O'Reilly Open Source Convention is the must-attend professional training event for 4,000+ developers, programmers, engineers, architects, CxOs, and technology innovators. OSCON is well known for a fast-paced, intellectually stimulating program, that covers the open source ecosystem in its entirety. The call for speakers has just opened. If you, or any of your colleagues, are interested in speaking at OSCON, please review the new and improved program themes and tracks at OSCON.com, and find out about the kinds of topics we’re looking for, as well as tips for creating a great proposal. Proposals are due by February 2, 2015. http://www.oscon.com/open-source-2015 -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] A Question about Ovirt-engine Stage_Customization_setup Interface
About the interaction style of engine-setup ,i want the interface which present to user will be a form, like web login form or register form, User fill up the form and click save then the setup process go to the next stage . My problem is when i bring in the TUI package like urwid(Based on the event loop, which is used by ovirt-node.3.5.0 ) to replace the original dialog Implementation of otopi, i found that i have to change a lot ,not only the original dialog Implementation but also the process that validate and save custom config. Is there a simple way to work around the problem ? Thank you so much.___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
