Re: [Engine-devel] Why deploy failed? Please help me, thanks.
On 04/20/2013 05:10 AM, 李强 wrote: I have ERROR and Please help me ,thanks sounds similar to: Bug 918742 - Ovirt 3.2 all in one problem install in Fedora 18 to workaround and just get the engine installed (without the all-in-one first), please reply 'no' to the this question: Configure VDSM on this host? ['yes'| 'no'] [yes] then please try to collaborate with sandro on the bug to resolve the issue. thanks, Itamar The first Upgrade is SUCCESS. Please look the info. But engine-set is ERROR. AIO: Adding Local Datacenter and cluster...[ ERROR ] Error: could not create ovirtsdk API object Please check log file /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more information == [root@engine noarch]# rpm -Uvh *.rpm Preparing... # [100%] Updating / installing... 1:ovirt-engine-sdk-3.3.0.1-1.201304# [ 3%] 2:ovirt-image-uploader-3.3.0-0.0.ma# http://ovirt-image-uploader-3.3.0-0.0.ma# [ 7%] 3:ovirt-iso-uploader-3.3.0-0.0.mast# [ 10%] 4:ovirt-log-collector-3.3.0-0.0.mas# [ 14%] 5:ovirt-engine-backend-3.3.0-0.2.ma# http://ovirt-engine-backend-3.3.0-0.2.ma# [ 17%] 6:ovirt-engine-dbscripts-3.3.0-0.2.# [ 21%] 7:ovirt-engine-restapi-3.3.0-0.2.ma# http://ovirt-engine-restapi-3.3.0-0.2.ma# [ 24%] 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: /etc/firewalld/services/ovirt.xml created as /etc/firewalld/services/ovirt.xml.rpmnew # [ 28%] 9:ovirt-engine-tools-3.3.0-0.2.mast# [ 31%] 10:ovirt-engine-userportal-3.3.0-0.2# [ 34%] 11:ovirt-engine-webadmin-portal-3.3.# [ 38%] 12:ovirt-engine-3.3.0-0.2.master.201# [ 41%] 13:ovirt-host-deploy-offline-1.1.0-0# [ 45%] 14:ovirt-engine-setup-plugin-allinon# [ 48%] Cleaning up / removing... 15:ovirt-engine-backend-3.2.0-4.fc18# [ 52%] 16:ovirt-engine-config-3.2.0-4.fc18 # [ 55%] 17:ovirt-engine-dbscripts-3.2.0-4.fc# [ 59%] 18:ovirt-engine-genericapi-3.2.0-4.f# [ 62%] 19:ovirt-engine-tools-common-3.2.0-4# [ 66%] 20:ovirt-engine-notification-service# [ 69%] 21:ovirt-engine-restapi-3.2.0-4.fc18# [ 72%] 22:ovirt-engine-setup-3.2.0-4.fc18 # [ 76%] 23:ovirt-engine-userportal-3.2.0-4.f# [ 79%] 24:ovirt-engine-webadmin-portal-3.2.# [ 83%] 25:ovirt-engine-3.2.0-4.fc18warning: /etc/sysconfig/ovirt-engine saved as /etc/sysconfig/ovirt-engine.rpmsave # [ 86%] 26:ovirt-image-uploader-3.2.0-1.fc18# [ 90%] 27:ovirt-iso-uploader-3.2.0-1.fc18 # [ 93%] 28:ovirt-log-collector-3.2.0-1.fc18 # [ 97%] 29:ovirt-engine-sdk-3.2.0.9-1.fc18 # [100%] == ++ [root@engine ~]# engine-setup Welcome to oVirt Engine setup utility WARNING: oVirt Engine setup has already been run on this host. To remove all configuration and reset oVirt Engine please run engine-cleanup. Please be advised that executing engine-setup without cleanup is not supported. Would you like to proceed? (yes|no): yes In order to proceed the installer must stop the ovirt-engine service Would you like to stop the ovirt-engine service? (yes|no): yes oVirt Engine uses httpd to proxy requests to the application server. It looks like the httpd installed locally is being actively used. The installer can override current configuration . Alternatively you can use JBoss directly (on ports higher than 1024) Do you wish to override current httpd configuration and restart the service? ['yes'| 'no'] [yes] : HTTP Port [80] : HTTPS Port [443] : Setup can configure server default page to launch oVirt Engine. Do you wish to do so? ['yes'| 'no'] [yes] : Host fully qualified domain name. Note: this name should be fully resolvable [engine.startn.com http://engine.startn.com] : The IP 192.168.11.12 does not hold a PTR record for the FQDN: engine.startn.com http://engine.startn.com User
Re: [Engine-devel] Why deploy failed? Please help me, thanks.
- Original Message - From: 李强 liqiang@gmail.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, engine-devel@ovirt.org Sent: Saturday, April 20, 2013 3:59:23 AM Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. HI:all The first THANKS to all, I rpmbuild and create this files: [root@engine noarch]# ls ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm AND I COMMAND: ++ rpm -Uvh *.rpm ++ That command is OK? Sorry, I have not used rpm command for a long time. If that rpm's command is ok, What should I do next? Put all rpms in directory, let's say /var/lib/repos.local Run: # createrepo /var/lib/repos.local Add the following file: /etc/yum.repos.d/local.repo --- [local] name=local baseurl=file:///var/lib/repos.local enabled=1 gpgcheck=0 priority=1 protect=1 --- Then: yum install ovirt-engine ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Why deploy failed? Please help me, thanks.
- Original Message - From: 李强 liqiang@gmail.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel@ovirt.org Sent: Saturday, April 20, 2013 4:11:39 AM Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. HI：Alon Thank your help, The question: 1,Your email Close the repository, What does it mean? I meant clone. 2,Your email Alternatively, you can try out soon to be merged development environment[1][2] Is it stable? Can be used in a production environment? No. This is only for development if you want to add translation. Thanks again your help, ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated
On 04/19/2013 12:21 PM, Chen, Wei D wrote: Hi All, Our second approach for trusted compute pools integration with oVirt seems more simple and sensible than previous VM level approach. Welcome any comments on our latest design. Thanks in advance. Link is here, http://www.ovirt.org/Trusted_compute_pools a few nits: 1. last updated date isn't updated... 2. from reading it top to bottom, hard to understand the 2nd approach is the one to be used and not the first (vm level). 3. cluster dialog - the 'trusted' should be a checkbox, not radio button, and should only be enabled if virt service was chosen. thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Packaging and locales
Hi! - Original Message - From: Einav Cohen eco...@redhat.com To: Alon Bar-Lev alo...@redhat.com, Vojtech Szocs vsz...@redhat.com, Alexander Wels aw...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 8:23:06 PM Subject: Re: Packaging and locales Hi Alon, The available languages of oVirt's gwt-based portals are determined during compilation time. for run-time optimization purposes, the gwt-compiler executes a compilation-permutation per browser + per language. Hmmm... this what I was afraid of... I assume that we can construct separate ovirt-engine[-*] packages, each one contains the gwt-based portals that were compiled only with the relevant locales (permutations). if we will do that, we won't be able to maintain all locales within the same web-application anymore (currently, the web-admin is a single web-application that supports all locales, same goes for the user-portal) - doing a separate web-application per locale probably makes more sense. also: could be trivial to do, but need to keep in mind that for every code-change, we will need to issue an update for each one of the ovirt-engine[-*] packages, and somehow make sure that the user will yum update *all* packages that he originally yum installed, in order to avoid applications in different locales going out-of-sync. Oh... this what I fear... if permutation include code + locale then this is no go for this approach. The separate package should contain locale only, so at worse case scenario you get locale C as default. Let's say going modular is too complicated for gwt based application... however, any reason why we do not build all locales by default? For development we can limit number of permutations, but default rpmbuild -tb tarball should build all available locales. Thanks! Alon Thanks, Einav - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Alexander Wels aw...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 3:44:15 AM Subject: Packaging and locales Hello, From recent thread I learned that we package locales within our main package, message bundles are going into jars, and by default we do not build them all. As this is GWT specific as far as I see in build, I have no real visibility of what happening. However, I do expect locales to be packaged and installed as separate packages, side by side with main package. Something like: # yum install ovirt-engine - provides en_US # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. This ease maintenance, as these translations can be maintain using their own release cycle and even out of main tree. Any thoughts? Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Packaging and locales
- Original Message - From: Einav Cohen eco...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, Alexander Wels aw...@redhat.com, Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 10:12:08 PM Subject: Re: Packaging and locales - Original Message - From: Alon Bar-Lev alo...@redhat.com Sent: Saturday, April 20, 2013 2:54:23 PM Hi! - Original Message - From: Einav Cohen eco...@redhat.com To: Alon Bar-Lev alo...@redhat.com, Vojtech Szocs vsz...@redhat.com, Alexander Wels aw...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 8:23:06 PM Subject: Re: Packaging and locales Hi Alon, The available languages of oVirt's gwt-based portals are determined during compilation time. for run-time optimization purposes, the gwt-compiler executes a compilation-permutation per browser + per language. Hmmm... this what I was afraid of... I assume that we can construct separate ovirt-engine[-*] packages, each one contains the gwt-based portals that were compiled only with the relevant locales (permutations). if we will do that, we won't be able to maintain all locales within the same web-application anymore (currently, the web-admin is a single web-application that supports all locales, same goes for the user-portal) - doing a separate web-application per locale probably makes more sense. also: could be trivial to do, but need to keep in mind that for every code-change, we will need to issue an update for each one of the ovirt-engine[-*] packages, and somehow make sure that the user will yum update *all* packages that he originally yum installed, in order to avoid applications in different locales going out-of-sync. Oh... this what I fear... if permutation include code + locale then this is no go for this approach. The separate package should contain locale only, so at worse case scenario you get locale C as default. Let's say going modular is too complicated for gwt based application... however, any reason why we do not build all locales by default? For development we can limit number of permutations, but default rpmbuild -tb tarball should build all available locales. when you are asking why we do not build all locales by default? I understand that you are referring specifically to an rpmbuild build, and NOT to a devel-time mvn build that a full-time ovirt-engine-GUI-maintainer performs 5 times a day, at least... so if I understood you correctly - indeed, I agree that the default rpmbuild should build with all available locales, assuming this is a non-frequent action, so the person performing it typically won't care if it takes some extra time, especially if it means that he will eventually gain a couple of extra available locales. Yes, building via Makefile, developers use maven directly. Currently we have: BUILD_FLAGS=-P gwt-admin,gwt-user I guess it should be replaced it with: BUILD_FLAGS=-P gwt-admin,gwt-user,all-langs To build the entire feature set of application. Thanks! Alon Thanks, Einav - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Alexander Wels aw...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 3:44:15 AM Subject: Packaging and locales Hello, From recent thread I learned that we package locales within our main package, message bundles are going into jars, and by default we do not build them all. As this is GWT specific as far as I see in build, I have no real visibility of what happening. However, I do expect locales to be packaged and installed as separate packages, side by side with main package. Something like: # yum install ovirt-engine - provides en_US # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. This ease maintenance, as these translations can be maintain using their own release cycle and even out of main tree. Any thoughts? Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] storage overallocation ratio
Hi, I was trying to find out how is this actually calculated. Doesn't look very straightforward…:) I'm curious about the following - vdsm reports something like truesize and apparentsize which IIUC should be distinct but then in engine, in backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java it's written to the same engine property actual_size. That doesn't sound right. Can someone enlighten me please? Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Cloud-Init integration
On 03/29/2013 01:35 AM, Greg Padgett wrote: Hi Everyone, I'd like to propose a feature we've been doing some investigation into, which is to integrate cloud-init support into oVirt. Cloud-init is used to help provision new Linux systems by setting the hostname, ip, ssh keys, timezone, injecting files, and more. It's used by OpenStack (amongst others) now, and has a lot of features that may be helpful to our users. Details are still evolving, but for more info please see the wiki page: http://www.ovirt.org/Features/Cloud-Init_Integration All feedback is welcome! a few questions: - are you planning to save the info in the db by field, or as a single blob? maybe a better questions is are you going to persist it at all? - i'd be careful before passing any passwords (page mentions root password) - you'd need to not persist it unecrypted, identify it and clean it from all logs, etc. - hostname - should just assume the vm name? - timezone - is that different than the windows one? for a windows guest as well? Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] FeatureSupported and compatibility versions
On 03/20/2013 04:47 PM, Shireesh Anjal wrote: Why are we even storing this information in config? Is this something that can be configured at customer site? some features can be disabled, and only enabled by someone aware of the implications of enabling them. that's apart of the versions they are supported at i guess ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Packaging and locales
- Original Message - From: Einav Cohen eco...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, Alexander Wels aw...@redhat.com, Juan Hernandez jhern...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Saturday, April 20, 2013 10:25:41 PM Subject: Re: Packaging and locales Currently we have: BUILD_FLAGS=-P gwt-admin,gwt-user I guess it should be replaced it with: BUILD_FLAGS=-P gwt-admin,gwt-user,all-langs To build the entire feature set of application. exactly. http://gerrit.ovirt.org/14083 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
