[Engine-devel] What type of DB inheritance to use?
Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] What type of DB inheritance to use?
On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ 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] What type of DB inheritance to use?
- Original Message - On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? Quantum provider in the 1st implementation will not require these fields. It will eventually require some sort of authentication, but not necessarily these fields, or only these fields. In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ 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] What type of DB inheritance to use?
On 05/12/2013 03:16 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? Quantum provider in the 1st implementation will not require these fields. It will eventually require some sort of authentication, but not necessarily these fields, or only these fields. I'm not talking about a POC. unless we pass through credentials of users for some actions, how do you use a provider without user/password (or client cert, etc. - i.e., all authentication methods are usually similar on the info you need to persist)? In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ 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] What type of DB inheritance to use?
- Original Message - On 05/12/2013 03:16 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? Quantum provider in the 1st implementation will not require these fields. It will eventually require some sort of authentication, but not necessarily these fields, or only these fields. I'm not talking about a POC. unless we pass through credentials of users for some actions, how do you use a provider without user/password (or client cert, etc. - i.e., all authentication methods are usually similar on the info you need to persist)? I did not say that we will use Quantum without auth, only that these fields may or may not necessarily be in the Quantum provider entity. I think this is regardless of the main discussion here of inheritance, which I think will happen regardless of how Quantum provider is implemented. If you wish to discuss these details I'll be happy do it on a new thread, so that this one can stay focused on the subject of DB inheritance. In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ 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] VDSM Fake
On 04/30/2013 02:00 PM, Libor Spevak wrote: I didn't have enough time to make a real stress test, I created 100 hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM Fake. I put the VMs into running state and tried migration. It was rather responsive. The server had still enough resources. On 30.4.2013 12:48, Liran Zelkha wrote: Awesome. I really need this for the stress tests I'm running. How many hosts were you able to simulate with one web application? - Original Message - From: Libor Spevak lspe...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 12:50:52 PM Subject: [Engine-devel] VDSM Fake Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor ___ 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 how different in what you can scale compared to fake vdsm? http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/faqemu ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] What type of DB inheritance to use?
On 05/12/2013 04:31 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 03:16 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? Quantum provider in the 1st implementation will not require these fields. It will eventually require some sort of authentication, but not necessarily these fields, or only these fields. I'm not talking about a POC. unless we pass through credentials of users for some actions, how do you use a provider without user/password (or client cert, etc. - i.e., all authentication methods are usually similar on the info you need to persist)? I did not say that we will use Quantum without auth, only that these fields may or may not necessarily be in the Quantum provider entity. I think this is regardless of the main discussion here of inheritance, which I think will happen regardless of how Quantum provider is implemented. If you wish to discuss these details I'll be happy do it on a new thread, so that this one can stay focused on the subject of DB inheritance. how many discrepancies do we expect between the various providers, to be actually defined at provider level rather than consumption level? In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ 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] [ANN] New development environment for ovirt-engine
Hello, As promised, I updated the wiki pages of engine developer environment to refer to this[1] single new page, I hope in time we can merge all non-trivial contributions into the README.developer. Feel free to contribute/fix as you experience issues. Regards, Alon Bar-Lev. [1] http://www.ovirt.org/OVirt_Engine_Development_Environment - Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Yaniv Bronheim ybron...@redhat.com, Moti Asayag masa...@redhat.com, Limor Gavish lgav...@gmail.com, Sharad Mishra snmis...@us.ibm.com, Alex Lourie alou...@redhat.com, Sandro Bonazzola sbona...@redhat.com, arch a...@ovirt.org, Ofer Schreiber oschr...@redhat.com Sent: Sunday, May 12, 2013 2:52:51 PM Subject: [ANN] New development environment for ovirt-engine Hello all ovirt-engine developers, When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production. I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse. I had no other option than to create rpms after each of my changes and test each in real production like setup. It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization. I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment. Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine. A complete documentation is available[1], I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up. In a nut shell, after installing prerequisites, build and install the product using: $ make clean install-dev PREFIX=$HOME/ovirt-engine This will run maven and create product installation at $HOME/ovirt-engine Next, a setup phase is required just like in production, to initialize configuration and database: $ $HOME/ovirt-engine/bin/engine-setup-2 You have now fully functional product, including PKI, SSL, host-deploy, tools. No manual database updates are required, no lose of functionality. All that is left is to start the engine service: $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start Access to application: http://localhost:8080 https://localhost:8443 Debugging port is opened at port 8787. Farther information exists in the documentation[1]. There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time! We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that? We are sure there are missing bits, we will be happy to know these so we can improve. I am aware that developers (especially java) are conservative, but I ask you to give us
