On 06/18/2013 10:46 AM, Karli Sjöberg wrote:
tis 2013-06-18 klockan 10:06 +0300 skrev Moran Goldboim:
On 06/17/2013 02:51 PM, Karli Sjöberg wrote:
mån 2013-06-17 klockan 10:11 +0003 skrev Alex Lourie:
On Fri, Jun 14, 2013 at 12:26 PM, Karli Sjöberg karli.sjob...@slu.se
mailto:karli.sjob...@slu.se
wrote:
Hi!
Hi Karli,
More than two months have passed without any notices or updates on
this issue, and looking at the bugreport absolutely nothing has been
done since then. What´s confusing me is that the release management
for oVirt 3.2 has this clearly printed:
MUST: Upgrade from previous release
And you all seem too busy with getting the next release out of the
door before fixing the current... What gives? Don´t you care about
early adopters?
I apologise that this issue wasn't taken care of yet. It is clear that
the priorities of developers shifted towards work on features in 3.3
release, which feature freeze is happening in about 2 weeks, so you can
understand the time pressure they all have. There's no need to be angry
about that. It is an open source project and as resources for the
development are limited, we're trying to do our best to cover as much
issues as possible. This can lead to situations as this issue, which
may be left behind for some time.
I´m not angry, as I stated before, I´m more confused, and maybe a
little disappointed that important(in my opinion) pieces of a
projects continuum have been ignored like that. I´m having a hard
time understanding the reasoning behind the priorities that have made
this issue appear. In my mind, making sure that users of any project
are able to follow between minor upgrades is a given, with a schedule
like; 1) Feature freeze, 2) Fix release blockers (upgrading being one
of them), 3) Release, in that order. Now what´s happening is that you
are kind of hoping to drag this out until the problem goes away by
itself when you decide it´s time to stop supporting 3.1.
That said, the process for upgrading the oVirt 3.1 on Fedora 17 to
oVirt 3.2 on Fedora 18 is complex and non-trivial, that's why it is
taking time to resolve all the issues that come up in the process.
If this matter is not extremely urgent, we are currently working on a
tool that may make this upgrade easier, albeit, maybe, not completely
automatic.
On the other hand, if this is a completely and utterly urgent, we may
try to guide you through possible manual attempts to perform the
upgrade. Mind though, that they weren't thoroughly tested, and not
promised to go smoothly or even work, and we may have to think about
possible alternative solutions on the go.
Straight answer: Am I ever going to be able to upgrade from 3.1 to 3.2?
My concern (fear) is about being left behind, abandoned. It makes me
feel non-important. Just like any admin, the work put down to make
Templates, to set up quotas, create VMPools, a dozen of guests. And
then have to export everything (nullifying the idea of Thin
Provisioning), redo every Role, reset every permission, quota, and
so on, isn´t (in my opinion) viable in the long run for oVirt as a
project to demand. That´s why I had the notion that upgrading surely
had to be a high priority. Was I wrong about that?
upgrade actually was high priority task, but due to lots of platform
(fedora 18) changes, it became a huge operation to support it (which
comes on top new features/bugs/support etc.).
in addition we have noticed that the interest from the community
regarding it, is very limited.
from where i see i we have couple of options:
-if there is enough interest from the community we can give it another
go (though i think most of it moved long ago to oVirt 3.2)
You certainly have my interest at least;)
-we can help individuals by making a migration (3.1-3.2) document on
fedora base systems- we'll probably need your assistance on testing
side here
A document explaining how to upgrade would be completly acceptable for
me. I´m not asking for a turnkey command that makes everything for me,
I´ve managed to get quite far by myself any way. I would love to help
testing the procedure, as I´ve stated before, we have set up a dedicated
test environment dedicated for this specific upgrade task in mind, with
engine, hosts and storage somewhat equal to the production system.
Please, if there´s anything I can do to help, don´t hesitate to ask!
I think another consideration here is with the issues around upgrades
with fedora (which breaks itself during upgrade), if recommending to
deploy on .el6[1] (RHEL/CentOS/etc.) platforms wouldn't be better.
[1] until other platforms are added - ubuntu is starting to look close.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
