10:06 a.m.
This is a multi-part message in MIME format.
--------------050509040907040604080502
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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.Sjoberg(a)slu.se
<mailto:Karli.Sjoberg@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)
-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
> Best regards,
> Alex Lourie,
> Software Developer in Integration,
> RHEV, Red Hat.
>
> >
> > Best Regards
> > Karli Sjöberg
> >
> > fre 2013-04-05 klockan 10:24 +0200 skrev Sandro Bonazzola: Hi Karli,
> >> we're still working on it
> >>
> >>
> >> Il 02/04/2013 12:22, Karli Sjöberg ha scritto:
> >>
> >>
> > Hi,
> >>>
> >>> has there been any progress regarding this matter?
> >>>
> >>> Best Regards
> >>> Karli Sjöberg
> >>>
> >>> fre 2013-03-15 klockan 14:12 +0000 skrev Karli Sjöberg:
> >>>> fre 2013-03-15 klockan 14:59 +0100 skrev Sandro Bonazzola:
> >>>>> Il 13/03/2013 12:24, Karli Sjöberg ha scritto:
> >>>>>
> >>>>>> ons 2013-03-13 klockan 12:00 +0100 skrev Dave Neary: Hi
Karli,
> >>>>>>>
> >>>>>>> On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> >>>>>>> > Hi,
> >>>>>>> >
> >>>>>>> > in the absence of any official path, we have
started working
> >>>>>>> out our own
> >>>>>>> > procedure for going from oVirt-3.1/Fedora 17 to
> >>>>>>> oVirt-3.2/Fedora 18.
> >>>>>>>
> >>>>>>> Indeed, I have not seen any documentation in the wiki
yet on
> >>>>>>> upgrading
> >>>>>>> oVirt - would you be interested in writing up your
experiences
> >>>>>>> there as
> >>>>>>> a guide to others?
> >>>>>>>
> >>>>>>> Thanks!
> >>>>>>> Dave.
> >>>>>>>
> >>>>>>>
> >>>>>> That was my intention to share a working procedure once it
was
> >>>>>> complete but I unfortunately hit a wall at
"engine-upgrade". I
> >>>>>> would be very glad, and able to continue, if that obstacle
could
> >>>>>> be lifted.
> >>>>>>
> >>>>>
> >>>>> My experience in upgrading from oVirt-3.1/Fedora 17 to
> >>>>> oVirt-3.2/Fedora 18:
> >>>>>
> >>>>> On Fedora 17:
> >>>>> Be sure to have the latest updates running: yum distro-sync
> >>>>> Set exclude=ovirt* in /etc/yum.conf
> >>>>> Execute: fedup --disablerepo=ovirt* --network 18
> >>>>>
> >>>>> When you have a running Fedora 18:
> >>>>> # systemctl list-units --failed
> >>>>> UNIT LOAD ACTIVE SUB DESCRIPTION
> >>>>> httpd.service loaded failed failed The Apache HTTP Server
> >>>>> postgresql.service loaded failed failed PostgreSQL database
server
> >>>>>
> >>>>> # systemctl stop postgresql.service
> >>>>> # tar cJvf pgsql-backup.tar.xz /var/lib/pgsql/data/
> >>>>> # yum install postgresql-upgrade
> >>>>>
> >>>>> # cp /var/lib/pgsql/data/pg_hba.conf /root/pg_hba.conf.ovirt
> >>>>>
> >>>>> edit /var/lib/pgsql/data/pg_hba.conf changing md5 to trust on
the
> >>>>> local line.
> >>>>>
> >>>>> # diff -u pg_hba.conf.ovirt pg_hba.conf
> >>>>> --- pg_hba.conf.ovirt 2013-01-30 20:58:49.404000000 +0100
> >>>>> +++ pg_hba.conf 2013-01-30 20:59:06.709000000 +0100
> >>>>> @@ -77,7 +77,7 @@
> >>>>> # TYPE DATABASE USER ADDRESS
> >>>>> METHOD
> >>>>>
> >>>>> # "local" is for Unix domain socket connections only
> >>>>> -local all all
> >>>>> md5
> >>>>> +local all all
> >>>>> trust
> >>>>> # IPv4 local connections:
> >>>>> host all all 127.0.0.1/32
> >>>>> md5
> >>>>> # IPv6 local connections:
> >>>>>
> >>>>>
> >>>>>
> >>>>> # postgresql-setup upgrade
> >>>>> Redirecting to /bin/systemctl stop postgresql.service
> >>>>> Upgrading database: OK
> >>>>>
> >>>>> See /var/lib/pgsql/pgupgrade.log for details.
> >>>>>
> >>>>> # cp /root/pg_hba.conf.ovirt /var/lib/pgsql/data/pg_hba.conf
> >>>>> # systemctl postgrsql.service restart
> >>>>>
> >>>>>
> >>>>> edit /etc/httpd/conf.d/ssl.conf:
> >>>>> # diff -u ssl.conf.ovirt ssl.conf
> >>>>> --- ssl.conf.ovirt 2013-01-30 21:21:06.906000000 +0100
> >>>>> +++ ssl.conf 2013-01-30 21:22:02.757000000 +0100
> >>>>> @@ -9,7 +9,7 @@
> >>>>> # consult the online docs. You have been warned.
> >>>>> #
> >>>>>
> >>>>> -LoadModule ssl_module modules/mod_ssl.so
> >>>>> +#LoadModule ssl_module modules/mod_ssl.so
> >>>>>
> >>>>> #
> >>>>> # When we also provide SSL we have to listen to the
> >>>>> @@ -40,7 +40,7 @@
> >>>>> # Semaphore:
> >>>>> # Configure the path to the mutual exclusion semaphore the
> >>>>> # SSL engine uses internally for inter-process
> >>>>> synchronization.
> >>>>> -SSLMutex default
> >>>>> +#SSLMutex default
> >>>>>
> >>>>> # Pseudo Random Number Generator (PRNG):
> >>>>> # Configure one or more sources to seed the PRNG of the
> >>>>>
> >>>>>
> >>>>> # /bin/systemctl restart httpd.service
> >>>>>
> >>>>> Remove the line exclude=ovirt* from /etc/yum.conf
> >>>>>
> >>>>> # yum update ovirt-engine-setup
> >>>>> # engine-upgrade
> >>>>>
> >>>>> However, during the upgrade I've stepped into
> >>>>>https://bugzilla.redhat.com/show_bug.cgi?id=906270
> >>>>> We are still working on the upgrade actions.
> >>>>>
> >>>> Our procedures looks almost exactly the same, and we have gotten
> >>>> just as far as you have. Good to know.
> >>>>
> >>>> /Karli
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
> >> --
> >> Sandro Bonazzola
> >> Better technology. Faster innovation. Powered by community
> >> collaboration.
> >> See how it works at redhat.com
> >>
> >
> > --
> >
> > Med Vänliga Hälsningar
> > -------------------------------------------------------------------------------
> > Karli Sjöberg
> > Swedish University of Agricultural Sciences
> > Box 7079 (Visiting Address Kronåsvägen 8)
> > S-750 07 Uppsala, Sweden
> > Phone: +46-(0)18-67 15 66
> >karli.sjoberg(a)slu.se <mailto:karli.sjoberg@slu.se>
>
--
Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg(a)slu.se <mailto:karli.sjoberg@adm.slu.se>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------050509040907040604080502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/17/2013 02:51 PM, Karli Sjöberg
wrote:<br>
</div>
<blockquote
cite="mid:5F9E965F5A80BC468BE5F40576769F092E6BAF5F@exchange2-1"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=utf-8">
<meta name="GENERATOR" content="GtkHTML/4.4.4">
mån 2013-06-17 klockan 10:11 +0003 skrev Alex Lourie:
<blockquote type="CITE">
<pre>On Fri, Jun 14, 2013 at 12:26 PM, Karli Sjöberg <<a
moz-do-not-send="true"
href="mailto:Karli.Sjoberg@slu.se">Karli.Sjoberg@slu.se</a>>
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="CITE">
<pre>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.
</pre>
</blockquote>
<br>
Straight answer: Am I ever going to be able to upgrade from 3.1 to
3.2?<br>
<br>
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?<br>
</blockquote>
<br>
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.).<br>
in addition we have noticed that the interest from the community
regarding it, is very limited.<br>
<br>
from where i see i we have couple of options:<br>
-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)<br>
-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<br>
<br>
<br>
<blockquote
cite="mid:5F9E965F5A80BC468BE5F40576769F092E6BAF5F@exchange2-1"
type="cite">
<br>
<blockquote type="CITE">
<pre>Best regards,
Alex Lourie,
Software Developer in Integration,
RHEV, Red Hat.
>
> Best Regards
> Karli Sjöberg
>
> fre 2013-04-05 klockan 10:24 +0200 skrev Sandro Bonazzola: Hi Karli,
>> we're still working on it
>>
>>
>> Il 02/04/2013 12:22, Karli Sjöberg ha scritto:
>>
>>
> Hi,
>>>
>>> has there been any progress regarding this matter?
>>>
>>> Best Regards
>>> Karli Sjöberg
>>>
>>> fre 2013-03-15 klockan 14:12 +0000 skrev Karli Sjöberg:
>>>> fre 2013-03-15 klockan 14:59 +0100 skrev Sandro
Bonazzola:
>>>>> Il 13/03/2013 12:24, Karli Sjöberg ha scritto:
>>>>>
>>>>>> ons 2013-03-13 klockan 12:00 +0100 skrev
Dave Neary: Hi Karli,
>>>>>>>
>>>>>>> On 03/11/2013 12:16 PM, Karli
Sjöberg wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > in the absence of any
official path, we have started working
>>>>>>> out our own
>>>>>>> > procedure for going from
oVirt-3.1/Fedora 17 to
>>>>>>> oVirt-3.2/Fedora 18.
>>>>>>>
>>>>>>> Indeed, I have not seen any
documentation in the wiki yet on
>>>>>>> upgrading
>>>>>>> oVirt - would you be interested
in writing up your experiences
>>>>>>> there as
>>>>>>> a guide to others?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Dave.
>>>>>>>
>>>>>>>
>>>>>> That was my intention to share a working
procedure once it was
>>>>>> complete but I unfortunately hit a wall
at "engine-upgrade". I
>>>>>> would be very glad, and able to continue,
if that obstacle could
>>>>>> be lifted.
>>>>>>
>>>>>
>>>>> My experience in upgrading from oVirt-3.1/Fedora
17 to
>>>>> oVirt-3.2/Fedora 18:
>>>>>
>>>>> On Fedora 17:
>>>>> Be sure to have the latest updates running: yum
distro-sync
>>>>> Set exclude=ovirt* in /etc/yum.conf
>>>>> Execute: fedup --disablerepo=ovirt* --network 18
>>>>>
>>>>> When you have a running Fedora 18:
>>>>> # systemctl list-units --failed
>>>>> UNIT LOAD ACTIVE SUB
DESCRIPTION
>>>>> httpd.service loaded failed failed The
Apache HTTP Server
>>>>> postgresql.service loaded failed failed
PostgreSQL database server
>>>>>
>>>>> # systemctl stop postgresql.service
>>>>> # tar cJvf pgsql-backup.tar.xz
/var/lib/pgsql/data/
>>>>> # yum install postgresql-upgrade
>>>>>
>>>>> # cp /var/lib/pgsql/data/pg_hba.conf
/root/pg_hba.conf.ovirt
>>>>>
>>>>> edit /var/lib/pgsql/data/pg_hba.conf changing md5
to trust on the
>>>>> local line.
>>>>>
>>>>> # diff -u pg_hba.conf.ovirt pg_hba.conf
>>>>> --- pg_hba.conf.ovirt 2013-01-30
20:58:49.404000000 +0100
>>>>> +++ pg_hba.conf 2013-01-30 20:59:06.709000000
+0100
>>>>> @@ -77,7 +77,7 @@
>>>>> # TYPE DATABASE USER ADDRESS
>>>>> METHOD
>>>>>
>>>>> # "local" is for Unix domain socket
connections only
>>>>> -local all all
>>>>> md5
>>>>> +local all all
>>>>> trust
>>>>> # IPv4 local connections:
>>>>> host all all
127.0.0.1/32
>>>>> md5
>>>>> # IPv6 local connections:
>>>>>
>>>>>
>>>>>
>>>>> # postgresql-setup upgrade
>>>>> Redirecting to /bin/systemctl stop
postgresql.service
>>>>> Upgrading database: OK
>>>>>
>>>>> See /var/lib/pgsql/pgupgrade.log for details.
>>>>>
>>>>> # cp /root/pg_hba.conf.ovirt
/var/lib/pgsql/data/pg_hba.conf
>>>>> # systemctl postgrsql.service restart
>>>>>
>>>>>
>>>>> edit /etc/httpd/conf.d/ssl.conf:
>>>>> # diff -u ssl.conf.ovirt ssl.conf
>>>>> --- ssl.conf.ovirt 2013-01-30 21:21:06.906000000
+0100
>>>>> +++ ssl.conf 2013-01-30 21:22:02.757000000 +0100
>>>>> @@ -9,7 +9,7 @@
>>>>> # consult the online docs. You have been warned.
>>>>> #
>>>>>
>>>>> -LoadModule ssl_module modules/mod_ssl.so
>>>>> +#LoadModule ssl_module modules/mod_ssl.so
>>>>>
>>>>> #
>>>>> # When we also provide SSL we have to listen to
the
>>>>> @@ -40,7 +40,7 @@
>>>>> # Semaphore:
>>>>> # Configure the path to the mutual exclusion
semaphore the
>>>>> # SSL engine uses internally for inter-process
>>>>> synchronization.
>>>>> -SSLMutex default
>>>>> +#SSLMutex default
>>>>>
>>>>> # Pseudo Random Number Generator (PRNG):
>>>>> # Configure one or more sources to seed the
PRNG of the
>>>>>
>>>>>
>>>>> # /bin/systemctl restart httpd.service
>>>>>
>>>>> Remove the line exclude=ovirt* from
/etc/yum.conf
>>>>>
>>>>> # yum update ovirt-engine-setup
>>>>> # engine-upgrade
>>>>>
>>>>> However, during the upgrade I've stepped into
>>>>> <a moz-do-not-send="true"
href="https://bugzilla.redhat.com/show_bug.cgi?id=906270">ht...
>>>>> We are still working on the upgrade actions.
>>>>>
>>>> Our procedures looks almost exactly the same, and we
have gotten
>>>> just as far as you have. Good to know.
>>>>
>>>> /Karli
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community
>> collaboration.
>> See how it works at redhat.com
>>
>
> --
>
> Med Vänliga Hälsningar
> -------------------------------------------------------------------------------
> Karli Sjöberg
> Swedish University of Agricultural Sciences
> Box 7079 (Visiting Address Kronåsvägen 8)
> S-750 07 Uppsala, Sweden
> Phone: +46-(0)18-67 15 66
> <a moz-do-not-send="true"
href="mailto:karli.sjoberg@slu.se">karli.sjoberg@slu.se</a>
</pre>
</blockquote>
<br>
<table width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: +46-(0)18-67 15 66<br>
<a moz-do-not-send="true"
href="mailto:karli.sjoberg@adm.slu.se">karli.sjoberg@slu.se</a>
</td>
</tr>
</tbody>
</table>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
</pre>
</blockquote>
<br>
</body>
</html>
--------------050509040907040604080502--