Re: [Engine-devel] rewrite the engine-notifier service wrapper
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Juan Hernandez jhern...@redhat.com, Simon Grinberg si...@redhat.com Sent: Tuesday, April 23, 2013 1:15:01 AM Subject: [Engine-devel] rewrite the engine-notifier service wrapper Hello, After finish to cleanup the engine-service to use downstream services and be portable to other distributions (upstart, openrc), we can use the same infrastructure for the engine notifier script. It is very similar to the engine-service in operation (running java), except it is written in bash instead of python and has no systemd support, and have its own configuration. What I suggest is to rewrite the notifier service in python and reuse the engine-service code. Also, drop the /etc/ovirt-engine/notifier/notifier.conf in favor of variables within the /etc/ovirt-engine/engine.conf[.d/*], this will provide a single point of configuration for all services. And of course proper systemd support and development environment support. Any comments? thoughts? Alon IMHO - +1 , the sooner the better - start with that and move to all the other bash scripts of the tools ;) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] some cleanup
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 22, 2013 8:27:00 PM Subject: [Engine-devel] some cleanup Hi, Some of my patches are waiting for a brave reviewer to +2 them :) - entity cleanups http://gerrit.ovirt.org/13531 http://gerrit.ovirt.org/13705 http://gerrit.ovirt.org/13940 http://gerrit.ovirt.org/13705 - command cleanups http://gerrit.ovirt.org/13945 http://gerrit.ovirt.org/13946 http://gerrit.ovirt.org/13947 Thx, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Done ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Introducing Infinispan cache and some required actions after change
- Original Message - From: Michael Kublin mkub...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 23, 2013 10:30:09 AM Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change Hi All, The following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7 will introduce a in memory cache inside ovirt-engine The cache which was chosen is infinispan (http://www.jboss.org/infinispan/) The reasons are following: cache has all required functionality, it is open source project and has built-in integration with JBOSS, all cache configuration can be accessed or edited via JBOSS admin console. By introducing this commit the first stage is finished: 1. Cache implementation is added to project 2. Show example how to add and use a cache in ovirt-engine, if it is required 3. Solved bug with possible memory leak in audit log event The next stages are: 1. Second stage - replace all custom made implementation by standard central cache implementation 2. Third stage - introduce second level cache for work with DB 3. Fourth stage (Future) - make cluster wise cache or make cache as service, if we will have more than one instance of JBOSS Now, after the applying the following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7, everyone who works with ovirt-engine will be required to perform the following operation 1. Run mvn clean install -Pdep,setup in order to replace an old standalone.xml with new version of it Or 1. Use regular deploy: mvn clean install -Pdep 2. Access to $JBOSS_HOME/bin/standalone.xml and replace or add infinispan subsystem: subsystem xmlns=urn:jboss:domain:infinispan:1.1 default-cache-container=ovirt-engine cache-container name=ovirt-engine default-cache=timeout-base jndi-name=java:jboss/infinispan/ovirt-engine start=EAGER local-cache name=timeout-base transaction mode=NONE/ eviction max-entries=1/ expiration interval=6/ /local-cache /cache-container /subsystem 3. Add or check that exists extension module=org.jboss.as.clustering.infinispan/ under extensions element Great! Minor addition - For those of you who are familiar with the term region (exists at JBoss Cache, and IIRC ehcache) - look at the configuration Michael provided for timeout-base. Infinspan supports transactions (see the transaction-mode) and supports distribution (currently at local mode - see the local-cache definition). Yair Thanks and Regards Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Introducing Infinispan cache and some required actions after change
Great news. I totally agree that Infinispan is the right way to go. Michael - let's sync on the database caching integration with Infinispan. Would love to hear your thoughts. - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Kublin mkub...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 23, 2013 10:45:47 AM Subject: Re: [Engine-devel] Introducing Infinispan cache and some requiredactions after change - Original Message - From: Michael Kublin mkub...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 23, 2013 10:30:09 AM Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change Hi All, The following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7 will introduce a in memory cache inside ovirt-engine The cache which was chosen is infinispan (http://www.jboss.org/infinispan/) The reasons are following: cache has all required functionality, it is open source project and has built-in integration with JBOSS, all cache configuration can be accessed or edited via JBOSS admin console. By introducing this commit the first stage is finished: 1. Cache implementation is added to project 2. Show example how to add and use a cache in ovirt-engine, if it is required 3. Solved bug with possible memory leak in audit log event The next stages are: 1. Second stage - replace all custom made implementation by standard central cache implementation 2. Third stage - introduce second level cache for work with DB 3. Fourth stage (Future) - make cluster wise cache or make cache as service, if we will have more than one instance of JBOSS Now, after the applying the following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7, everyone who works with ovirt-engine will be required to perform the following operation 1. Run mvn clean install -Pdep,setup in order to replace an old standalone.xml with new version of it Or 1. Use regular deploy: mvn clean install -Pdep 2. Access to $JBOSS_HOME/bin/standalone.xml and replace or add infinispan subsystem: subsystem xmlns=urn:jboss:domain:infinispan:1.1 default-cache-container=ovirt-engine cache-container name=ovirt-engine default-cache=timeout-base jndi-name=java:jboss/infinispan/ovirt-engine start=EAGER local-cache name=timeout-base transaction mode=NONE/ eviction max-entries=1/ expiration interval=6/ /local-cache /cache-container /subsystem 3. Add or check that exists extension module=org.jboss.as.clustering.infinispan/ under extensions element Great! Minor addition - For those of you who are familiar with the term region (exists at JBoss Cache, and IIRC ehcache) - look at the configuration Michael provided for timeout-base. Infinspan supports transactions (see the transaction-mode) and supports distribution (currently at local mode - see the local-cache definition). Yair Thanks and Regards Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] storage overallocation ratio
Hi Michal, apparentsize is the size that you perceive when working with the volume (i.e., ignoring sparseness etc.) while trusize is the size taken on the drive (i.e., taking sparseness etc. into account). DiskImage.getActualSize() should report the truesize. The end result is OK, since truesize overrides apparentsize in that command, but it's obviously wrong, and should be fixed [1]. [1] http://gerrit.ovirt.org/#/c/14176/ - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Saturday, April 20, 2013 11:13:04 PM Subject: [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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] rewrite the engine-notifier service wrapper
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, Simon Grinberg si...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, April 23, 2013 10:07:39 AM Subject: Re: [Engine-devel] rewrite the engine-notifier service wrapper - Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Juan Hernandez jhern...@redhat.com, Simon Grinberg si...@redhat.com Sent: Tuesday, April 23, 2013 1:15:01 AM Subject: [Engine-devel] rewrite the engine-notifier service wrapper Hello, After finish to cleanup the engine-service to use downstream services and be portable to other distributions (upstart, openrc), we can use the same infrastructure for the engine notifier script. It is very similar to the engine-service in operation (running java), except it is written in bash instead of python and has no systemd support, and have its own configuration. What I suggest is to rewrite the notifier service in python and reuse the engine-service code. Also, drop the /etc/ovirt-engine/notifier/notifier.conf in favor of variables within the /etc/ovirt-engine/engine.conf[.d/*], this will provide a single point of configuration for all services. And of course proper systemd support and development environment support. Any comments? thoughts? Alon IMHO - +1 , the sooner the better - start with that and move to all the other bash scripts of the tools ;) +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Cloud-Init integration
Hi Itamar, On 04/20/2013 04:52 PM, Itamar Heim wrote: 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? No persistence yet, but when that time comes I'd prefer to store the fields (either separately or a standard serialized format), rather than storing the generated blob. Easier to retrieve/modify. - 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. I've looked into this a little: cloud-init will accept a password that's been crypt(3)'ed, and Apache Commons Codec has a Crypt API that will do this--but not in our version, it's new in 1.7. So, still considering alternatives. - hostname - should just assume the vm name? Sure, how about pre-populating the field? The user would see that we're setting the hostname and be able to change it if desired. - timezone - is that different than the windows one? for a windows guest as well? AFAICT, a healthy subset of timezones can be mapped cleanly between Linux/Java/Windows representations, and the Java timezone ids look to be a fairly good match for the timezone files used in Linux. I hope we don't have to show different timezone selections based on OS type, but not sure yet. (Should know soon, I'm looking into all this now.) Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] some cleanup
Thank you Michael! - Original Message - From: Michael Kublin mkub...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, April 23, 2013 9:39:11 AM Subject: Re: [Engine-devel] some cleanup - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 22, 2013 8:27:00 PM Subject: [Engine-devel] some cleanup Hi, Some of my patches are waiting for a brave reviewer to +2 them :) - entity cleanups http://gerrit.ovirt.org/13531 http://gerrit.ovirt.org/13705 http://gerrit.ovirt.org/13940 http://gerrit.ovirt.org/13705 - command cleanups http://gerrit.ovirt.org/13945 http://gerrit.ovirt.org/13946 http://gerrit.ovirt.org/13947 Thx, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Done ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
