subject:"Re\: \[Users\] Fedora upgrading from 3.1 to 3.2"

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-07 Thread Karli Sjöberg

OK guys, here it is. The entire process of going from oVirt-3.1 on Fedora to 
oVirt-3.2 on CentOS!

Installation
minimal Fedora 17 / oVirt-3.1

Engine Contents
NewDC (NFS DataCenter Type, Quota disabled)
- Networks
  - ovirtmgmt
  - ovirtnfs
- Storage
  - Data
  - Export
  - ISO
- Templates
  - CentOS
  - Fedora
  - Ubuntu
- Clusters (Conroe Family)
   - CLusterName
- Hostname1 (No power manangement)
- Hostname2 (No power manangement)
- Virtual machines
  - CentOS (Server,AD\abcd0001: UserRole)
  - ClonedFedora (Server)
  - ClonedUbuntu (Desktop)
  - Fedora (Server,AD\abcd0002: UserRole)
  - TestPool-{1,2,3} (VDI,Based on Fedora-template)
  - Ubuntu (Server,AD\abcd0003: UserRole)
  - Windows7 (Server,AD\abcd0004: UserRole)
- Templates
  - CentOS
  - Fedora
  - Ubuntu
- Pools
  - TestPool (Assigned:3, Running:1,AD\oVirt_Users:UserRole)
- Permissions
  - Active Directory connected
   - AD\oVirt_Admins = SuperUser

1) Back up using "/mnt/backup/ovirtctl":
#!/bin/sh

DB_EXPORT_PATH=/usr/share/ovirt-engine/db-backups
DB_BKUP_FILENAME=dump_engine_`date "+%Y%m%d_%H%M"`.sql
DB_NAME=engine
ENGINE_CONF='/etc/ovirt-engine
 /etc/pki/ovirt-engine
 /usr/share/ovirt-engine/db-backups
 /root/.pgpass
 /root/.rnd'
BACKUPDIR=/mnt/backup
ENGINE_BKUP_FILENAME=bkup_engine_`date "+%Y%m%d_%H%M"`.tgz

case $1 in

  backup)
find $DB_EXPORT_PATH -mtime +1 -type f -exec rm -rf {} \;
find $BACKUPDIR -mtime +7 -type f -exec rm -rf {} \;
pg_dump -C -E UTF8 --column-inserts --disable-dollar-quoting 
--disable-triggers -U postgres --format=p -f \
$DB_EXPORT_PATH/$DB_BKUP_FILENAME $DB_NAME
tar zcf $BACKUPDIR/$ENGINE_BKUP_FILENAME $ENGINE_CONF
  ;;

  #restore)
  #  tar zxf $BACKUPDIR/$ENGINE_BKUP_FILENAME -C /
  #;;

esac

# /mnt/backup/ovirtctl backup
# systemctl stop ovirt-engine.service

2) I chose to install with engine as ISO-provider, so back that up:
# cp -rf /mnt/ISO /mnt/backup/
# cp /etc/exports /mnt/backup/

3) Reinstall minimal CentOS-6.4

4) Use dreyou´s guide for setting up engine and re-enter the same password and 
options as you used when you first installed the engine back in Fedora. Then, 
after the engine has started, shut it down and begin restoring the previous 
setup:
http://wiki.dreyou.org/dokuwiki/doku.php?id=ovirt_rpm_start31

# service ovirt-engine stop
# service jboss-as stop
# service httpd stop

5) Start the restoring process (make sure to mount your backup).
- Restore ISO domain
# rm -rf /mnt/ISO/*
# cp -rf /mnt/backup/ISO/* /mnt/ISO/
# cp /mnt/backup/exports /etc/exports
# chown -R 36:36 /mnt/ISO/
# service nfs restart

- Restore engine
# tar zxf $BACKUPDIR/$ENGINE_BKUP_FILENAME -C /

- Make a minor modification to the backed up Fedora database dump:
@@ -4,9 +4,10 @@

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
-SET standard_conforming_strings = on;
+SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
+SET escape_string_warning = off;

--
-- Name: engine; Type: DATABASE; Schema: -; Owner: engine
@@ -21,36 +22,18 @@

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
-SET standard_conforming_strings = on;
+SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
+SET escape_string_warning = off;

--
--- Name: plpgsql; Type: EXTENSION; Schema: -; Owner:
+-- Name: plpgsql; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: engine
--

-CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
+CREATE PROCEDURAL LANGUAGE plpgsql;


---
--- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner:
---
-
-COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
-
-
---
--- Name: uuid-ossp; Type: EXTENSION; Schema: -; Owner:
---
-
-CREATE EXTENSION IF NOT EXISTS "uuid-ossp" WITH SCHEMA public;
-
-
---
--- Name: EXTENSION "uuid-ossp"; Type: COMMENT; Schema: -; Owner:
---
-
-COMMENT ON EXTENSION "uuid-ossp" IS 'generate universally unique identifiers 
(UUIDs)';
-
+ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO engine;

SET search_path = public, pg_catalog;

- Restore database from backup:
# dropdb -U postgres engine
# createdb -U postgres engine
# psql -U postgres engine < 
/usr/share/ovirt-engine/db-backups/dump_engine_20130805_1137.sql
# service httpd start
# service jboss-as start
# service ovirt-engine start

5) After everything is back up and running in CentOS, you follow dreyou´s guide 
on upgrading from 3.1 to 3.2:
http://wiki.dreyou.org/dokuwiki/doku.php?id=ovirt_rpm_update31to32

- For me, as several others, engine-upgrade first fails because you have to run 
it like:
# LC_ALL=C engine-upgrade

- And here was the trickiest part of the entire process, I had to actually fail 
once to be able to save a modified version of 
"/usr/share/ovirt-engine/dbscripts/upgrade/03_01_1520_add_fk_vm_interface_vm_static_template.sql"
 and insert:
DELETE FROM vm_interface where vmt_guid not in (SELECT vm_guid FROM vm_static);

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-02 Thread Karli Sjöberg

tor 2013-08-01 klockan 07:46 -0400 skrev Alex Lourie:


@Alon

Upgrade from 3.1 to 3.2 doesn't work in upstream, that's why we are doing this.

@Karli - are you keeping the keys/certificates from the 3.1 installation?



That time, no I didn´t. By this time, I was rather fed up with Fedora so I 
started thinking outside the box a little. So I reinstalled Fedora 17, 
installed engine and reran engine-setup. After that I made a backup, then 
reinstalled to CentOS-6.4 and used dreyou´s repo to regain oVirt-3.1. Then I 
ran engine-setup, shut the engine down, dropped the db, restored the previous 
db I had when it was Fedora and restored /etc/pki/ovirt-engine/certs, /keys, 
.keystore and .truststore. After a restart of httpd and ovirt-engine I was able 
to log in to the 3.1-engine that was originally set up in Fedora. And since 
that worked alright, I proceeded with following dreyou´s excellent (because 
it´s tested) guide for upgrading from 3.1 to 3.2, and it worked!!! So the once 
Fedora/oVirt-3.1 engine is now a CentOS/oVirt-3.2 engine instead:)

So as it turns out, the best way of upgrading from oVirt-3.1 on Fedora is...to 
switch to CentOS...

I will rerun the procedure again from start, but this time with added Hosts, 
Storage, etc. to confirm.

--

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.sjob...@slu.se
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Alex Lourie

@Alon

Upgrade from 3.1 to 3.2 doesn't work in upstream, that's why we are doing this.

@Karli - are you keeping the keys/certificates from the 3.1 installation?

-- 

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat


- Original Message -
> From: "Alon Bar-Lev" 
> To: "Karli Sjöberg" 
> Cc: users@ovirt.org
> Sent: Thursday, August 1, 2013 2:20:06 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> 
> 
> - Original Message -
> > From: "Karli Sjöberg" 
> > To: "Alon Bar-Lev" 
> > Cc: users@ovirt.org
> > Sent: Thursday, August 1, 2013 12:50:11 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> > 
> > tor 2013-08-01 klockan 05:29 -0400 skrev Alon Bar-Lev:
> > 
> > 
> > 
> > - Original Message -
> > > From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> > > To: "Alon Bar-Lev" mailto:alo...@redhat.com>>
> > > Cc: "Alex Lourie" mailto:alou...@redhat.com>>,
> > > users@ovirt.org<mailto:users@ovirt.org>, "Eli Mesika"
> > > mailto:emes...@redhat.com>>
> > > Sent: Thursday, August 1, 2013 12:24:57 PM
> > > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> > >
> > > Ah, my bad, I botched that when doing the patch for "engine-setup" and
> > > hadn´t
> > > made an original copy so I did "yum erase" and "yum install" again to get
> > > back the original file, and yum was nice enough to erase and install
> > > blank
> > > files for me, heh. Now I´m back again and once more updated those option
> > > values in the database, but I´m still not able to log in. The log is
> > > attached.
> > 
> > The engine.log you sent is too short for typical log...
> > 
> > Can we start from scratch?
> > What exactly are you doing?
> > What sequence?
> > 
> > 
> > OK, to make a long story a little shorter. I´m trying to go from oVirt-3.1
> > to
> > oVirt-3.2 on Fedora, so this is what I have done so far:
> > 
> > (After Fedora is up to 18, and the old engine is up and running, I was able
> > to log in)
> > - Erase all of the 3.1-packages
> > - Install the new 3.2-packages
> > - Have to go about the dbase upgrade like this:
> > # psql -U postgres engine
> > $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> > $ \q
> > Or the upgrade won´t work. After that it´s possible to:
> > # cd /usr/share/ovirt-engine/dbscripts
> > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> > (lots of output)
> > # engine-cleanup --dont-drop-db
> > 
> > - Had to make modifications to "/usr/bin/engine-setup" for the setup to
> > complete OK.
> > @@ -1142,8 +1142,8 @@
> >  # Run db backup
> >  utils.backupDB(
> >  db=basedefs.DB_NAME,
> > -backup_file=dbBackupFile,
> > -env=utils.getPgPassEnv(),
> > +backupFile=dbBackupFile,
> > +#env=utils.getPgPassEnv(),
> >  user=getDbUser(),
> >  host=getDbHostName(),
> >  port=getDbPort(),
> > 
> > # engine-setup
> > # systemctl stop ovirt-engine
> > # psql -U engine engine
> > $ update vdc_options set option_value =
> > '/etc/pki/ovirt-engine/keys/engine.p12' where option_name = 'keystoreUrl';
> > $ update vdc_options set option_value =
> > '/etc/pki/ovirt-engine/certs/engine.cer' where option_name =
> > 'CertificateFileName';
> > $ update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore'
> > where option_name = 'TruststoreUrl';
> > $ \q
> > # cat /dev/null > /var/log/ovirt-engine/engine.log
> > # systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log
> > |
> > tee /tmp/engine_start.log
> > 
> > That is the log you now have seen.
> 
> And why don't you use engine-upgrade?
> 
> I think that in this process you probably remove your existing keys from
> /etc/pki/ovirt-engine
> 
> > 
> > 
> > 
> > 
> > Thanks,
> > Alon
> > 
> > 
> > --
> > 
> > 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.sjob...@slu.se<mailto:karli.sjob...@adm.slu.se>
> > 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Alon Bar-Lev



- Original Message -
> From: "Karli Sjöberg" 
> To: "Alon Bar-Lev" 
> Cc: users@ovirt.org
> Sent: Thursday, August 1, 2013 12:50:11 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> tor 2013-08-01 klockan 05:29 -0400 skrev Alon Bar-Lev:
> 
> 
> 
> - Original Message -
> > From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> > To: "Alon Bar-Lev" mailto:alo...@redhat.com>>
> > Cc: "Alex Lourie" mailto:alou...@redhat.com>>,
> > users@ovirt.org<mailto:users@ovirt.org>, "Eli Mesika"
> > mailto:emes...@redhat.com>>
> > Sent: Thursday, August 1, 2013 12:24:57 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Ah, my bad, I botched that when doing the patch for "engine-setup" and
> > hadn´t
> > made an original copy so I did "yum erase" and "yum install" again to get
> > back the original file, and yum was nice enough to erase and install blank
> > files for me, heh. Now I´m back again and once more updated those option
> > values in the database, but I´m still not able to log in. The log is
> > attached.
> 
> The engine.log you sent is too short for typical log...
> 
> Can we start from scratch?
> What exactly are you doing?
> What sequence?
> 
> 
> OK, to make a long story a little shorter. I´m trying to go from oVirt-3.1 to
> oVirt-3.2 on Fedora, so this is what I have done so far:
> 
> (After Fedora is up to 18, and the old engine is up and running, I was able
> to log in)
> - Erase all of the 3.1-packages
> - Install the new 3.2-packages
> - Have to go about the dbase upgrade like this:
> # psql -U postgres engine
> $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> $ \q
> Or the upgrade won´t work. After that it´s possible to:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> (lots of output)
> # engine-cleanup --dont-drop-db
> 
> - Had to make modifications to "/usr/bin/engine-setup" for the setup to
> complete OK.
> @@ -1142,8 +1142,8 @@
>  # Run db backup
>  utils.backupDB(
>  db=basedefs.DB_NAME,
> -backup_file=dbBackupFile,
> -env=utils.getPgPassEnv(),
> +backupFile=dbBackupFile,
> +#env=utils.getPgPassEnv(),
>  user=getDbUser(),
>  host=getDbHostName(),
>  port=getDbPort(),
> 
> # engine-setup
> # systemctl stop ovirt-engine
> # psql -U engine engine
> $ update vdc_options set option_value =
> '/etc/pki/ovirt-engine/keys/engine.p12' where option_name = 'keystoreUrl';
> $ update vdc_options set option_value =
> '/etc/pki/ovirt-engine/certs/engine.cer' where option_name =
> 'CertificateFileName';
> $ update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore'
> where option_name = 'TruststoreUrl';
> $ \q
> # cat /dev/null > /var/log/ovirt-engine/engine.log
> # systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log |
> tee /tmp/engine_start.log
> 
> That is the log you now have seen.

And why don't you use engine-upgrade?

I think that in this process you probably remove your existing keys from 
/etc/pki/ovirt-engine

> 
> 
> 
> 
> Thanks,
> Alon
> 
> 
> --
> 
> 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.sjob...@slu.se<mailto:karli.sjob...@adm.slu.se>
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Karli Sjöberg

tor 2013-08-01 klockan 05:29 -0400 skrev Alon Bar-Lev:



- Original Message -
> From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> To: "Alon Bar-Lev" mailto:alo...@redhat.com>>
> Cc: "Alex Lourie" mailto:alou...@redhat.com>>, 
> users@ovirt.org<mailto:users@ovirt.org>, "Eli Mesika" 
> mailto:emes...@redhat.com>>
> Sent: Thursday, August 1, 2013 12:24:57 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> Ah, my bad, I botched that when doing the patch for "engine-setup" and hadn´t
> made an original copy so I did "yum erase" and "yum install" again to get
> back the original file, and yum was nice enough to erase and install blank
> files for me, heh. Now I´m back again and once more updated those option
> values in the database, but I´m still not able to log in. The log is
> attached.

The engine.log you sent is too short for typical log...

Can we start from scratch?
What exactly are you doing?
What sequence?


OK, to make a long story a little shorter. I´m trying to go from oVirt-3.1 to 
oVirt-3.2 on Fedora, so this is what I have done so far:

(After Fedora is up to 18, and the old engine is up and running, I was able to 
log in)
- Erase all of the 3.1-packages
- Install the new 3.2-packages
- Have to go about the dbase upgrade like this:
# psql -U postgres engine
$ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
$ \q
Or the upgrade won´t work. After that it´s possible to:
# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine
(lots of output)
# engine-cleanup --dont-drop-db

- Had to make modifications to "/usr/bin/engine-setup" for the setup to 
complete OK.
@@ -1142,8 +1142,8 @@
 # Run db backup
 utils.backupDB(
 db=basedefs.DB_NAME,
-backup_file=dbBackupFile,
-env=utils.getPgPassEnv(),
+backupFile=dbBackupFile,
+#env=utils.getPgPassEnv(),
 user=getDbUser(),
 host=getDbHostName(),
 port=getDbPort(),

# engine-setup
# systemctl stop ovirt-engine
# psql -U engine engine
$ update vdc_options set option_value = '/etc/pki/ovirt-engine/keys/engine.p12' 
where option_name = 'keystoreUrl';
$ update vdc_options set option_value = 
'/etc/pki/ovirt-engine/certs/engine.cer' where option_name = 
'CertificateFileName';
$ update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore' 
where option_name = 'TruststoreUrl';
$ \q
# cat /dev/null > /var/log/ovirt-engine/engine.log
# systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log | 
tee /tmp/engine_start.log

That is the log you now have seen.




Thanks,
Alon


--

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.sjob...@slu.se<mailto:karli.sjob...@adm.slu.se>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Alon Bar-Lev



- Original Message -
> From: "Karli Sjöberg" 
> To: "Alon Bar-Lev" 
> Cc: "Alex Lourie" , users@ovirt.org, "Eli Mesika" 
> 
> Sent: Thursday, August 1, 2013 12:24:57 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Ah, my bad, I botched that when doing the patch for "engine-setup" and hadn´t
> made an original copy so I did "yum erase" and "yum install" again to get
> back the original file, and yum was nice enough to erase and install blank
> files for me, heh. Now I´m back again and once more updated those option
> values in the database, but I´m still not able to log in. The log is
> attached.

The engine.log you sent is too short for typical log...

Can we start from scratch?
What exactly are you doing?
What sequence?

Thanks,
Alon
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Alon Bar-Lev



- Original Message -
> From: "Karli Sjöberg" 
> To: "Alon Bar-Lev" 
> Cc: "Alex Lourie" , users@ovirt.org, "Eli Mesika" 
> 
> Sent: Thursday, August 1, 2013 11:02:13 AM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> tor 2013-08-01 klockan 03:44 -0400 skrev Alon Bar-Lev:
> 
> 
> 
> - Original Message -
> > From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> > To: "Alon Bar-Lev" mailto:alo...@redhat.com>>
> > Cc: "Alex Lourie" mailto:alou...@redhat.com>>,
> > users@ovirt.org<mailto:users@ovirt.org>
> > Sent: Thursday, August 1, 2013 10:27:02 AM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > ons 2013-07-31 klockan 15:11 -0400 skrev Alon Bar-Lev:
> >
> >
> >
> > - Original Message -
> > > From: "Karli Sjöberg"
> > > mailto:karli.sjob...@slu.se><mailto:karli.sjob...@slu.se>>
> > > To: "Alex Lourie"
> > > mailto:alou...@redhat.com><mailto:alou...@redhat.com>>
> > > Cc: users@ovirt.org<mailto:users@ovirt.org><mailto:users@ovirt.org>
> > > Sent: Wednesday, July 31, 2013 5:10:24 PM
> > > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> > >
> > > Hey!
> > >
> > > Big news for me, I´ve managed to upgrade to 3.2, but sadly, now I can´t
> > > get
> > > it to log in with admin@internal :( This is how I managed it:
> > >
> > > (After Fedora is up to 18)
> > > - Erase all of the 3.1-packages
> > > - Install the new 3.2-packages
> > > - Have to go about the dbase upgrade like this:
> > > # psql -U postgres engine
> > > $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> > > Or the upgrade won´t work. After that it´s possible to:
> > > # cd /usr/share/ovirt-engine/dbscripts
> > > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> > > (lots of output)
> > > # engine-cleanup --dont-drop- db (not dbase)
> > >
> > > - Had to make modifications to "/usr/bin/engine-setup" too:
> > > @@ -1142,8 +1142,8 @@
> > > # Run db backup
> > > utils.backupDB(
> > > db=basedefs.DB_NAME,
> > > - backup_file=dbBackupFile,
> > > - env=utils.getPgPassEnv(),
> > > + backupFile=dbBackupFile,
> > > + #env=utils.getPgPassEnv(),
> > > user=getDbUser(),
> > > host=getDbHostName(),
> > > port=getDbPort(),
> > >
> > > An apparent spelling error and an oversight maybe, the
> > > "backupDB"-function
> > > in
> > > "common-utils.py" doesn´t expect a "env"-variable so I just uncommented
> > > it.
> > > After that it was OK to:
> > > # engine-setup
> > >
> > > No errors. However I was unable to log in so I did:
> > > # systemctl restart ovirt-engine; tail -f
> > > /var/log/ovirt-engine/engine.log
> > > |
> > > tee /tmp/engine_start.log
> > >
> > > Where I was able to see stuff like:
> > > "2013-07-31 15:19:13,300 ERROR
> > > [org.ovirt.engine.core.utils.crypt.EncryptionUtils] (MSC service thread
> > > 1-8)
> > > Can't load keystore from file "/keys/engine.p12". FileNotFoundException:
> > > keys/engine.p12 (No such file or directory)"
> >
> > Yes.
> > There was a bug in tools which ignored the CABaseDirectory option.
> > Please execute the following within engine database:
> >
> > update vdc_options set option_value =
> > '/etc/pki/ovirt-engine/keys/engine.p12'
> > where option_name = 'keystoreUrl';
> > update vdc_options set option_value =
> > '/etc/pki/ovirt-engine/certs/engine.cer' where option_name =
> > 'CertificateFileName';
> > update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore'
> > where option_name = 'TruststoreUrl';
> >
> >
> > OK, done, thanks! Now I just get this printed over and over:
> > 2013-08-01 09:09:04,929 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
> > service thread 1-3) Error in getting DB connection. The database is
> > inaccessible. Original exception is: DataAccessResourceFailureException:
> > Error retreiving database metadata; nested exception is
> > org.springframework.jdbc.support.MetaDataAccessException: Could not get
> > Connection for extracting meta data; nested exception is
> > org.springframe

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Alon Bar-Lev



- Original Message -
> From: "Karli Sjöberg" 
> To: "Alon Bar-Lev" 
> Cc: "Alex Lourie" , users@ovirt.org
> Sent: Thursday, August 1, 2013 10:27:02 AM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> ons 2013-07-31 klockan 15:11 -0400 skrev Alon Bar-Lev:
> 
> 
> 
> - Original Message -
> > From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> > To: "Alex Lourie" mailto:alou...@redhat.com>>
> > Cc: users@ovirt.org<mailto:users@ovirt.org>
> > Sent: Wednesday, July 31, 2013 5:10:24 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Hey!
> >
> > Big news for me, I´ve managed to upgrade to 3.2, but sadly, now I can´t get
> > it to log in with admin@internal :( This is how I managed it:
> >
> > (After Fedora is up to 18)
> > - Erase all of the 3.1-packages
> > - Install the new 3.2-packages
> > - Have to go about the dbase upgrade like this:
> > # psql -U postgres engine
> > $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> > Or the upgrade won´t work. After that it´s possible to:
> > # cd /usr/share/ovirt-engine/dbscripts
> > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> > (lots of output)
> > # engine-cleanup --dont-drop- db (not dbase)
> >
> > - Had to make modifications to "/usr/bin/engine-setup" too:
> > @@ -1142,8 +1142,8 @@
> > # Run db backup
> > utils.backupDB(
> > db=basedefs.DB_NAME,
> > - backup_file=dbBackupFile,
> > - env=utils.getPgPassEnv(),
> > + backupFile=dbBackupFile,
> > + #env=utils.getPgPassEnv(),
> > user=getDbUser(),
> > host=getDbHostName(),
> > port=getDbPort(),
> >
> > An apparent spelling error and an oversight maybe, the "backupDB"-function
> > in
> > "common-utils.py" doesn´t expect a "env"-variable so I just uncommented it.
> > After that it was OK to:
> > # engine-setup
> >
> > No errors. However I was unable to log in so I did:
> > # systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log
> > |
> > tee /tmp/engine_start.log
> >
> > Where I was able to see stuff like:
> > "2013-07-31 15:19:13,300 ERROR
> > [org.ovirt.engine.core.utils.crypt.EncryptionUtils] (MSC service thread
> > 1-8)
> > Can't load keystore from file "/keys/engine.p12". FileNotFoundException:
> > keys/engine.p12 (No such file or directory)"
> 
> Yes.
> There was a bug in tools which ignored the CABaseDirectory option.
> Please execute the following within engine database:
> 
> update vdc_options set option_value = '/etc/pki/ovirt-engine/keys/engine.p12'
> where option_name = 'keystoreUrl';
> update vdc_options set option_value =
> '/etc/pki/ovirt-engine/certs/engine.cer' where option_name =
> 'CertificateFileName';
> update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore'
> where option_name = 'TruststoreUrl';
> 
> 
> OK, done, thanks! Now I just get this printed over and over:
> 2013-08-01 09:09:04,929 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
> service thread 1-3) Error in getting DB connection. The database is
> inaccessible. Original exception is: DataAccessResourceFailureException:
> Error retreiving database metadata; nested exception is
> org.springframework.jdbc.support.MetaDataAccessException: Could not get
> Connection for extracting meta data; nested exception is
> org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get
> JDBC Connection; nested exception is java.sql.SQLException:
> javax.resource.ResourceException: IJ000453: Unable to get managed connection
> for java:/ENGINEDataSource
> 
> What now?
> 

This I do not know...

What do you have at:
/etc/ovirt-engine/.pgpass
/etc/sysconfig/ovirt-engine

> 
> 
> 
> >
> > Although the file does exist (freshly created during "engine-setup") and is
> > located exactly where it should be, in "/etc/pki/ovirt-engine/keys".
> >
> > Files attached.
> >
> > Any ideas?
> >
> > /Karli
> >
> > tor 2013-07-18 klockan 10:02 + skrev Karli Sjöberg:
> >
> >
> > Hi Alex,
> >
> > since I´m on vacation I haven´t been as active as I usually am, but I
> > haven´t
> > stopped working. Good to hear about the certificates, and about
> > "--dont-drop-database". I´m going to contact one of my co-workers and have
> > him try the folowing scenario:
> >
> > 1) Have a

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-08-01 Thread Karli Sjöberg

ons 2013-07-31 klockan 15:11 -0400 skrev Alon Bar-Lev:



- Original Message -
> From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> To: "Alex Lourie" mailto:alou...@redhat.com>>
> Cc: users@ovirt.org<mailto:users@ovirt.org>
> Sent: Wednesday, July 31, 2013 5:10:24 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> Hey!
>
> Big news for me, I´ve managed to upgrade to 3.2, but sadly, now I can´t get
> it to log in with admin@internal :( This is how I managed it:
>
> (After Fedora is up to 18)
> - Erase all of the 3.1-packages
> - Install the new 3.2-packages
> - Have to go about the dbase upgrade like this:
> # psql -U postgres engine
> $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> Or the upgrade won´t work. After that it´s possible to:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> (lots of output)
> # engine-cleanup --dont-drop- db (not dbase)
>
> - Had to make modifications to "/usr/bin/engine-setup" too:
> @@ -1142,8 +1142,8 @@
> # Run db backup
> utils.backupDB(
> db=basedefs.DB_NAME,
> - backup_file=dbBackupFile,
> - env=utils.getPgPassEnv(),
> + backupFile=dbBackupFile,
> + #env=utils.getPgPassEnv(),
> user=getDbUser(),
> host=getDbHostName(),
> port=getDbPort(),
>
> An apparent spelling error and an oversight maybe, the "backupDB"-function in
> "common-utils.py" doesn´t expect a "env"-variable so I just uncommented it.
> After that it was OK to:
> # engine-setup
>
> No errors. However I was unable to log in so I did:
> # systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log |
> tee /tmp/engine_start.log
>
> Where I was able to see stuff like:
> "2013-07-31 15:19:13,300 ERROR
> [org.ovirt.engine.core.utils.crypt.EncryptionUtils] (MSC service thread 1-8)
> Can't load keystore from file "/keys/engine.p12". FileNotFoundException:
> keys/engine.p12 (No such file or directory)"

Yes.
There was a bug in tools which ignored the CABaseDirectory option.
Please execute the following within engine database:

update vdc_options set option_value = '/etc/pki/ovirt-engine/keys/engine.p12' 
where option_name = 'keystoreUrl';
update vdc_options set option_value = '/etc/pki/ovirt-engine/certs/engine.cer' 
where option_name = 'CertificateFileName';
update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore' where 
option_name = 'TruststoreUrl';


OK, done, thanks! Now I just get this printed over and over:
2013-08-01 09:09:04,929 ERROR [org.ovirt.engine.core.bll.Backend] (MSC service 
thread 1-3) Error in getting DB connection. The database is inaccessible. 
Original exception is: DataAccessResourceFailureException: Error retreiving 
database metadata; nested exception is 
org.springframework.jdbc.support.MetaDataAccessException: Could not get 
Connection for extracting meta data; nested exception is 
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC 
Connection; nested exception is java.sql.SQLException: 
javax.resource.ResourceException: IJ000453: Unable to get managed connection 
for java:/ENGINEDataSource

What now?





>
> Although the file does exist (freshly created during "engine-setup") and is
> located exactly where it should be, in "/etc/pki/ovirt-engine/keys".
>
> Files attached.
>
> Any ideas?
>
> /Karli
>
> tor 2013-07-18 klockan 10:02 + skrev Karli Sjöberg:
>
>
> Hi Alex,
>
> since I´m on vacation I haven´t been as active as I usually am, but I haven´t
> stopped working. Good to hear about the certificates, and about
> "--dont-drop-database". I´m going to contact one of my co-workers and have
> him try the folowing scenario:
>
> 1) Have a working F17/3.1 system up and running
> 2) Use "fedora-upgrade" up to F18
> 3) "yum erase" all oVirt-packages
> 4) Install the latest 3.2-packages
> 5) Execute:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> # engine-cleanup --dont-drop-database
> 6) "engine-setup"
>
> And see how that goes. First I´m thinking about testing with a "clean", just
> installed engine with essentially nothing in it. And if the procedure proves
> successful, try again from the start but with an engine that has Hosts,
> Storage, VMs and so on added into it.
>
> /Karli
>
> 
> Från: Alex Lourie [ alou...@redhat.com<mailto:alou...@redhat.com> ]
> Skickat: den 14 juli 2013 13:42
> Till: Karli Sjöberg
> Cc: users@ovirt.org<mailto:users@ovirt.org&

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-31 Thread Alon Bar-Lev



- Original Message -
> From: "Karli Sjöberg" 
> To: "Alex Lourie" 
> Cc: users@ovirt.org
> Sent: Wednesday, July 31, 2013 5:10:24 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hey!
> 
> Big news for me, I´ve managed to upgrade to 3.2, but sadly, now I can´t get
> it to log in with admin@internal :( This is how I managed it:
> 
> (After Fedora is up to 18)
> - Erase all of the 3.1-packages
> - Install the new 3.2-packages
> - Have to go about the dbase upgrade like this:
> # psql -U postgres engine
> $ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
> Or the upgrade won´t work. After that it´s possible to:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> (lots of output)
> # engine-cleanup --dont-drop- db (not dbase)
> 
> - Had to make modifications to "/usr/bin/engine-setup" too:
> @@ -1142,8 +1142,8 @@
> # Run db backup
> utils.backupDB(
> db=basedefs.DB_NAME,
> - backup_file=dbBackupFile,
> - env=utils.getPgPassEnv(),
> + backupFile=dbBackupFile,
> + #env=utils.getPgPassEnv(),
> user=getDbUser(),
> host=getDbHostName(),
> port=getDbPort(),
> 
> An apparent spelling error and an oversight maybe, the "backupDB"-function in
> "common-utils.py" doesn´t expect a "env"-variable so I just uncommented it.
> After that it was OK to:
> # engine-setup
> 
> No errors. However I was unable to log in so I did:
> # systemctl restart ovirt-engine; tail -f /var/log/ovirt-engine/engine.log |
> tee /tmp/engine_start.log
> 
> Where I was able to see stuff like:
> "2013-07-31 15:19:13,300 ERROR
> [org.ovirt.engine.core.utils.crypt.EncryptionUtils] (MSC service thread 1-8)
> Can't load keystore from file "/keys/engine.p12". FileNotFoundException:
> keys/engine.p12 (No such file or directory)"

Yes.
There was a bug in tools which ignored the CABaseDirectory option.
Please execute the following within engine database:

update vdc_options set option_value = '/etc/pki/ovirt-engine/keys/engine.p12' 
where option_name = 'keystoreUrl';
update vdc_options set option_value = '/etc/pki/ovirt-engine/certs/engine.cer' 
where option_name = 'CertificateFileName';
update vdc_options set option_value = '/etc/pki/ovirt-engine/.truststore' where 
option_name = 'TruststoreUrl';


> 
> Although the file does exist (freshly created during "engine-setup") and is
> located exactly where it should be, in "/etc/pki/ovirt-engine/keys".
> 
> Files attached.
> 
> Any ideas?
> 
> /Karli
> 
> tor 2013-07-18 klockan 10:02 + skrev Karli Sjöberg:
> 
> 
> Hi Alex,
> 
> since I´m on vacation I haven´t been as active as I usually am, but I haven´t
> stopped working. Good to hear about the certificates, and about
> "--dont-drop-database". I´m going to contact one of my co-workers and have
> him try the folowing scenario:
> 
> 1) Have a working F17/3.1 system up and running
> 2) Use "fedora-upgrade" up to F18
> 3) "yum erase" all oVirt-packages
> 4) Install the latest 3.2-packages
> 5) Execute:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> # engine-cleanup --dont-drop-database
> 6) "engine-setup"
> 
> And see how that goes. First I´m thinking about testing with a "clean", just
> installed engine with essentially nothing in it. And if the procedure proves
> successful, try again from the start but with an engine that has Hosts,
> Storage, VMs and so on added into it.
> 
> /Karli
> 
> 
> Från: Alex Lourie [ alou...@redhat.com ]
> Skickat: den 14 juli 2013 13:42
> Till: Karli Sjöberg
> Cc: users@ovirt.org Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hi Karli
> 
> It's been awhile since we heard from you. Would you mind updating us on your
> status?
> 
> Thanks
> 
> --
> 
> Best regards,
> 
> Alex Lourie
> Software Developer in Integration
> Red Hat
> 
> 
> - Original Message -
> > From: "Alex Lourie" < alou...@redhat.com >
> > To: "Karli Sjöberg" < karli.sjob...@slu.se >
> > Cc: users@ovirt.org > Sent: Wednesday, July 10, 2013 7:16:02 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Hi Karli
> >
> > 'Restore' certificates basically means taking the backup of
> > /etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after
> > installation.
> >
> > --dont-drop-database will do exact

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-31 Thread Itamar Heim

On 07/31/2013 05:10 PM, Karli Sjöberg wrote:

Hey!

Big news for me, I´ve managed to upgrade to 3.2, but sadly, now I can´t
get it to log in with admin@internal <mailto:admin@internal>:( This is
how I managed it:

(After Fedora is up to 18)
- Erase all of the 3.1-packages
- Install the new 3.2-packages
- Have to go about the dbase upgrade like this:
# psql -U postgres engine
$ ALTER FUNCTION uuid_generate_v1() OWNER TO engine;
Or the upgrade won´t work. After that it´s possible to:
# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine
(lots of output)
# engine-cleanup --dont-drop-*db* (not dbase)

- Had to make modifications to "/usr/bin/engine-setup" too:
@@ -1142,8 +1142,8 @@
  # Run db backup
  utils.backupDB(
  db=basedefs.DB_NAME,
-backup_file=dbBackupFile,
-env=utils.getPgPassEnv(),
+backupFile=dbBackupFile,
+#env=utils.getPgPassEnv(),
  user=getDbUser(),
  host=getDbHostName(),
  port=getDbPort(),

An apparent spelling error and an oversight maybe, the
"backupDB"-function in "common-utils.py" doesn´t expect a "env"-variable
so I just uncommented it. After that it was OK to:
# engine-setup

No errors. However I was unable to log in so I did:
# systemctl restart ovirt-engine; tail -f
/var/log/ovirt-engine/engine.log | tee /tmp/engine_start.log

Where I was able to see stuff like:
"2013-07-31 15:19:13,300 ERROR
[org.ovirt.engine.core.utils.crypt.EncryptionUtils] (MSC service thread
1-8) Can't load keystore from file "/keys/engine.p12".
FileNotFoundException: keys/engine.p12 (No such file or directory)"

Although the file does exist (freshly created during "engine-setup") and
is located exactly where it should be, in "/etc/pki/ovirt-engine/keys".

admin password is encrypted with keystore...
check vdc_options table in the db for the path/password it has for this file

Files attached.

Any ideas?

/Karli

tor 2013-07-18 klockan 10:02 + skrev Karli Sjöberg:

Hi Alex,

since I´m on vacation I haven´t been as active as I usually am, but I haven´t stopped 
working. Good to hear about the certificates, and about "--dont-drop-database". 
I´m going to contact one of my co-workers and have him try the folowing scenario:

1) Have a working F17/3.1 system up and running
2) Use "fedora-upgrade" up to F18
3) "yum erase" all oVirt-packages
4) Install the latest 3.2-packages
5) Execute:
# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine
# engine-cleanup --dont-drop-database
6) "engine-setup"

And see how that goes. First I´m thinking about testing with a "clean", just 
installed engine with essentially nothing in it. And if the procedure proves successful, 
try again from the start but with an engine that has Hosts, Storage, VMs and so on added 
into it.

/Karli

Från: Alex Lourie [alou...@redhat.com  <mailto:alou...@redhat.com>]
Skickat: den 14 juli 2013 13:42
Till: Karli Sjöberg
Cc:users@ovirt.org  <mailto:users@ovirt.org>
Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2

Hi Karli

It's been awhile since we heard from you. Would you mind updating us on your 
status?

Thanks

--

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat

- Original Message -
> From: "Alex Lourie" mailto:alou...@redhat.com>>
> To: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> Cc:users@ovirt.org  <mailto:users@ovirt.org>
> Sent: Wednesday, July 10, 2013 7:16:02 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> Hi Karli
>
> 'Restore' certificates basically means taking the backup of
> /etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after
> installation.
>
> --dont-drop-database will do exactly that - leave DB intact; that can be for
> your benefit in some cases.
>
> I'll be happy to hear on your progress.
>
> --
>
> Best regards,
>
> Alex Lourie
> Software Developer in Integration
> Red Hat
>
>
> - Original Message -
> > From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> > To: "Alex Lourie" mailto:alou...@redhat.com>>
> > Cc:users@ovirt.org  <mailto:users@ovirt.org>
> > Sent: Friday, July 5, 2013 8:34:22 PM
> > Subject: SV: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Hi Alex,
> >
> > crappy MS webmail that can´t figure out indents while on vacation, just
> > FYI.
> > Yes, progress is always good:) I would like to have some pointers about nr.
> > 4: Restore certificates. Then I can ask one of my co-workers to test th

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-18 Thread Karli Sjöberg

Hi Alex,

since I´m on vacation I haven´t been as active as I usually am, but I haven´t 
stopped working. Good to hear about the certificates, and about 
"--dont-drop-database". I´m going to contact one of my co-workers and have him 
try the folowing scenario:

1) Have a working F17/3.1 system up and running
2) Use "fedora-upgrade" up to F18
3) "yum erase" all oVirt-packages
4) Install the latest 3.2-packages 
5) Execute:
# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine
# engine-cleanup --dont-drop-database
6) "engine-setup"

And see how that goes. First I´m thinking about testing with a "clean", just 
installed engine with essentially nothing in it. And if the procedure proves 
successful, try again from the start but with an engine that has Hosts, 
Storage, VMs and so on added into it.

/Karli


Från: Alex Lourie [alou...@redhat.com]
Skickat: den 14 juli 2013 13:42
Till: Karli Sjöberg
Cc: users@ovirt.org
Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2

Hi Karli

It's been awhile since we heard from you. Would you mind updating us on your 
status?

Thanks

--

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat


- Original Message -
> From: "Alex Lourie" 
> To: "Karli Sjöberg" 
> Cc: users@ovirt.org
> Sent: Wednesday, July 10, 2013 7:16:02 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> Hi Karli
>
> 'Restore' certificates basically means taking the backup of
> /etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after
> installation.
>
> --dont-drop-database will do exactly that - leave DB intact; that can be for
> your benefit in some cases.
>
> I'll be happy to hear on your progress.
>
> --
>
> Best regards,
>
> Alex Lourie
> Software Developer in Integration
> Red Hat
>
>
> - Original Message -
> > From: "Karli Sjöberg" 
> > To: "Alex Lourie" 
> > Cc: users@ovirt.org
> > Sent: Friday, July 5, 2013 8:34:22 PM
> > Subject: SV: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Hi Alex,
> >
> > crappy MS webmail that can´t figure out indents while on vacation, just
> > FYI.
> > Yes, progress is always good:) I would like to have some pointers about nr.
> > 4: Restore certificates. Then I can ask one of my co-workers to test the
> > procedure and report back. So, restore certs; How to?
> >
> > Or! I saw in another thread there was a "engine-cleanup --dont-drop-dbase"
> > something or other... Is there an equivalent for "engine-setup", like
> > "--dont-touch-dbase"? Or "engine-cleanup --dbase-something" and then
> > "engine-setup" again, and it´ll just play nice with the dbase that´s still
> > there perhaps?
> >
> > /Karli
> >
> > 
> > Från: Alex Lourie [alou...@redhat.com]
> > Skickat: den 30 juni 2013 17:29
> > Till: Karli Sjöberg
> > Cc: users@ovirt.org
> > Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> > Hi Karli
> >
> > On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg 
> > wrote:
> > > Update!
> > >
> > > I have actually made some headway, I managed to get it passed the
> > > database upgrade! As I was looking at the log, I drilled down into
> > > the engine-upgrade script at looked at what it was trying to do,
> > > which was a pythonic way of doing:
> > > # cd /usr/share/ovirt-engine/dbscripts
> > > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> > >
> >
> > Nice progress!
> >
> > >
> > > So I first reinstalled everything (I´ve stopped counting) and an
> > > hour later I was back at just before doing engine-upgrade again. What
> > > I did then was to upgrade ovirt-engine-dbscripts first and ran the
> > > upgrade.sh script manually (which went by smoothly, output also
> > > attached), downgraded all of the ovirt packages back to 3.1.0-4
> > > (because engine-upgrade didn´t think there was any updating to act
> > > upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran
> > > engine-upgrade. That made it pass the database upgrade, yeay! But!
> > > Now it stopped at doing the CA instead... Log is attached.
> > >
> > > What I find strange is the last line of output from the upgrade.sh:
> > > ...
> > > Refreshing materialized views...
> > > Done.
> > > /usr/share/ovirt-engine/dbscripts
> > >
> > >

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-14 Thread Alex Lourie

Hi Karli

It's been awhile since we heard from you. Would you mind updating us on your 
status?

Thanks

-- 

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat


- Original Message -
> From: "Alex Lourie" 
> To: "Karli Sjöberg" 
> Cc: users@ovirt.org
> Sent: Wednesday, July 10, 2013 7:16:02 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hi Karli
> 
> 'Restore' certificates basically means taking the backup of
> /etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after
> installation.
> 
> --dont-drop-database will do exactly that - leave DB intact; that can be for
> your benefit in some cases.
> 
> I'll be happy to hear on your progress.
> 
> --
> 
> Best regards,
> 
> Alex Lourie
> Software Developer in Integration
> Red Hat
> 
> 
> - Original Message -
> > From: "Karli Sjöberg" 
> > To: "Alex Lourie" 
> > Cc: users@ovirt.org
> > Sent: Friday, July 5, 2013 8:34:22 PM
> > Subject: SV: [Users] Fedora upgrading from 3.1 to 3.2
> > 
> > Hi Alex,
> > 
> > crappy MS webmail that can´t figure out indents while on vacation, just
> > FYI.
> > Yes, progress is always good:) I would like to have some pointers about nr.
> > 4: Restore certificates. Then I can ask one of my co-workers to test the
> > procedure and report back. So, restore certs; How to?
> > 
> > Or! I saw in another thread there was a "engine-cleanup --dont-drop-dbase"
> > something or other... Is there an equivalent for "engine-setup", like
> > "--dont-touch-dbase"? Or "engine-cleanup --dbase-something" and then
> > "engine-setup" again, and it´ll just play nice with the dbase that´s still
> > there perhaps?
> > 
> > /Karli
> > 
> > 
> > Från: Alex Lourie [alou...@redhat.com]
> > Skickat: den 30 juni 2013 17:29
> > Till: Karli Sjöberg
> > Cc: users@ovirt.org
> > Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2
> > 
> > Hi Karli
> > 
> > On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg 
> > wrote:
> > > Update!
> > >
> > > I have actually made some headway, I managed to get it passed the
> > > database upgrade! As I was looking at the log, I drilled down into
> > > the engine-upgrade script at looked at what it was trying to do,
> > > which was a pythonic way of doing:
> > > # cd /usr/share/ovirt-engine/dbscripts
> > > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> > >
> > 
> > Nice progress!
> > 
> > >
> > > So I first reinstalled everything (I´ve stopped counting) and an
> > > hour later I was back at just before doing engine-upgrade again. What
> > > I did then was to upgrade ovirt-engine-dbscripts first and ran the
> > > upgrade.sh script manually (which went by smoothly, output also
> > > attached), downgraded all of the ovirt packages back to 3.1.0-4
> > > (because engine-upgrade didn´t think there was any updating to act
> > > upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran
> > > engine-upgrade. That made it pass the database upgrade, yeay! But!
> > > Now it stopped at doing the CA instead... Log is attached.
> > >
> > > What I find strange is the last line of output from the upgrade.sh:
> > > ...
> > > Refreshing materialized views...
> > > Done.
> > > /usr/share/ovirt-engine/dbscripts
> > >
> > > Where the last lines of upgrade.sh are like:
> > > ...
> > > run_upgrade_files
> > >
> > > ret=$?
> > > printf "Done.\n"
> > > exit $ret
> > >
> > > And I looked through run_upgrade_files and couldn´t figure out why
> > > that function would exit with "/usr/share/ovirt-engine/dbscripts"? No
> > > that doesn´t quite add up. Something just doesn´t smell right but I
> > > haven´t figured it out what it is yet,
> > >
> > 
> > I think it is the output from another script that runs the upgrade.sh
> > script. There's a pushd/popd action used in sh scripts to change
> > working folder and then get back to the original one. I think that this
> > is what you see here.
> > 
> > >
> > > About the second error, with handling the CA, it seems like it´s
> > > having trouble connecting to the database after it´s upgrade, but
> > > since the upgrade itself went by OK, I did engine-cleanup,

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-10 Thread Alex Lourie

Hi Karli

'Restore' certificates basically means taking the backup of 
/etc/pki/ovirt-engine/certs and /keys and restoring them into 3.2 after 
installation.

--dont-drop-database will do exactly that - leave DB intact; that can be for 
your benefit in some cases.

I'll be happy to hear on your progress.

-- 

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat


- Original Message -
> From: "Karli Sjöberg" 
> To: "Alex Lourie" 
> Cc: users@ovirt.org
> Sent: Friday, July 5, 2013 8:34:22 PM
> Subject: SV: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hi Alex,
> 
> crappy MS webmail that can´t figure out indents while on vacation, just FYI.
> Yes, progress is always good:) I would like to have some pointers about nr.
> 4: Restore certificates. Then I can ask one of my co-workers to test the
> procedure and report back. So, restore certs; How to?
> 
> Or! I saw in another thread there was a "engine-cleanup --dont-drop-dbase"
> something or other... Is there an equivalent for "engine-setup", like
> "--dont-touch-dbase"? Or "engine-cleanup --dbase-something" and then
> "engine-setup" again, and it´ll just play nice with the dbase that´s still
> there perhaps?
> 
> /Karli
> 
> ____________
> Från: Alex Lourie [alou...@redhat.com]
> Skickat: den 30 juni 2013 17:29
> Till: Karli Sjöberg
> Cc: users@ovirt.org
> Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hi Karli
> 
> On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg 
> wrote:
> > Update!
> >
> > I have actually made some headway, I managed to get it passed the
> > database upgrade! As I was looking at the log, I drilled down into
> > the engine-upgrade script at looked at what it was trying to do,
> > which was a pythonic way of doing:
> > # cd /usr/share/ovirt-engine/dbscripts
> > # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
> >
> 
> Nice progress!
> 
> >
> > So I first reinstalled everything (I´ve stopped counting) and an
> > hour later I was back at just before doing engine-upgrade again. What
> > I did then was to upgrade ovirt-engine-dbscripts first and ran the
> > upgrade.sh script manually (which went by smoothly, output also
> > attached), downgraded all of the ovirt packages back to 3.1.0-4
> > (because engine-upgrade didn´t think there was any updating to act
> > upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran
> > engine-upgrade. That made it pass the database upgrade, yeay! But!
> > Now it stopped at doing the CA instead... Log is attached.
> >
> > What I find strange is the last line of output from the upgrade.sh:
> > ...
> > Refreshing materialized views...
> > Done.
> > /usr/share/ovirt-engine/dbscripts
> >
> > Where the last lines of upgrade.sh are like:
> > ...
> > run_upgrade_files
> >
> > ret=$?
> > printf "Done.\n"
> > exit $ret
> >
> > And I looked through run_upgrade_files and couldn´t figure out why
> > that function would exit with "/usr/share/ovirt-engine/dbscripts"? No
> > that doesn´t quite add up. Something just doesn´t smell right but I
> > haven´t figured it out what it is yet,
> >
> 
> I think it is the output from another script that runs the upgrade.sh
> script. There's a pushd/popd action used in sh scripts to change
> working folder and then get back to the original one. I think that this
> is what you see here.
> 
> >
> > About the second error, with handling the CA, it seems like it´s
> > having trouble connecting to the database after it´s upgrade, but
> > since the upgrade itself went by OK, I did engine-cleanup,
> > engine-setup, stopped engine, restored the database and started
> > engine again, and it worked. Which should point more to something
> > like a configuration being missed, or improperly handled at the
> > upgrade that makes engine-config fail to connect.
> 
> Could be; but the fact that reimport of the DB worked is a very good
> sign.
> 
> > Maybe some old configurations lying around that shouldn´t be, that
> > hinders it, I don´t know. Is there anything handling configuration
> > changes, like "rpmconf -a" in the upgrade process, after updating the
> > rpms?
> >
> 
> No, we do not have rpmconf in ovirt.
> 
> Now, if you have a working engine, that's good. Remember though that
> you started with clean DB. When DB has entries, the upgrade.sh run may
> not be as fluent as it was before. But, if it works, I guess you could
> use the same s

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-07-05 Thread Karli Sjöberg

Hi Alex,

crappy MS webmail that can´t figure out indents while on vacation, just FYI. 
Yes, progress is always good:) I would like to have some pointers about nr. 4: 
Restore certificates. Then I can ask one of my co-workers to test the procedure 
and report back. So, restore certs; How to?

Or! I saw in another thread there was a "engine-cleanup --dont-drop-dbase" 
something or other... Is there an equivalent for "engine-setup", like 
"--dont-touch-dbase"? Or "engine-cleanup --dbase-something" and then 
"engine-setup" again, and it´ll just play nice with the dbase that´s still 
there perhaps?

/Karli

Från: Alex Lourie [alou...@redhat.com]
Skickat: den 30 juni 2013 17:29
Till: Karli Sjöberg
Cc: users@ovirt.org
Ämne: Re: [Users] Fedora upgrading from 3.1 to 3.2

Hi Karli

On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg 
wrote:
> Update!
>
> I have actually made some headway, I managed to get it passed the
> database upgrade! As I was looking at the log, I drilled down into
> the engine-upgrade script at looked at what it was trying to do,
> which was a pythonic way of doing:
> # cd /usr/share/ovirt-engine/dbscripts
> # ./upgrade.sh -s localhost -p 5432 -u engine -d engine
>

Nice progress!

>
> So I first reinstalled everything (I´ve stopped counting) and an
> hour later I was back at just before doing engine-upgrade again. What
> I did then was to upgrade ovirt-engine-dbscripts first and ran the
> upgrade.sh script manually (which went by smoothly, output also
> attached), downgraded all of the ovirt packages back to 3.1.0-4
> (because engine-upgrade didn´t think there was any updating to act
> upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran
> engine-upgrade. That made it pass the database upgrade, yeay! But!
> Now it stopped at doing the CA instead... Log is attached.
>
> What I find strange is the last line of output from the upgrade.sh:
> ...
> Refreshing materialized views...
> Done.
> /usr/share/ovirt-engine/dbscripts
>
> Where the last lines of upgrade.sh are like:
> ...
> run_upgrade_files
>
> ret=$?
> printf "Done.\n"
> exit $ret
>
> And I looked through run_upgrade_files and couldn´t figure out why
> that function would exit with "/usr/share/ovirt-engine/dbscripts"? No
> that doesn´t quite add up. Something just doesn´t smell right but I
> haven´t figured it out what it is yet,
>

I think it is the output from another script that runs the upgrade.sh
script. There's a pushd/popd action used in sh scripts to change
working folder and then get back to the original one. I think that this
is what you see here.

>
> About the second error, with handling the CA, it seems like it´s
> having trouble connecting to the database after it´s upgrade, but
> since the upgrade itself went by OK, I did engine-cleanup,
> engine-setup, stopped engine, restored the database and started
> engine again, and it worked. Which should point more to something
> like a configuration being missed, or improperly handled at the
> upgrade that makes engine-config fail to connect.

Could be; but the fact that reimport of the DB worked is a very good
sign.

> Maybe some old configurations lying around that shouldn´t be, that
> hinders it, I don´t know. Is there anything handling configuration
> changes, like "rpmconf -a" in the upgrade process, after updating the
> rpms?
>

No, we do not have rpmconf in ovirt.

Now, if you have a working engine, that's good. Remember though that
you started with clean DB. When DB has entries, the upgrade.sh run may
not be as fluent as it was before. But, if it works, I guess you could
use the same strategy for upgrading the complete working environment:

1. Backup DB and certificates
2. Upgrade DB in a stand-alone mode and save it aside.
3. Install 3.2, restore the engine DB from upgraded backup.
4. Restore certificates.
5. Start the engine.
6. Enjoy?

Let me know what your status is.

>
> /Karli
>
> ons 2013-06-26 klockan 13:33 + skrev Karli Sjöberg:
>> tis 2013-06-25 klockan 16:02 +0003 skrev Alex Lourie: 
>>> On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg
>>> 
>>> wrote:
>>> > tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi: On
>>> Tue,
>>> > Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:
>>> >  
>>> >>>
>>> >>>
>>> >  Yes, I had much better success following that article, and
>>> managed
>>> > to upgrade fedora to 18, had to tune my kernel parameters a
>>> little
>>> > for the postgres upgrade to work, but then engine-upgrade fails
>>> just
>>> > as it did the last t

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-30 Thread Alex Lourie

Hi Karli

On Wed, Jun 26, 2013 at 5:28 PM, Karli Sjöberg  
wrote:

Update!

I have actually made some headway, I managed to get it passed the 
database upgrade! As I was looking at the log, I drilled down into 
the engine-upgrade script at looked at what it was trying to do, 
which was a pythonic way of doing:

# cd /usr/share/ovirt-engine/dbscripts
# ./upgrade.sh -s localhost -p 5432 -u engine -d engine

Nice progress!

So I first reinstalled everything (I´ve stopped counting) and an 
hour later I was back at just before doing engine-upgrade again. What 
I did then was to upgrade ovirt-engine-dbscripts first and ran the 
upgrade.sh script manually (which went by smoothly, output also 
attached), downgraded all of the ovirt packages back to 3.1.0-4 
(because engine-upgrade didn´t think there was any updating to act 
upon otherwise), then updated ovirt-engine-setup to 3.2.2, lastly ran 
engine-upgrade. That made it pass the database upgrade, yeay! But! 
Now it stopped at doing the CA instead... Log is attached.

What I find strange is the last line of output from the upgrade.sh:
...
Refreshing materialized views...
Done.
/usr/share/ovirt-engine/dbscripts

Where the last lines of upgrade.sh are like:
...
run_upgrade_files

ret=$?
printf "Done.\n"
exit $ret

And I looked through run_upgrade_files and couldn´t figure out why 
that function would exit with "/usr/share/ovirt-engine/dbscripts"? No 
that doesn´t quite add up. Something just doesn´t smell right but I 
haven´t figured it out what it is yet,

I think it is the output from another script that runs the upgrade.sh 
script. There's a pushd/popd action used in sh scripts to change 
working folder and then get back to the original one. I think that this 
is what you see here.

About the second error, with handling the CA, it seems like it´s 
having trouble connecting to the database after it´s upgrade, but 
since the upgrade itself went by OK, I did engine-cleanup, 
engine-setup, stopped engine, restored the database and started 
engine again, and it worked. Which should point more to something 
like a configuration being missed, or improperly handled at the 
upgrade that makes engine-config fail to connect.

Could be; but the fact that reimport of the DB worked is a very good 
sign.

Maybe some old configurations lying around that shouldn´t be, that 
hinders it, I don´t know. Is there anything handling configuration 
changes, like "rpmconf -a" in the upgrade process, after updating the 
rpms?

No, we do not have rpmconf in ovirt.

Now, if you have a working engine, that's good. Remember though that 
you started with clean DB. When DB has entries, the upgrade.sh run may 
not be as fluent as it was before. But, if it works, I guess you could 
use the same strategy for upgrading the complete working environment:

1. Backup DB and certificates
2. Upgrade DB in a stand-alone mode and save it aside.
3. Install 3.2, restore the engine DB from upgraded backup.
4. Restore certificates.
5. Start the engine.
6. Enjoy?

Let me know what your status is.

/Karli

ons 2013-06-26 klockan 13:33 + skrev Karli Sjöberg:

tis 2013-06-25 klockan 16:02 +0003 skrev Alex Lourie: 
On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg 

wrote:
> tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi: On 
Tue, 
> Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:

>  
>>> 
>>> 
>  Yes, I had much better success following that article, and 
managed 
> to upgrade fedora to 18, had to tune my kernel parameters a 
little 
> for the postgres upgrade to work, but then engine-upgrade fails 
just 
> as it did the last time we tried. The log is attached. Hoping to 
hear 
> back from you soon with ideas on what to try next.

>  
>>> 
>>> 
>>> 
>  
>> 
>> 
>  But now the error seems different from the original one in 
March 
> (if I remember correctly the original post).
>> 
>  
> They are quite the same:
> 
> Then
> psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop 
function 
> uuid_nil() because extension uuid-ossp requires it
> 
> Now
> 2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
> psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop 
function 
> uuid_nil() because extension uuid-ossp requires it
> 
>> Could it be somehow related with this rhev one bug:

>  https://bugzilla.redhat.com/show_bug.cgi?id=923614
>> 
>> 
>  and that changing permissions for the impacted objects in db 
before 
> running upgrade could help?

I have now tried that and it did no change in success there 
unfortunately, so it´s probably not anything permissions related in 
the database.

dbmodify:
#!/bin/sh
export PGPASSFILE=/root/.pgpass
for tbl in `psql -U postgres -wqAt -c "select tablename from 
pg_tables where schemaname = 'public';" engine` ; do  psql -U 
postgres -c "alter table $tbl owner to engine" engine ; done
for tbl in `psql -U postgres -wqAt -c "select sequence_name from 
information_schema.sequences where sequence_schema = 'public';" 
engine`

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-26 Thread Alex Lourie




On Tue, Jun 25, 2013 at 7:07 PM, Matthew Curry  
wrote:
Has anyone tried 3.1 to 3.2 in CentOS? or even 3.1 to 
3.3rc/beta/etc?? I 
am going to be forced down that path soon; so I am wondering what 
kind 
of hurt I am in for...

Lol...



Hi Matthew

I suspect your mileage will be much smoother due to much smaller 
changes between CentOS released compared to Fedora :-)




Thanks,
Matthew Curry

On 6/25/13 8:40 AM, Alex Lourie wrote:
> Hi Eli
>
> The following is the error we're getting when upgrading upstream 
3.1 
> to 3.2:

>
> 2013-06-25 14:52:11::DEBUG::common_utils::434::root:: Executing 
> command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s 
localhost 
> -p 5432 -u engine -d engine_2013_06_25_14_49_31'
> 2013-06-25 14:52:16::DEBUG::common_utils::472::root:: output = 
> /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> upgrade script detected a change in Config, View or Stored 
Procedure...

>
> 2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
> psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function 
> uuid_nil() because extension uuid-ossp requires it

> HINT:  You can drop extension uuid-ossp instead.
> CONTEXT:  SQL statement "drop function if exists  uuid_nil()"
> PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL 
> statement
> psql:create_functions.sql:671: ERROR:  must be owner of function 
> uuid_generate_v1

>
>
> Any idea how can we fix it manually?
>
> Thanks,
> Alex.
>
> On Tue, Jun 25, 2013 at 3:58 PM, Karli Sjöberg 
 
> wrote:
>> tis 2013-06-25 klockan 14:59 +0300 skrev Moran Goldboim: On 
>> 06/25/2013 02:52 PM, Alex Lourie wrote:

>>> >
>>> > On Tue, Jun 25, 2013 at 1:31 PM, Karli Sjöberg 
>>>  > wrote:

>>> >> mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie: 
>>> >>> On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg >>> 
>>>  wrote:

>>> >>> > mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>>> >>> >> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg >> >>> 
>>>  >> wrote:
>>> >>> >> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: 
Hi 
>>> Karli
>>> >>> >> >> >> >> I've written up all we know at [1], please try to 
>>> follow >>> it (if >> you >> >> haven't yet) and let us know how 
it 
>>> goes. If >>> anything goes wrong, >> we >> >> will look for the 
ways 
>>> to resolve it.

>>> >>> >> >> >> >  >> > Hi Alex!
>>> >>> >> > >> > Awesome job, I´m going to test this right away and 
let 
>>> you >>> know >> how >> > it goes. Wish me luck;)

>>> >>> >> > >> >> Good luck! May the force be with you.
>>> >>> >> >  > No no, the source Alex, the source:)
>>> >>> > > /K
>>> >>> >
>>> >>> Sure, that one too.
>>> >>>
>>> >>>
>>> >
>>> > Hi Karli
>>> >
>>> >>
>>> >> Well, it wasn´t with me for long, I have hit BZ 911939 and 
>>> 901786, >> where fedup fails to find my LVM volumes. In the 
dracut 
>>> shell (to >> where it gets dropped), I have good output from 
blkid 
>>> and lvm >> pvs|vgs|lvs but no nodes created in /dev/mapper and so 
>>> the system >> cannot boot and upgrade fails. Do you have any 
>>> suggestions there that >> might help? In the mean time, I´ll try 
>>> upgrading using >> 
>>> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, 
>>> see >> if that gives better success.

>>> >>
>>> >
>>> > Sorry to hear that. Different people have experienced multiple 
> 
>>> problems upgrading lvm-based F17 systems to F18. I don't think 
that 
>>> > there's a magic solution that would just work, each case is 
>>> usually > solved on its own.

>>> >
>>> > Let us know how you progress with upgrading with yum.
>>> >
>>> > Alex.
>>>
>>> i used same article [1] and had a successful go with it - good 
luck...

>>>
>>> [1] 
>>> 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 
>>>

>>>
>>> >
>>> >>
>>> >> -- >>
>>> >> 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.sjob...@slu.se
>>> >
>>>
>>>
>>
>> Yes, I had much better success following that article, and managed 
to 
>> upgrade fedora to 18, had to tune my kernel parameters a little 
for 
>> the postgres upgrade to work, but then engine-upgrade fails just 
as 
>> it did the last time we tried. The log is attached. Hoping to hear 
>> back from you soon with ideas on what to try next.

>>
>> -- 
>>

>> 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.sjob...@slu.se
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Matthew Curry

Has anyone tried 3.1 to 3.2 in CentOS? or even 3.1 to 3.3rc/beta/etc?? I 
am going to be forced down that path soon; so I am wondering what kind 
of hurt I am in for...

Lol...

Thanks,
Matthew Curry

On 6/25/13 8:40 AM, Alex Lourie wrote:

Hi Eli

The following is the error we're getting when upgrading upstream 3.1 
to 3.2:


2013-06-25 14:52:11::DEBUG::common_utils::434::root:: Executing 
command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s localhost 
-p 5432 -u engine -d engine_2013_06_25_14_49_31'
2013-06-25 14:52:16::DEBUG::common_utils::472::root:: output = 
/usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts

upgrade script detected a change in Config, View or Stored Procedure...

2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function 
uuid_nil() because extension uuid-ossp requires it

HINT:  You can drop extension uuid-ossp instead.
CONTEXT:  SQL statement "drop function if exists  uuid_nil()"
PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL 
statement
psql:create_functions.sql:671: ERROR:  must be owner of function 
uuid_generate_v1



Any idea how can we fix it manually?

Thanks,
Alex.

On Tue, Jun 25, 2013 at 3:58 PM, Karli Sjöberg  
wrote:
tis 2013-06-25 klockan 14:59 +0300 skrev Moran Goldboim: On 
06/25/2013 02:52 PM, Alex Lourie wrote:

>
> On Tue, Jun 25, 2013 at 1:31 PM, Karli Sjöberg 
 > wrote:

>> mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie: 
>>> On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg >>> 
 wrote:

>>> > mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>>> >> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg >> >>> 
 >> wrote:
>>> >> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi 
Karli
>>> >> >> >> >> I've written up all we know at [1], please try to 
follow >>> it (if >> you >> >> haven't yet) and let us know how it 
goes. If >>> anything goes wrong, >> we >> >> will look for the ways 
to resolve it.

>>> >> >> >> >  >> > Hi Alex!
>>> >> > >> > Awesome job, I´m going to test this right away and let 
you >>> know >> how >> > it goes. Wish me luck;)

>>> >> > >> >> Good luck! May the force be with you.
>>> >> >  > No no, the source Alex, the source:)
>>> > > /K
>>> >
>>> Sure, that one too.
>>>
>>>
>
> Hi Karli
>
>>
>> Well, it wasn´t with me for long, I have hit BZ 911939 and 
901786, >> where fedup fails to find my LVM volumes. In the dracut 
shell (to >> where it gets dropped), I have good output from blkid 
and lvm >> pvs|vgs|lvs but no nodes created in /dev/mapper and so 
the system >> cannot boot and upgrade fails. Do you have any 
suggestions there that >> might help? In the mean time, I´ll try 
upgrading using >> 
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, 
see >> if that gives better success.

>>
>
> Sorry to hear that. Different people have experienced multiple > 
problems upgrading lvm-based F17 systems to F18. I don't think that 
> there's a magic solution that would just work, each case is 
usually > solved on its own.

>
> Let us know how you progress with upgrading with yum.
>
> Alex.

i used same article [1] and had a successful go with it - good luck...

[1] 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 



>
>>
>> -- >>
>> 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.sjob...@slu.se
>




Yes, I had much better success following that article, and managed to 
upgrade fedora to 18, had to tune my kernel parameters a little for 
the postgres upgrade to work, but then engine-upgrade fails just as 
it did the last time we tried. The log is attached. Hoping to hear 
back from you soon with ideas on what to try next.


--

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.sjob...@slu.se


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Alex Lourie




On Tue, Jun 25, 2013 at 5:03 PM, Karli Sjöberg  
wrote:
tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi: On Tue, 
Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:

 



 Yes, I had much better success following that article, and managed 
to upgrade fedora to 18, had to tune my kernel parameters a little 
for the postgres upgrade to work, but then engine-upgrade fails just 
as it did the last time we tried. The log is attached. Hoping to hear 
back from you soon with ideas on what to try next.

 





 



 But now the error seems different from the original one in March 
(if I remember correctly the original post).


 
They are quite the same:


Then
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function 
uuid_nil() because extension uuid-ossp requires it


Now
2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function 
uuid_nil() because extension uuid-ossp requires it



Could it be somehow related with this rhev one bug:

 https://bugzilla.redhat.com/show_bug.cgi?id=923614



 and that changing permissions for the impacted objects in db before 
running upgrade could help?


 
Very interesting, thanks for the hint! That is definitely worth 
trying out. Will try that first thing tomorrow:)


Hi Karli

If it helps, let me know - I will add a troubleshooting section to the 
wiki.









 BTW: is your environment directly created in 3.1 or did it come 
from a further upgrade? 


 
Started with a minimal Fedora 17 install, added the oVirt-3.1 repo, 
ran yum upgrade -y first, then yum install -y ovirt-engine and lastly 
engine-setup. Nothing more. So it´s just an empty engine that I´m 
trying to upgrade at this point. When that works, I´ll add hosts, 
VMs, Templates, etc.







 HIH,
 Gianluca
 
--


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.sjob...@slu.se


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Karli Sjöberg

tis 2013-06-25 klockan 15:35 +0200 skrev Gianluca Cecchi:
On Tue, Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:


Yes, I had much better success following that article, and managed to upgrade 
fedora to 18, had to tune my kernel parameters a little for the postgres 
upgrade to work, but then engine-upgrade fails just as it did the last time we 
tried. The log is attached. Hoping to hear back from you soon with ideas on 
what to try next.





But now the error seems different from the original one in March (if I remember 
correctly the original post).

They are quite the same:

Then
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function uuid_nil() 
because extension uuid-ossp requires it

Now
2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function uuid_nil() 
because extension uuid-ossp requires it

Could it be somehow related with this rhev one bug:
https://bugzilla.redhat.com/show_bug.cgi?id=923614

and that changing permissions for the impacted objects in db before running 
upgrade could help?

Very interesting, thanks for the hint! That is definitely worth trying out. 
Will try that first thing tomorrow:)



BTW: is your environment directly created in 3.1 or did it come from a further 
upgrade?

Started with a minimal Fedora 17 install, added the oVirt-3.1 repo, ran yum 
upgrade -y first, then yum install -y ovirt-engine and lastly engine-setup. 
Nothing more. So it´s just an empty engine that I´m trying to upgrade at this 
point. When that works, I´ll add hosts, VMs, Templates, etc.



HIH,
Gianluca

--

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.sjob...@slu.se
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Alex Lourie


Hi Eli

The following is the error we're getting when upgrading upstream 3.1 to 
3.2:


2013-06-25 14:52:11::DEBUG::common_utils::434::root:: Executing command 
--> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s localhost -p 5432 
-u engine -d engine_2013_06_25_14_49_31'
2013-06-25 14:52:16::DEBUG::common_utils::472::root:: output = 
/usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts

upgrade script detected a change in Config, View or Stored Procedure...

2013-06-25 14:52:16::DEBUG::common_utils::473::root:: stderr = 
psql:drop_old_uuid_functions.sql:25: ERROR:  cannot drop function 
uuid_nil() because extension uuid-ossp requires it

HINT:  You can drop extension uuid-ossp instead.
CONTEXT:  SQL statement "drop function if exists  uuid_nil()"
PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL 
statement
psql:create_functions.sql:671: ERROR:  must be owner of function 
uuid_generate_v1



Any idea how can we fix it manually?

Thanks,
Alex.

On Tue, Jun 25, 2013 at 3:58 PM, Karli Sjöberg  
wrote:
tis 2013-06-25 klockan 14:59 +0300 skrev Moran Goldboim: On 
06/25/2013 02:52 PM, Alex Lourie wrote:

>
> On Tue, Jun 25, 2013 at 1:31 PM, Karli Sjöberg 
 
> wrote:

>> mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie: 
>>> On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg 
>>>  wrote:

>>> > mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>>> >> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg >> 
>>>  >> wrote:
>>> >> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi 
Karli
>>> >> >> >> >> I've written up all we know at [1], please try to 
follow 
>>> it (if >> you >> >> haven't yet) and let us know how it goes. If 
>>> anything goes wrong, >> we >> >> will look for the ways to 
resolve it.

>>> >> >> >> >  >> > Hi Alex!
>>> >> > >> > Awesome job, I´m going to test this right away and 
let you 
>>> know >> how >> > it goes. Wish me luck;)

>>> >> > >> >> Good luck! May the force be with you.
>>> >> >  > No no, the source Alex, the source:)
>>> > > /K
>>> >
>>> Sure, that one too.
>>>
>>>
>
> Hi Karli
>
>>
>> Well, it wasn´t with me for long, I have hit BZ 911939 and 
901786, 
>> where fedup fails to find my LVM volumes. In the dracut shell (to 
>> where it gets dropped), I have good output from blkid and lvm 
>> pvs|vgs|lvs but no nodes created in /dev/mapper and so the system 
>> cannot boot and upgrade fails. Do you have any suggestions there 
that 
>> might help? In the mean time, I´ll try upgrading using 
>> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, 
see 
>> if that gives better success.

>>
>
> Sorry to hear that. Different people have experienced multiple 
> problems upgrading lvm-based F17 systems to F18. I don't think 
that 
> there's a magic solution that would just work, each case is 
usually 
> solved on its own.

>
> Let us know how you progress with upgrading with yum.
>
> Alex.

i used same article [1] and had a successful go with it - good 
luck...


[1] 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 



>
>>
>> -- 
>>

>> 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.sjob...@slu.se
>


 
Yes, I had much better success following that article, and managed to 
upgrade fedora to 18, had to tune my kernel parameters a little for 
the postgres upgrade to work, but then engine-upgrade fails just as 
it did the last time we tried. The log is attached. Hoping to hear 
back from you soon with ideas on what to try next.


--

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.sjob...@slu.se


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Gianluca Cecchi

On Tue, Jun 25, 2013 at 2:58 PM, Karli Sjöberg wrote:

> **
>
>
> Yes, I had much better success following that article, and managed to
> upgrade fedora to 18, had to tune my kernel parameters a little for the
> postgres upgrade to work, but then engine-upgrade fails just as it did the
> last time we tried. The log is attached. Hoping to hear back from you soon
> with ideas on what to try next.
>
>
>
But now the error seems different from the original one in March (if I
remember correctly the original post).
Could it be somehow related with this rhev one bug:
https://bugzilla.redhat.com/show_bug.cgi?id=923614
and that changing permissions for the impacted objects in db before running
upgrade could help?

BTW: is your environment directly created in 3.1 or did it come from a
further upgrade?

HIH,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Moran Goldboim

On 06/25/2013 02:52 PM, Alex Lourie wrote:

On Tue, Jun 25, 2013 at 1:31 PM, Karli Sjöberg  
wrote:

mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie: 
On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg 
 wrote:

> mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg >> 
 >> wrote:

>> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi Karli
>> >> >> >> I've written up all we know at [1], please try to follow 
it (if >> you >> >> haven't yet) and let us know how it goes. If 
anything goes wrong, >> we >> >> will look for the ways to resolve it.

>> >> >> >  >> > Hi Alex!
>> > >> > Awesome job, I´m going to test this right away and let you 
know >> how >> > it goes. Wish me luck;)

>> > >> >> Good luck! May the force be with you.
>> >  > No no, the source Alex, the source:)
> > /K
>
Sure, that one too.

Hi Karli

Well, it wasn´t with me for long, I have hit BZ 911939 and 901786, 
where fedup fails to find my LVM volumes. In the dracut shell (to 
where it gets dropped), I have good output from blkid and lvm 
pvs|vgs|lvs but no nodes created in /dev/mapper and so the system 
cannot boot and upgrade fails. Do you have any suggestions there that 
might help? In the mean time, I´ll try upgrading using 
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, see 
if that gives better success.

Sorry to hear that. Different people have experienced multiple 
problems upgrading lvm-based F17 systems to F18. I don't think that 
there's a magic solution that would just work, each case is usually 
solved on its own.

Let us know how you progress with upgrading with yum.

Alex.

i used same article [1] and had a successful go with it - good luck...

[1] 
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 

--

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.sjob...@slu.se

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Alex Lourie

On Tue, Jun 25, 2013 at 1:31 PM, Karli Sjöberg  
wrote:

mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie: 
On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg 

wrote:

> mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg 
>>  
>> wrote:

>> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi Karli
>> >> 
>> >> I've written up all we know at [1], please try to follow it 
(if 
>> you 
>> >> haven't yet) and let us know how it goes. If anything goes 
wrong, 
>> we 
>> >> will look for the ways to resolve it.
>> >> 
>> >  
>> > Hi Alex!
>> > 
>> > Awesome job, I´m going to test this right away and let you 
know 
>> how 
>> > it goes. Wish me luck;)
>> > 
>> 
>> Good luck! May the force be with you.
>> 
>  
> No no, the source Alex, the source:)
> 
> /K
> 

Sure, that one too.

Hi Karli

Well, it wasn´t with me for long, I have hit BZ 911939 and 901786, 
where fedup fails to find my LVM volumes. In the dracut shell (to 
where it gets dropped), I have good output from blkid and lvm 
pvs|vgs|lvs but no nodes created in /dev/mapper and so the system 
cannot boot and upgrade fails. Do you have any suggestions there that 
might help? In the mean time, I´ll try upgrading using 
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, see 
if that gives better success.

Sorry to hear that. Different people have experienced multiple problems 
upgrading lvm-based F17 systems to F18. I don't think that there's a 
magic solution that would just work, each case is usually solved on its 
own.

Let us know how you progress with upgrading with yum.

Alex.

--

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.sjob...@slu.se

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-25 Thread Karli Sjöberg

mån 2013-06-24 klockan 12:35 +0003 skrev Alex Lourie:

On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg 
mailto:karli.sjob...@slu.se>>
wrote:
> mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
>> On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg
>> mailto:karli.sjob...@slu.se>>
>> wrote:
>> > sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi Karli
>> >>
>> >> I've written up all we know at [1], please try to follow it (if
>> you
>> >> haven't yet) and let us know how it goes. If anything goes wrong,
>> we
>> >> will look for the ways to resolve it.
>> >>
>> >
>> > Hi Alex!
>> >
>> > Awesome job, I´m going to test this right away and let you know
>> how
>> > it goes. Wish me luck;)
>> >
>>
>> Good luck! May the force be with you.
>>
>
> No no, the source Alex, the source:)
>
> /K
>

Sure, that one too.

Well, it wasn´t with me for long, I have hit BZ 911939 and 901786, where fedup 
fails to find my LVM volumes. In the dracut shell (to where it gets dropped), I 
have good output from blkid and lvm pvs|vgs|lvs but no nodes created in 
/dev/mapper and so the system cannot boot and upgrade fails. Do you have any 
suggestions there that might help? In the mean time, I´ll try upgrading using 
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum instead, see if that 
gives better success.

--

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.sjob...@slu.se
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-24 Thread Moran Goldboim


On 06/23/2013 10:08 PM, Alfred Angelov wrote:

Hey,

This might sounds like a foolish question, but from the link you 
mentioned:


oVirt 3.1 was released as Fedora 17 package while 3.2 is targeted 
Fedora 18. Due to the nature of this upgrade, we DO NOT recommend it, 
users are advised to do a 3.2 clean installation, and to import all 
VM's and template into the new installation. 


Is there anything special I would have to do to import all the VMs 
(around 40) from my ovirt 3.1.0-2 to another ovirt (which runs 3.2.2) ?


you should:
-create and attach an export domain to the relevant datacenter on your 
3.1 system

-export the vms you need to the export domain
-disconnect the export domain
-import the domain on your 3.2.2 system (from storage tab)
-import the vms to the relevant datacenter



Mvh, Alfred Angelov

On 06/23/2013 11:35 AM, Alex Lourie wrote:

Hi Karli

I've written up all we know at [1], please try to follow it (if you 
haven't yet) and let us know how it goes. If anything goes wrong, we 
will look for the ways to resolve it.


Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie  wrote:

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 
 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 
  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

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-24 Thread Alex Lourie




On Mon, Jun 24, 2013 at 2:09 PM, Karli Sjöberg  
wrote:

mån 2013-06-24 klockan 10:54 +0003 skrev Alex Lourie: 
On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg 
 
wrote:

> sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi Karli
>> 
>> I've written up all we know at [1], please try to follow it (if 
you 
>> haven't yet) and let us know how it goes. If anything goes wrong, 
we 
>> will look for the ways to resolve it.
>> 
>  
> Hi Alex!
> 
> Awesome job, I´m going to test this right away and let you know 
how 
> it goes. Wish me luck;)
> 


Good luck! May the force be with you.

 
No no, the source Alex, the source:)


/K



Sure, that one too.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-24 Thread Alex Lourie




On Mon, Jun 24, 2013 at 1:26 PM, Karli Sjöberg  
wrote:

sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie: Hi Karli


I've written up all we know at [1], please try to follow it (if you 
haven't yet) and let us know how it goes. If anything goes wrong, we 
will look for the ways to resolve it.


 
Hi Alex!


Awesome job, I´m going to test this right away and let you know how 
it goes. Wish me luck;)




Good luck! May the force be with you.

Alex.



/Karli



Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie  
wrote:

> 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 
>  
> 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  
>  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

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-24 Thread Karli Sjöberg

sön 2013-06-23 klockan 09:38 +0003 skrev Alex Lourie:


Hi Karli

I've written up all we know at [1], please try to follow it (if you
haven't yet) and let us know how it goes. If anything goes wrong, we
will look for the ways to resolve it.


Hi Alex!

Awesome job, I´m going to test this right away and let you know how it goes. 
Wish me luck;)

/Karli




Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie 
mailto:alou...@redhat.com>> wrote:
> 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
> mailto:karli.sjob...@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 
> > 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 o

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-23 Thread Alex Lourie


Hi Alfred

On Sun, Jun 23, 2013 at 10:08 PM, Alfred Angelov  
wrote:

Hey,

This might sounds like a foolish question, but from the link you 
mentioned:


oVirt 3.1 was released as Fedora 17 package while 3.2 is targeted 
Fedora 18. Due to the nature of this upgrade, we DO NOT recommend 
it, users are advised to do a 3.2 clean installation, and to import 
all VM's and template into the new installation. 

Is there anything special I would have to do to import all the VMs 
(around 40) from my ovirt 3.1.0-2 to another ovirt (which runs 3.2.2) 
?




No, just usual import should work.



Mvh, Alfred Angelov

On 06/23/2013 11:35 AM, Alex Lourie wrote:

Hi Karli

I've written up all we know at [1], please try to follow it (if you 
haven't yet) and let us know how it goes. If anything goes wrong, we 
will look for the ways to resolve it.


Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie  
wrote:

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 
 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 
  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 
>> regar

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-23 Thread Alfred Angelov


Hey,

This might sounds like a foolish question, but from the link you mentioned:

oVirt 3.1 was released as Fedora 17 package while 3.2 is targeted 
Fedora 18. Due to the nature of this upgrade, we DO NOT recommend it, 
users are advised to do a 3.2 clean installation, and to import all 
VM's and template into the new installation. 


Is there anything special I would have to do to import all the VMs 
(around 40) from my ovirt 3.1.0-2 to another ovirt (which runs 3.2.2) ?


Mvh, Alfred Angelov

On 06/23/2013 11:35 AM, Alex Lourie wrote:

Hi Karli

I've written up all we know at [1], please try to follow it (if you 
haven't yet) and let us know how it goes. If anything goes wrong, we 
will look for the ways to resolve it.


Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie  wrote:

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 
 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  
 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 fro

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-23 Thread Alex Lourie


Hi Karli

I've written up all we know at [1], please try to follow it (if you 
haven't yet) and let us know how it goes. If anything goes wrong, we 
will look for the ways to resolve it.


Alex.

[1] http://www.ovirt.org/OVirt_3.1_to_3.2_upgrade

On Thu, Jun 20, 2013 at 8:05 PM, Alex Lourie  wrote:

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 
 
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  
 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 q

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-22 Thread Itamar Heim


On 06/22/2013 02:43 PM, Karli Sjöberg wrote:

Hi Itamar!


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.


So that Fedora can be the testingbed that it was designed to be; yes I think so to. But 
there have been issues going from CentOS-6.3- to 6.4 with oVirt as well, no? I mean, 
isn´t upgrading issues something that needs dealing with sooner rather than later, 
regardless of the distribution? Or are "we" hoping for that much better 
maintainability between CentOS-6.X and oVirt-3.X that they can live alongside of each 
other throughout their respective lifespan?

There weren´t any "official" packages for CentOS when we set up our platform, otherwise 
we would have probably chosen CentOS right from start, for that increased stability. But is there 
any commitment from your side to continue supporting oVirt on CentOS, or is it going to continue 
being more or less a "one-man show"? (No offense to Dreyou, keep up the good work, 
awesome job so far)

Best Regards
Karli Sjöberg


,.øﬁﬁ÷



Dreyou can only be commended for the work he did for .el6 support.
and to your question - yes - .el6 has been officially added to oVirt and 
will remain maintained.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-22 Thread Karli Sjöberg

Hi Itamar!

> 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.

So that Fedora can be the testingbed that it was designed to be; yes I think so 
to. But there have been issues going from CentOS-6.3- to 6.4 with oVirt as 
well, no? I mean, isn´t upgrading issues something that needs dealing with 
sooner rather than later, regardless of the distribution? Or are "we" hoping 
for that much better maintainability between CentOS-6.X and oVirt-3.X that they 
can live alongside of each other throughout their respective lifespan?

There weren´t any "official" packages for CentOS when we set up our platform, 
otherwise we would have probably chosen CentOS right from start, for that 
increased stability. But is there any commitment from your side to continue 
supporting oVirt on CentOS, or is it going to continue being more or less a 
"one-man show"? (No offense to Dreyou, keep up the good work, awesome job so 
far)

Best Regards
Karli Sjöberg


,.øﬁﬁ÷
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-20 Thread Alex Lourie

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  
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  

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 1

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-19 Thread Itamar Heim

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 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

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-18 Thread Karli Sjöberg

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 
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!

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 + 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,
>

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-18 Thread 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 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)
-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 + 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
>>>

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-17 Thread Karli Sjöberg

mån 2013-06-17 klockan 10:11 +0003 skrev Alex Lourie:

On Fri, Jun 14, 2013 at 12:26 PM, Karli Sjöberg 
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?

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 + 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 SUBDESCRIPTION
> httpd.service  loaded failed failed The Apache HTTP Server
>>

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-17 Thread Itamar Heim

On 06/17/2013 01:08 PM, Alex Lourie wrote:

On Fri, Jun 14, 2013 at 12:26 PM, Karli Sjöberg 
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.

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.

it seems that upgrades on .el6 platforms (RHEL/CentOS) are easier (since 
not a major upgrade of the underlying OS)?

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 + 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 SUBDESCRIPTION
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.ovirt2013-01-30 20:58:49.40400 +0100
+++ pg_hba.conf2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS METHOD

 # "local" is for Unix domain socket connections only
-local   all all md5
+local   all all trust
 # IPv4 local connections:
 hostall 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.ovirt2013-01-30 21:21:06.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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
 #

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-17 Thread Alex Lourie

On Fri, Jun 14, 2013 at 12:26 PM, Karli Sjöberg  
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.

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.

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 + 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 SUBDESCRIPTION
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.40400 +0100
+++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS 
METHOD

 # "local" is for Unix domain socket connections only
-local   all all 
md5
+local   all all 
trust

 # IPv4 local connections:
 hostall 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.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-06-14 Thread Karli Sjöberg

Hi!

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?

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 + 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 SUBDESCRIPTION
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.40400 +0100
+++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS METHOD

 # "local" is for Unix domain socket connections only
-local   all all md5
+local   all all trust
 # IPv4 local connections:
 hostall all 127.0.0.1/32md5
 # 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.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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.sjob...@slu.se
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-04-05 Thread 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 + 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 SUBDESCRIPTION
>>> 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.40400 +0100
>>> +++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
>>> @@ -77,7 +77,7 @@
>>>  # TYPE  DATABASEUSERADDRESS METHOD
>>>  
>>>  # "local" is for Unix domain socket connections only
>>> -local   all all md5
>>> +local   all all trust
>>>  # IPv4 local connections:
>>>  hostall all 127.0.0.1/32md5
>>>  # 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.90600 +0100
>>> +++ ssl.conf2013-01-30 21:22:02.75700 +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

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-04-02 Thread Karli Sjöberg

Hi,

has there been any progress regarding this matter?

Best Regards
Karli Sjöberg

fre 2013-03-15 klockan 14:12 + 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 SUBDESCRIPTION
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.40400 +0100
+++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS METHOD

 # "local" is for Unix domain socket connections only
-local   all all md5
+local   all all trust
 # IPv4 local connections:
 hostall all 127.0.0.1/32md5
 # 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.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-15 Thread 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 SUBDESCRIPTION
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.40400 +0100
+++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS METHOD

 # "local" is for Unix domain socket connections only
-local   all all md5
+local   all all trust
 # IPv4 local connections:
 hostall all 127.0.0.1/32md5
 # 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.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-15 Thread 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 SUBDESCRIPTION
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.40400 +0100
+++ pg_hba.conf 2013-01-30 20:59:06.70900 +0100
@@ -77,7 +77,7 @@
 # TYPE  DATABASEUSERADDRESS METHOD
 
 # "local" is for Unix domain socket connections only
-local   all all md5
+local   all all trust
 # IPv4 local connections:
 hostall all 127.0.0.1/32md5
 # 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.90600 +0100
+++ ssl.conf2013-01-30 21:22:02.75700 +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.

-- 
Sandro

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread Dave Neary


Hi Eli,

On 03/13/2013 03:41 PM, Eli Mesika wrote:

On 03/11/2013 03:17 PM, Eli Mesika wrote:

Please make sure to upgrade to latest 3.1.z before upgrading to 3.2


Would you mind explaining why? It's funny that I would need to
upgrade
in 2 steps: Update 3.1 to tip of branch, then upgrade to 3.2.

Were there any database schema changes withing the 3.1.* releases?


There we some bugs that were related only to 3.1 and therefore fixed only on 
the 3.1 repository.
I had consulted on that with Barak and I have been told that it is OK to ask to 
upgrade to latest 3.1.z before upgrading to 3.2
If this is wrong from your POV, please open a discussion on engine-devel and I 
will be glad to follow any new directions requested by the community.


Of course it's OK to ask :-) I think it's OK to ask why, also.

I'm just wondering if there is some reason why an upgrade might work 
better from 3.1 branch tim than from the 3.1 release (or 3.1.1 if there 
was one, but I don't remember it).


Thanks!
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread Eli Mesika

- Original Message -
> From: "Dave Neary" 
> To: "Eli Mesika" 
> Cc: "Karli Sjöberg" , "Juan Hernandez" 
> , users@ovirt.org
> Sent: Wednesday, March 13, 2013 1:02:21 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> Hi Eli,
> 
> On 03/11/2013 03:17 PM, Eli Mesika wrote:
> > Please make sure to upgrade to latest 3.1.z before upgrading to 3.2
> 
> Would you mind explaining why? It's funny that I would need to
> upgrade
> in 2 steps: Update 3.1 to tip of branch, then upgrade to 3.2.
> 
> Were there any database schema changes withing the 3.1.* releases?

There we some bugs that were related only to 3.1 and therefore fixed only on 
the 3.1 repository.
I had consulted on that with Barak and I have been told that it is OK to ask to 
upgrade to latest 3.1.z before upgrading to 3.2
If this is wrong from your POV, please open a discussion on engine-devel and I 
will be glad to follow any new directions requested by the community.

> 
> Thanks,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread Karli Sjöberg

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.

/Karli
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread Dave Neary


Hi Eli,

On 03/11/2013 03:17 PM, Eli Mesika wrote:

Please make sure to upgrade to latest 3.1.z before upgrading to 3.2


Would you mind explaining why? It's funny that I would need to upgrade 
in 2 steps: Update 3.1 to tip of branch, then upgrade to 3.2.


Were there any database schema changes withing the 3.1.* releases?

Thanks,
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread 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.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-13 Thread Karli Sjöberg

Hi,

let me restate my main question: Is there any patch-set I can try to verify if 
the changes work, or how long until there is any update to the repository 
packages? We have an identical oVirt installation set up next to our production 
environment that we can mess up as much as we´d like without interfering, so if 
you have anything you´d like to test, we are game:)

/Karli

mån 2013-03-11 klockan 14:26 + skrev Karli Sjöberg:
mån 2013-03-11 klockan 10:17 -0400 skrev Eli Mesika:



- Original Message -
> From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> To: "Eli Mesika" mailto:emes...@redhat.com>>
> Cc: users@ovirt.org<mailto:users@ovirt.org>, "Juan Hernandez" 
> mailto:jhern...@redhat.com>>
> Sent: Monday, March 11, 2013 2:54:10 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> mån 2013-03-11 klockan 08:03 -0400 skrev Eli Mesika:
>
> Hi
> this was solved in commit e433e54616231c1afe950d3291566133106812d0
> Following procedured still fails; revert failed upgrade to 3.1.0-4,
> re-enable 3.2 repo, update ovirt-engine-setup (3.2.0-4), download
> new dbfunctions.sh and drop_old_uuid_functions.sql from gerrit, and
> then try to engine-upgrade. Same problem as before. Is there any
> patch-set I could try and verify if changes work, or how long until
> there is any update to the repository packages?

Please make sure to upgrade to latest 3.1.z before upgrading to 3.2


Of course, they are all the latest versions. Before attempting upgrade are 
oVirt-3.1.0-4, going to oVirt-3.2.0-4 taken from:
http://ovirt.org/releases/3.2/rpm/Fedora/18




>
> /Karli
>
> - Original Message -
> > From: "Karli Sjöberg" < karli.sjob...@slu.se<mailto:karli.sjob...@slu.se> >
> > To: "Juan Hernandez" < jhern...@redhat.com<mailto:jhern...@redhat.com> >
> > Cc: users@ovirt.org<mailto:users@ovirt.org> > Sent: Monday, March 11, 2013 
> > 1:35:29 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> >
> > mån 2013-03-11 klockan 12:20 +0100 skrev Juan Hernandez:
> >
> > On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> > > 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.
> > > We´ve come about halfway into upgrading to the engine node, where
> > > we
> > > have managed to get it up to 18, with postgres, httpd and
> > > ovirt-engine-3.1.0-4 running and functional. Then we edit our
> > > ovirt-engine.repo to add 3.2 packages, yum update
> > > ovirt-engine-setup,
> > > then run engine-upgrade, that fails on upgrading the database.
> > > The
> > > log
> > > file is attached. What could be the issue here?
> >
> > The service is failing to start after the upgrade. Can you check
> > /var/log/messages? What about
> > /var/log/ovirt-engine/{engine.log,server.log}? Well that comes
> > after
> > failing to upgrade the database, engine- and server.log attached,
> > doesn´t say anything useful really. It´s rather here it starts
> > going
> > south:
> >
> > 2013-03-11 11:56:49::DEBUG::engine-upgrade::412::root:: DB Update
> > started
> > 2013-03-11 11:56:49::DEBUG::common_utils::434::root:: Executing
> > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > localhost -p 5432 -u engine -d engine_2013_03_11_11_54_00'
> > 2013-03-11 11:56:54::DEBUG::common_utils::472::root:: output =
> > /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> > upgrade script detected a change in Config, View or Stored
> > Procedure...
> >
> > 2013-03-11 11:56:54::DEBUG::common_utils::473::root:: stderr =
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:common_sp.sql:567: NOTICE: type "fk_info_rs" does not exist,
> > skipping
> > psql:drop_all_views.sql:1: NOTICE: drop cascades to 9 other objects
> > ...
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:drop_old_uuid_functions.sql:25: NOTICE: extension "uuid" does
> > not exist, skipping
> > CONTEXT: SQL statement "DROP EXTENSION IF EXISTS uuid--ossp
> > CASCADE;"
> > PL/pgSQL function __temp_drop_old_uuid_functions() line 6 at
> > EXECUTE
> > statement
> > psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> > uuid_nil() because extension uuid-ossp requires it
> > HINT: You can drop extension uuid-ossp in

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-11 Thread Karli Sjöberg

mån 2013-03-11 klockan 10:17 -0400 skrev Eli Mesika:



- Original Message -
> From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> To: "Eli Mesika" mailto:emes...@redhat.com>>
> Cc: users@ovirt.org<mailto:users@ovirt.org>, "Juan Hernandez" 
> mailto:jhern...@redhat.com>>
> Sent: Monday, March 11, 2013 2:54:10 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
> mån 2013-03-11 klockan 08:03 -0400 skrev Eli Mesika:
>
> Hi
> this was solved in commit e433e54616231c1afe950d3291566133106812d0
> Following procedured still fails; revert failed upgrade to 3.1.0-4,
> re-enable 3.2 repo, update ovirt-engine-setup (3.2.0-4), download
> new dbfunctions.sh and drop_old_uuid_functions.sql from gerrit, and
> then try to engine-upgrade. Same problem as before. Is there any
> patch-set I could try and verify if changes work, or how long until
> there is any update to the repository packages?

Please make sure to upgrade to latest 3.1.z before upgrading to 3.2


Of course, they are all the latest versions. Before attempting upgrade are 
oVirt-3.1.0-4, going to oVirt-3.2.0-4 taken from:
http://ovirt.org/releases/3.2/rpm/Fedora/18




>
> /Karli
>
> - Original Message -
> > From: "Karli Sjöberg" < karli.sjob...@slu.se<mailto:karli.sjob...@slu.se> >
> > To: "Juan Hernandez" < jhern...@redhat.com<mailto:jhern...@redhat.com> >
> > Cc: users@ovirt.org<mailto:users@ovirt.org> > Sent: Monday, March 11, 2013 
> > 1:35:29 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> >
> >
> > mån 2013-03-11 klockan 12:20 +0100 skrev Juan Hernandez:
> >
> > On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> > > 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.
> > > We´ve come about halfway into upgrading to the engine node, where
> > > we
> > > have managed to get it up to 18, with postgres, httpd and
> > > ovirt-engine-3.1.0-4 running and functional. Then we edit our
> > > ovirt-engine.repo to add 3.2 packages, yum update
> > > ovirt-engine-setup,
> > > then run engine-upgrade, that fails on upgrading the database.
> > > The
> > > log
> > > file is attached. What could be the issue here?
> >
> > The service is failing to start after the upgrade. Can you check
> > /var/log/messages? What about
> > /var/log/ovirt-engine/{engine.log,server.log}? Well that comes
> > after
> > failing to upgrade the database, engine- and server.log attached,
> > doesn´t say anything useful really. It´s rather here it starts
> > going
> > south:
> >
> > 2013-03-11 11:56:49::DEBUG::engine-upgrade::412::root:: DB Update
> > started
> > 2013-03-11 11:56:49::DEBUG::common_utils::434::root:: Executing
> > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > localhost -p 5432 -u engine -d engine_2013_03_11_11_54_00'
> > 2013-03-11 11:56:54::DEBUG::common_utils::472::root:: output =
> > /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> > upgrade script detected a change in Config, View or Stored
> > Procedure...
> >
> > 2013-03-11 11:56:54::DEBUG::common_utils::473::root:: stderr =
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:common_sp.sql:567: NOTICE: type "fk_info_rs" does not exist,
> > skipping
> > psql:drop_all_views.sql:1: NOTICE: drop cascades to 9 other objects
> > ...
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:drop_old_uuid_functions.sql:25: NOTICE: extension "uuid" does
> > not exist, skipping
> > CONTEXT: SQL statement "DROP EXTENSION IF EXISTS uuid--ossp
> > CASCADE;"
> > PL/pgSQL function __temp_drop_old_uuid_functions() line 6 at
> > EXECUTE
> > statement
> > psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> > uuid_nil() because extension uuid-ossp requires it
> > HINT: You can drop extension uuid-ossp instead.
> > CONTEXT: SQL statement "drop function if exists uuid_nil()"
> > PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL
> > statement
> > psql:create_functions.sql:379: WARNING: GLOBAL is deprecated in
> > temporary table creation
> > LINE 25: CREATE GLOBAL TEMPORARY TABLE tt_TEMP22
> > ^
> > psql:create_functions.sql:535: NOTICE: type
> > "all_vds

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-11 Thread Eli Mesika



- Original Message -
> From: "Karli Sjöberg" 
> To: "Eli Mesika" 
> Cc: users@ovirt.org, "Juan Hernandez" 
> Sent: Monday, March 11, 2013 2:54:10 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> mån 2013-03-11 klockan 08:03 -0400 skrev Eli Mesika:
> 
> Hi
> this was solved in commit e433e54616231c1afe950d3291566133106812d0
> Following procedured still fails; revert failed upgrade to 3.1.0-4,
> re-enable 3.2 repo, update ovirt-engine-setup (3.2.0-4), download
> new dbfunctions.sh and drop_old_uuid_functions.sql from gerrit, and
> then try to engine-upgrade. Same problem as before. Is there any
> patch-set I could try and verify if changes work, or how long until
> there is any update to the repository packages?

Please make sure to upgrade to latest 3.1.z before upgrading to 3.2

> 
> /Karli
> 
> - Original Message -
> > From: "Karli Sjöberg" < karli.sjob...@slu.se >
> > To: "Juan Hernandez" < jhern...@redhat.com >
> > Cc: users@ovirt.org > Sent: Monday, March 11, 2013 1:35:29 PM
> > Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> > 
> > 
> > mån 2013-03-11 klockan 12:20 +0100 skrev Juan Hernandez:
> > 
> > On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> > > 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.
> > > We´ve come about halfway into upgrading to the engine node, where
> > > we
> > > have managed to get it up to 18, with postgres, httpd and
> > > ovirt-engine-3.1.0-4 running and functional. Then we edit our
> > > ovirt-engine.repo to add 3.2 packages, yum update
> > > ovirt-engine-setup,
> > > then run engine-upgrade, that fails on upgrading the database.
> > > The
> > > log
> > > file is attached. What could be the issue here?
> > 
> > The service is failing to start after the upgrade. Can you check
> > /var/log/messages? What about
> > /var/log/ovirt-engine/{engine.log,server.log}? Well that comes
> > after
> > failing to upgrade the database, engine- and server.log attached,
> > doesn´t say anything useful really. It´s rather here it starts
> > going
> > south:
> > 
> > 2013-03-11 11:56:49::DEBUG::engine-upgrade::412::root:: DB Update
> > started
> > 2013-03-11 11:56:49::DEBUG::common_utils::434::root:: Executing
> > command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> > localhost -p 5432 -u engine -d engine_2013_03_11_11_54_00'
> > 2013-03-11 11:56:54::DEBUG::common_utils::472::root:: output =
> > /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> > upgrade script detected a change in Config, View or Stored
> > Procedure...
> > 
> > 2013-03-11 11:56:54::DEBUG::common_utils::473::root:: stderr =
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:common_sp.sql:567: NOTICE: type "fk_info_rs" does not exist,
> > skipping
> > psql:drop_all_views.sql:1: NOTICE: drop cascades to 9 other objects
> > ...
> > psql:common_sp.sql:524: NOTICE: drop cascades to function
> > fn_db_get_async_tasks()
> > psql:drop_old_uuid_functions.sql:25: NOTICE: extension "uuid" does
> > not exist, skipping
> > CONTEXT: SQL statement "DROP EXTENSION IF EXISTS uuid--ossp
> > CASCADE;"
> > PL/pgSQL function __temp_drop_old_uuid_functions() line 6 at
> > EXECUTE
> > statement
> > psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> > uuid_nil() because extension uuid-ossp requires it
> > HINT: You can drop extension uuid-ossp instead.
> > CONTEXT: SQL statement "drop function if exists uuid_nil()"
> > PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL
> > statement
> > psql:create_functions.sql:379: WARNING: GLOBAL is deprecated in
> > temporary table creation
> > LINE 25: CREATE GLOBAL TEMPORARY TABLE tt_TEMP22
> > ^
> > psql:create_functions.sql:535: NOTICE: type
> > "all_vds_group_usage_rs"
> > does not exist, skipping
> > psql:create_functions.sql:570: NOTICE: type "all_storage_usage_rs"
> > does not exist, skipping
> > psql:create_functions.sql:671: ERROR: must be owner of function
> > uuid_generate_v1
> > 
> > 2013-03-11 11:56:54::DEBUG::common_utils::474::root:: retcode = 3
> > 2013-03-11 11:56:54::ERROR::engine-upgrade::1078::root:: Traceback
> > (most recent

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-11 Thread Karli Sjöberg

mån 2013-03-11 klockan 08:03 -0400 skrev Eli Mesika:


Hi
this was solved in commit e433e54616231c1afe950d3291566133106812d0


Following procedured still fails; revert failed upgrade to 3.1.0-4, re-enable 
3.2 repo, update ovirt-engine-setup (3.2.0-4), download new 
dbfunctions.sh<http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh>
 and 
drop_old_uuid_functions.sql<http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/drop_old_uuid_functions.sql>
 from gerrit, and then try to engine-upgrade. Same problem as before. Is there 
any patch-set I could try and verify if changes work, or how long until there 
is any update to the repository packages?

/Karli



- Original Message -
> From: "Karli Sjöberg" mailto:karli.sjob...@slu.se>>
> To: "Juan Hernandez" mailto:jhern...@redhat.com>>
> Cc: users@ovirt.org<mailto:users@ovirt.org>
> Sent: Monday, March 11, 2013 1:35:29 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
>
>
> mån 2013-03-11 klockan 12:20 +0100 skrev Juan Hernandez:
>
> On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> > 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.
> > We´ve come about halfway into upgrading to the engine node, where
> > we
> > have managed to get it up to 18, with postgres, httpd and
> > ovirt-engine-3.1.0-4 running and functional. Then we edit our
> > ovirt-engine.repo to add 3.2 packages, yum update
> > ovirt-engine-setup,
> > then run engine-upgrade, that fails on upgrading the database. The
> > log
> > file is attached. What could be the issue here?
>
> The service is failing to start after the upgrade. Can you check
> /var/log/messages? What about
> /var/log/ovirt-engine/{engine.log,server.log}? Well that comes after
> failing to upgrade the database, engine- and server.log attached,
> doesn´t say anything useful really. It´s rather here it starts going
> south:
>
> 2013-03-11 11:56:49::DEBUG::engine-upgrade::412::root:: DB Update
> started
> 2013-03-11 11:56:49::DEBUG::common_utils::434::root:: Executing
> command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> localhost -p 5432 -u engine -d engine_2013_03_11_11_54_00'
> 2013-03-11 11:56:54::DEBUG::common_utils::472::root:: output =
> /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> upgrade script detected a change in Config, View or Stored
> Procedure...
>
> 2013-03-11 11:56:54::DEBUG::common_utils::473::root:: stderr =
> psql:common_sp.sql:524: NOTICE: drop cascades to function
> fn_db_get_async_tasks()
> psql:common_sp.sql:567: NOTICE: type "fk_info_rs" does not exist,
> skipping
> psql:drop_all_views.sql:1: NOTICE: drop cascades to 9 other objects
> ...
> psql:common_sp.sql:524: NOTICE: drop cascades to function
> fn_db_get_async_tasks()
> psql:drop_old_uuid_functions.sql:25: NOTICE: extension "uuid" does
> not exist, skipping
> CONTEXT: SQL statement "DROP EXTENSION IF EXISTS uuid--ossp CASCADE;"
> PL/pgSQL function __temp_drop_old_uuid_functions() line 6 at EXECUTE
> statement
> psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> uuid_nil() because extension uuid-ossp requires it
> HINT: You can drop extension uuid-ossp instead.
> CONTEXT: SQL statement "drop function if exists uuid_nil()"
> PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL
> statement
> psql:create_functions.sql:379: WARNING: GLOBAL is deprecated in
> temporary table creation
> LINE 25: CREATE GLOBAL TEMPORARY TABLE tt_TEMP22
> ^
> psql:create_functions.sql:535: NOTICE: type "all_vds_group_usage_rs"
> does not exist, skipping
> psql:create_functions.sql:570: NOTICE: type "all_storage_usage_rs"
> does not exist, skipping
> psql:create_functions.sql:671: ERROR: must be owner of function
> uuid_generate_v1
>
> 2013-03-11 11:56:54::DEBUG::common_utils::474::root:: retcode = 3
> 2013-03-11 11:56:54::ERROR::engine-upgrade::1078::root:: Traceback
> (most recent call last):
> File "/usr/bin/engine-upgrade", line 1065, in main
> runFunc([db.update], MSG_INFO_DB_UPDATE)
> File "/usr/bin/engine-upgrade", line 594, in runFunc
> func()
> File "/usr/bin/engine-upgrade", line 429, in update
> output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> msg=MSG_ERROR_UPDATE_DB)
> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 477, in
> execCmd
> raise Exception(msg)
> Exception: Error: Database update failed
> ...
>
> /Karli
> ___
> Users mailing list
> Users@ovirt.org<mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
>


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-11 Thread Eli Mesika

Hi
this was solved in commit e433e54616231c1afe950d3291566133106812d0

- Original Message -
> From: "Karli Sjöberg" 
> To: "Juan Hernandez" 
> Cc: users@ovirt.org
> Sent: Monday, March 11, 2013 1:35:29 PM
> Subject: Re: [Users] Fedora upgrading from 3.1 to 3.2
> 
> 
> mån 2013-03-11 klockan 12:20 +0100 skrev Juan Hernandez:
> 
> On 03/11/2013 12:16 PM, Karli Sjöberg wrote:
> > 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.
> > We´ve come about halfway into upgrading to the engine node, where
> > we
> > have managed to get it up to 18, with postgres, httpd and
> > ovirt-engine-3.1.0-4 running and functional. Then we edit our
> > ovirt-engine.repo to add 3.2 packages, yum update
> > ovirt-engine-setup,
> > then run engine-upgrade, that fails on upgrading the database. The
> > log
> > file is attached. What could be the issue here?
> 
> The service is failing to start after the upgrade. Can you check
> /var/log/messages? What about
> /var/log/ovirt-engine/{engine.log,server.log}? Well that comes after
> failing to upgrade the database, engine- and server.log attached,
> doesn´t say anything useful really. It´s rather here it starts going
> south:
> 
> 2013-03-11 11:56:49::DEBUG::engine-upgrade::412::root:: DB Update
> started
> 2013-03-11 11:56:49::DEBUG::common_utils::434::root:: Executing
> command --> '/usr/share/ovirt-engine/dbscripts/upgrade.sh -s
> localhost -p 5432 -u engine -d engine_2013_03_11_11_54_00'
> 2013-03-11 11:56:54::DEBUG::common_utils::472::root:: output =
> /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> upgrade script detected a change in Config, View or Stored
> Procedure...
> 
> 2013-03-11 11:56:54::DEBUG::common_utils::473::root:: stderr =
> psql:common_sp.sql:524: NOTICE: drop cascades to function
> fn_db_get_async_tasks()
> psql:common_sp.sql:567: NOTICE: type "fk_info_rs" does not exist,
> skipping
> psql:drop_all_views.sql:1: NOTICE: drop cascades to 9 other objects
> ...
> psql:common_sp.sql:524: NOTICE: drop cascades to function
> fn_db_get_async_tasks()
> psql:drop_old_uuid_functions.sql:25: NOTICE: extension "uuid" does
> not exist, skipping
> CONTEXT: SQL statement "DROP EXTENSION IF EXISTS uuid--ossp CASCADE;"
> PL/pgSQL function __temp_drop_old_uuid_functions() line 6 at EXECUTE
> statement
> psql:drop_old_uuid_functions.sql:25: ERROR: cannot drop function
> uuid_nil() because extension uuid-ossp requires it
> HINT: You can drop extension uuid-ossp instead.
> CONTEXT: SQL statement "drop function if exists uuid_nil()"
> PL/pgSQL function __temp_drop_old_uuid_functions() line 10 at SQL
> statement
> psql:create_functions.sql:379: WARNING: GLOBAL is deprecated in
> temporary table creation
> LINE 25: CREATE GLOBAL TEMPORARY TABLE tt_TEMP22
> ^
> psql:create_functions.sql:535: NOTICE: type "all_vds_group_usage_rs"
> does not exist, skipping
> psql:create_functions.sql:570: NOTICE: type "all_storage_usage_rs"
> does not exist, skipping
> psql:create_functions.sql:671: ERROR: must be owner of function
> uuid_generate_v1
> 
> 2013-03-11 11:56:54::DEBUG::common_utils::474::root:: retcode = 3
> 2013-03-11 11:56:54::ERROR::engine-upgrade::1078::root:: Traceback
> (most recent call last):
> File "/usr/bin/engine-upgrade", line 1065, in main
> runFunc([db.update], MSG_INFO_DB_UPDATE)
> File "/usr/bin/engine-upgrade", line 594, in runFunc
> func()
> File "/usr/bin/engine-upgrade", line 429, in update
> output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
> msg=MSG_ERROR_UPDATE_DB)
> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 477, in
> execCmd
> raise Exception(msg)
> Exception: Error: Database update failed
> ...
> 
> /Karli
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Fedora upgrading from 3.1 to 3.2

2013-03-11 Thread Juan Hernandez


On 03/11/2013 12:16 PM, Karli Sjöberg wrote:

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.
We´ve come about halfway into upgrading to the engine node, where we
have managed to get it up to 18, with postgres, httpd and
ovirt-engine-3.1.0-4 running and functional. Then we edit our
ovirt-engine.repo to add 3.2 packages, yum update ovirt-engine-setup,
then run engine-upgrade, that fails on upgrading the database. The log
file is attached. What could be the issue here?


The service is failing to start after the upgrade. Can you check 
/var/log/messages? What about /var/log/ovirt-engine/{engine.log,server.log}?


--
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.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

57 matches

Mail list logo