[QE] oVirt 3.4.1 RC status
by Sandro Bonazzola
Hi,
We're going to tart composing oVirt 3.4.1 RC on 2014-04-23 09:00 UTC from 3.4 branches.
The bug tracker [1] shows no blocking bugs for the release
There are still 302 bugs [2] targeted to 3.4.1.
Excluding node and documentation bugs we still have 184 bugs [3] targeted to 3.4.1.
Please review them as soon as possible and retarget them to a future release.
Maintainers / Assignee:
- Please remember to rebuild your packages before 2014-04-23 09:00 UTC if you don't want
to use ovirt-3.4-snapshot packages
- Please add the bugs to the tracker if you think that 3.4.1 should not be released without them fixed.
- Please update the target to any next release for bugs that won't be in 3.4.1:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- If you're going to test this release, please add yourself to the test page [5]
[1] https://bugzilla.redhat.com/1080483
[2] http://red.ht/1gCFOtH
[3] http://red.ht/1laBSUj
[4] http://www.ovirt.org/OVirt_3.4.1_release_notes
[5] http://www.ovirt.org/Testing/oVirt_3.4.1_testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Re: [ovirt-devel] Fwd: rpm deps
by Dan Kenigsberg
On Wed, Apr 30, 2014 at 09:41:40AM -0400, Piotr Kliczewski wrote:
> Adding to the discussion.
Your CC line was too huge. devel(a)ovirt.org should be used to such
discussions.
>
> Currently vdsm-xmlrpc rpm is required by vdsm and vdsm-cli rpms. Initially I suggested to have vdsm-jsonrpc required by vdsm-api but it do not seems to be good idea.
> I think that we need to add that dept to vdsm rpm in the same way as it is for vdsm-xmlrpc.
>
> I do not understand why we have decided to split jsonrpc code between two rpms:
>
> vdms-api:
> - vdsmapi-schema.json
>
> vdsm-jsonrpc:
> - BindingJsonRpc
> - Bridge
>
> vdsm-yajsonrpc:
> - __init__
> - betterAsyncore
> - stomp
> - stompReactor
>
> I understand that we may have schema in api package but do we really need two packages for jsonrpc?
> Currently we need a package for stomp reactor so I suggest for now to have one json(stomp) rpm and
> create second for amqp when there will be need for it.
I believe that the motivation for the current packaging was that
- yajsonrpc is not strictly vdsm-related. It is a candidate for a
spin-off
- jsonrpc is sever-side only
- api might be needed by clients, too. But I hope we'd have reasonable
inspection to avoid this need.
As long as vdsm can work without jsonrpc, I'd rather that it does not
require the package. When we move away of xmlrpc, we could drop the
xmlrpc requirement, too.
Dan.
10 years
Re: [ovirt-devel] Sanlock fencing reservations
by Dan Kenigsberg
On Wed, Feb 26, 2014 at 11:14:33AM -0500, Saggi Mizrahi wrote:
> I've recently been introduced to the this feature and I was wondering is this really
> the correct way to go for solving this particular problem.
>
> My main issue is with making two unrelated flow dependent.
> By pushing this into the existing sanlock data structures you limit yourself
> in the future from changing either to optimize or even solve problems for a
> single use case.
>
> Having an independent daemon to perform this task will give more room as to
> how to implement the feature.
Saggi, are you thinking about something similar to fence_sanlockd
http://linux.die.net/man/8/fence_sanlockd and its client fence_sanlock?
Using them, instead of reimplementing parts of them within Vdsm, seem
reasonable in first glance.
However
http://www.ovirt.org/Features/Sanlock_Fencing#Why_not_use_fence_sanlockd.3F
claim that it wastes 2G of storage and requires explicit master domain
upgrade.
Nir, could you explain why so much space is required by sanlockd? Can it
be configured to use smaller area?
>
> I don't want to reach a situation where we need to change a sanlock struct
> and not be able to do it as it makes problems with fencing flows.
>
> I believe in the mantra that things should do one thing and do it well.
> This feels like an ad-hoc solution to a very niche problem.
>
>
> Further more, it kind of seems like a mailbox issue.
> Leaving a fencing request is just a message. In the
> future I can see it just being a suspend-to-disk request
> so that you don't even have to fence the host in such cases.
>
> The only reason I see people putting it to sanlock is
> that it's a daemon that reads from disk and has does fencing.
>
> I agree that in VDSMs current state putting this in the mailbox
> is unreliable to say the least but it doesn't mean that we can't
> have a small independent daemon to do the task until we get
> messaging in VDSM to a stable state.
>
> IMHO it's better than having it as and ad-hoc feature to sanlock.
> A feature which we can't remove later as someone might depend on it.
> A feature that might limit us or that we might even abandon once we
> have more reliable disk based messaging in VDSM.
10 years
[Features] Special Request for Feature Page Cleanup Projecy
by Brian Proffitt
All:
It has been requested that we add date/timestamps to the Features pages in order to highlight the age of each page and assist users in determining how fresh information is. After investigating various options to do this within the database or using automated code, it seems that the old-fashioned manual way is still the best option. This is because an automated solution would only insert the needed strings, but not the actual data that pertains to that feature.
To divide this work among the community, I have made an inventory of all of the features pages in the oVirt.org site as of 3/30/14, located at http://bit.ly/1iA1HQ3.
If everyone can take a look at this sheet (check the tabs on the bottom, too) and find the pages they created or for which they are responsible, the following steps should be taken for pages that are marked "Yes" in "Needs Datestamp":
1. Add the following line to the top of each page, under the first heading:
{{Feature|name=[Name of Feature]}|modules=[Node(s) of feature]|version=[oVirt version number]|status=Released}}
2. On the Feature page spreadsheet on Google Docs, change the "Yes" in "Needs Datestamp" to "No."
This new Feature template string will add the time and date information to the page automatically.
If, along the way, you find features that have been deprecated, or feature pages that are duplicates, these pages should be cleaned up as well. Ideally, this should not take too much time for each individual, and the effort will be a big step towards documentation consistency on the oVirt site.
If you have any questions/concerns, send them my way.
Thanks,
BKP
--
Brian Proffitt
oVirt Community Manager
Project Atomic Community Lead
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
10 years
vdsm installation error on fc20
by Vered Volansky
Hi,
I'm trying to install vdsm on a fedora20 machine with the following error.
I've been following http://www.ovirt.org/Download#Fedora_Installation_Instructions .
I've also tried "yum clean all" - to no avail.
Any idea anybody?
Thanks,
Vered
======================
=============================================================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================================================================================
Installing:
vdsm x86_64 4.14.6-0.fc20 ovirt-3.4-stable 752 k
Installing for dependencies:
vdsm-python x86_64 4.14.6-0.fc20 ovirt-3.4-stable 134 k
vdsm-python-zombiereaper noarch 4.14.6-0.fc20 ovirt-3.4-stable 18 k
vdsm-xmlrpc noarch 4.14.6-0.fc20 ovirt-3.4-stable 35 k
Transaction Summary
===================================================================================================================================================================================================================
Install 1 Package (+3 Dependent packages)
Total download size: 938 k
Installed size: 3.5 M
Is this ok [y/d/N]: y
Downloading packages:
warning: /var/cache/yum/x86_64/20/ovirt-3.4-stable/packages/vdsm-python-4.14.6-0.fc20.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID fe590cb7: NOKEY ] 117 kB/s | 127 kB 00:00:06 ETA
Public key for vdsm-python-4.14.6-0.fc20.x86_64.rpm is not installed
(1/4): vdsm-python-4.14.6-0.fc20.x86_64.rpm | 134 kB 00:00:01
(2/4): vdsm-python-zombiereaper-4.14.6-0.fc20.noarch.rpm | 18 kB 00:00:00
(3/4): vdsm-xmlrpc-4.14.6-0.fc20.noarch.rpm | 35 kB 00:00:00
(4/4): vdsm-4.14.6-0.fc20.x86_64.rpm | 752 kB 00:00:03
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 236 kB/s | 938 kB 00:00:03
Public key for vdsm-python-zombiereaper-4.14.6-0.fc20.noarch.rpm is not installed
10 years
Re: [ovirt-devel] Sanlock fencing reservations
by Nir Soffer
----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> To: "arch" <arch(a)ovirt.org>
> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "David Teigland" <teigland(a)redhat.com>
> Sent: Wednesday, February 26, 2014 6:14:33 PM
> Subject: Sanlock fencing reservations
>
> I've recently been introduced to the this feature and I was wondering is this
> really
> the correct way to go for solving this particular problem.
>
> My main issue is with making two unrelated flow dependent.
Hi Saggi,
Sorry for the late response.
The flows are related - sanlock already fencing as part of the lease and
resources keeping.
> By pushing this into the existing sanlock data structures you limit yourself
> in the future from changing either to optimize or even solve problems for a
> single use case.
I agree, we have 196 unused bits in the sanlock lease, which can be used
for other needs if we don't used them the new host_message api. We can
keep the extra space forever - or use it now.
>
> Having an independent daemon to perform this task will give more room as to
> how to implement the feature.
I agree, but we are not designing this system from scratch, and adding this
feature to the existing daemon is easy and makes sense. I thinks this is
a good trade-off.
>
> I don't want to reach a situation where we need to change a sanlock struct
> and not be able to do it as it makes problems with fencing flows.
This is the price for choosing this way.
>
> I believe in the mantra that things should do one thing and do it well.
> This feels like an ad-hoc solution to a very niche problem.
>
>
> Further more, it kind of seems like a mailbox issue.
> Leaving a fencing request is just a message. In the
> future I can see it just being a suspend-to-disk request
> so that you don't even have to fence the host in such cases.
>
> The only reason I see people putting it to sanlock is
> that it's a daemon that reads from disk and has does fencing.
>
> I agree that in VDSMs current state putting this in the mailbox
> is unreliable to say the least but it doesn't mean that we can't
> have a small independent daemon to do the task until we get
> messaging in VDSM to a stable state.
>
> IMHO it's better than having it as and ad-hoc feature to sanlock.
> A feature which we can't remove later as someone might depend on it.
> A feature that might limit us or that we might even abandon once we
> have more reliable disk based messaging in VDSM.
>
I don't think we need another daemon that duplicate most of what sanlock
is doing now, and I would not mix critical messages (fencing) with everyday
messages in such new messaging solution.
Regards,
Nir
10 years
oVirt sources tagging
by Sandro Bonazzola
Hi,
today I've seen that ovirt-hosted-engine-ha was missing proper tagging of version released.
I've not checked all projects so this is just a reminder.
Maintainers, please ensure that all previous releases are properly tagged (at least GA ones, but RC and beta are recommended too) and please remember
to tag each time you release a new tarball.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
UI plugins using REST API
by Vojtech Szocs
Hi guys,
just a quick note on UI plugin vs. REST API integration,
there are currently two ways to work with REST API:
* (standard) /ovirt-engine/api
* (legacy) /api
Please don't use the legacy URL, since "sessionId" that
is acquired via RestApiSessionAcquired event handler [1]
works only for the standard URL.
(Also, don't forget to include "Prefer:persistent-auth"
header when making calls that shouldn't close the session.)
[1] http://www.ovirt.org/Features/UIPlugins#REST_API_integration
Regards,
Vojtech
10 years
oVirt 3.4.1 branching
by Sandro Bonazzola
Hi,
we're going to create ovirt-engine-3.4.1 branch tomorrow morning 08:00 UTC in order to allow 3.4.2 development starting on 3.4 branch while we prepare
for 3.4.1 GA release.
So starting tomorrow morning, if you have patches targeted to 3.4.1 you'll need to push them on 3.4.1 branch too.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
