[Users] Fedora upgrading from 3.1 to 3.2

Alex Lourie alourie at redhat.com
Thu Jun 20 17:05:11 UTC 2013


Hi Karli

I am reviewing all the actions again, and hopefully will have something 
documented on Sunday.

Alex.

On Tue, Jun 18, 2013 at 10:46 AM, Karli Sjöberg <Karli.Sjoberg at slu.se> 
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.Sjoberg at 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!
> 
>> 
>> 
>>> 
>>>> 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 at 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 at slu.se
>>> 
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>> 
>>  
>> 
>  
> -- 
> 
> 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 at slu.se




More information about the Users mailing list