[Engine-devel] Adding JCommander library to projects
Hi, I'm currently working on bug 904029, support for POSIX parameters and values in engine-manage-domains. I think there are two possible solutions: 1) Write custom parser (similar to EngineConfigCLIParser used for engine-config) 2) Add CLI parsing library to project and use it for all command line clients (first implementation could be for engine-manage-domains) I think 2) is much better approach, but I'm not sure about the process of adding new library to project. Personally I like JCommander ( http://jcommander.org ), using annotation for parameter specification is great. JCommander is licensed with Apache 2.0 license, so the addition shouldn't be a problem. So, would it be possible to add JCommander library to project? Martin Perina ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Adding JCommander library to projects
- Original Message - > From: "Martin Perina" > To: engine-devel@ovirt.org > Sent: Thursday, March 28, 2013 10:48:07 AM > Subject: [Engine-devel] Adding JCommander library to projects > > Hi, > > I'm currently working on bug 904029, support for POSIX parameters and > values > in engine-manage-domains. I think there are two possible solutions: > > 1) Write custom parser (similar to EngineConfigCLIParser used for > engine-config) > 2) Add CLI parsing library to project and use it for all command > line clients > (first implementation could be for engine-manage-domains) > > I think 2) is much better approach, but I'm not sure about the > process of adding new > library to project. > > Personally I like JCommander ( http://jcommander.org ), using > annotation for parameter > specification is great. JCommander is licensed with Apache 2.0 > license, so the addition > shouldn't be a problem. > > So, would it be possible to add JCommander library to project? I believe that any other solution will be better than current situation. However, I recommend of horizontal change when such introduced, leaving hybrid implementation in tree will just make maintenance cost higher when introducing new dependency. It should not be that difficult to port all current implementation to the new dependency when selected. Regards, Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Adding JCommander library to projects
- Original Message - > From: "Alon Bar-Lev" > To: "Martin Perina" > Cc: engine-devel@ovirt.org > Sent: Thursday, March 28, 2013 10:18:19 AM > Subject: Re: [Engine-devel] Adding JCommander library to projects > > > > - Original Message - > > From: "Martin Perina" > > To: engine-devel@ovirt.org > > Sent: Thursday, March 28, 2013 10:48:07 AM > > Subject: [Engine-devel] Adding JCommander library to projects > > > > Hi, > > > > I'm currently working on bug 904029, support for POSIX parameters > > and > > values > > in engine-manage-domains. I think there are two possible solutions: > > > > 1) Write custom parser (similar to EngineConfigCLIParser used for > > engine-config) > > 2) Add CLI parsing library to project and use it for all command > > line clients > > (first implementation could be for engine-manage-domains) > > > > I think 2) is much better approach, but I'm not sure about the > > process of adding new > > library to project. > > > > Personally I like JCommander ( http://jcommander.org ), using > > annotation for parameter > > specification is great. JCommander is licensed with Apache 2.0 > > license, so the addition > > shouldn't be a problem. > > > > So, would it be possible to add JCommander library to project? > > I believe that any other solution will be better than current > situation. > > However, I recommend of horizontal change when such introduced, > leaving hybrid implementation in tree will just make maintenance > cost higher when introducing new dependency. It should not be that > difficult to port all current implementation to the new dependency > when selected. > > Regards, > Alon. > Sure, reference implementation will be for engine-manage-domains and after that I will implement this solution for the rest of commands. Martin ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review
Hi Dave, I would like to raise again the question of the full cache flash for each stale cache entry found. This method can cause two unwanted situations: 1. Choosing untrusted host: lets say, for example that you have 1000 host in your pool. you look at the first host in the cache and find that its attestation hat expired. you refresh the entire pool (there are 1000 host, that must take some time). by the the time the last host was refreshed in the pool, the first host may already be expired again. but since you already checked it - you keep on with your flow and select that host, even so it has expired and may as well be untrusted. 2. infinite loop: lets say we'll try to fix what I've described in 1. then, we need to check again if the host has expired before we select it. if it is, the entire refresh process starts again. this could potentially go on forever (unless I'm missing something, and the expiration is much longer then the full re-cache process). Instead of re-caching the full cache we can do as follows: - hold the cache entries sorted by expiration (if the expiration time is the same for all hosts, so a queue is enough). - each time we need a new trusted host - select from the unexpired hosts, refresh all expired hosts (in one query). - if all hosts are expired - we can wait for the first host to be defined trusted by the attestation server and select that host. Ofri - Original Message - > From: "Wei D Chen" > To: engine-devel@ovirt.org > Sent: Friday, March 22, 2013 11:34:55 AM > Subject: [Engine-devel] Open Attestation integration with oVirt engine > proposal has submitted patchset5 for your > review > > Hi all, > > Before submitting this patch set, we has updated our design page, and > new feature about VM template has added to this patchset. In > patchset a lot of frontend changes has been imported. > Welcome to review our patchset and thanks advance for your > suggestion. > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > In this patch set, follow changes has been introduced: > > 1. GUI changes to support for creating a trusted VM on a trusted > physical host. > 2. View/Edit VM changes to enable end user switch between three run > on options. > 3. Template relevant changes to support end user create a trusted VM > template and create trusted VM based on this template afterwards. > 4. Bug fixing and code cleanup. > 5. wiki design page update. > > > > Best Regards, > Dave Chen > > > ___ > 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] FeatureSupported and compatibility versions
On 03/27/2013 05:48 PM, Mike Kolesnik wrote: - Original Message - On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: - Original Message - From: "Shireesh Anjal" To: "Mike Kolesnik" Cc: engine-devel@ovirt.org Sent: Wednesday, March 20, 2013 4:47:08 PM Subject: Re: [Engine-devel] FeatureSupported and compatibility versions On 03/18/2013 01:11 PM, Shireesh Anjal wrote: On 03/18/2013 12:59 PM, Mike Kolesnik wrote: - Original Message - Hi all, The current mechanism in oVirt to check whether a feature is supported in a particular compatibility version is to use the FeatureSupported class. e.g. FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) Checks whether the "network linking" feature is supported for the the VM's cluster compatibility version. This internally checks whether the value of the corresponding config (NetworkLinkingSupported) for the given compatibility version is true/false. I'm not sure if this is a good idea, since a feature is typically supported "from" a particular version. E.g. Gluster support was introduced in 3.1, and it continues to be available in all subsequent versions. So I see no point in adding configuration for every version indicating whether the feature is supported in that version or not. I suggest to use either of the following options: You can "merge" the configs into a single config when older versions go out of the supported versions for the system. i.e. in 4.0 you can have upgrade script that merges all GlusterFeatureSupported to one entry instead of several. Why are we even storing this information in config? Is this something that can be "configured" at customer site? As previously explained (but off list :) ) , Config gives you the ability to have a cachable "map" of entry (i.e - "feature name") per version and value. I guess it was convinient for the developers to use that. I also mentioned that customers/oVirt users should config the entries of vdc_options using engine-config tool only. Not all entries are exposed via engine-config.properties (and no, not just "is feature supported" entries are hidden). 1) Instead of using a boolean config for each version, use a single string config that indicates the "supported from" version e.g. GlusterSupportedFrom = 3.1. There could be rare cases where a feature, for some reason, is removed in some release. In such cases, we could use one additional config for the "supported to" version. 2) Continue with the boolean approach, but do not have entries for every version; rather make use of the "default value" for majority of cases, and add the explicit version mapping for the minority e.g. GlusterSupported = true by default, and false in case of 3.0 (only one config required for 3.0) I'm not sure why we would want to complicate this simple mechanism? Is there much to gain? I think option 1 suggested above is simpler - to implement as well as to understand. Let me give you an example of why I don't like current mechanism. I introduce a version check for a feature that was introduced in 3.1. I'm being asked now to add three entries in config 3.0 - false 3.1 - true 3.2 - true It will also mean that when 3.3 goes out, someone has to make sure that another entry is added for 3.3-true. I think it is not logical as well as scalable if you have more versions. And it sounds far more complex (to maintain) than just having SupportedFrom = 3.1 So I would like to know if there are any objections to my proposal. I intend to use this for at least the gluster related features. I've sent a patch (http://gerrit.ovirt.org/12970) with following changes: 1) Introduced CompatibilityUtils that provides utility methods for checking if a given feature is supported in the config. One method to check based on boolean values (as is being done today for virt features), and nother to check based on a range (from, to) which I would like to use for gluster features. 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use the first utility method from CompatibilityUtils 3) Introduced GlusterFeatureSupported for gluster features, which uses the second utility method from CompatibilityUtils Key advantage here is that - we don't have to touch any virt specifc source for adding compatibility checks for gluster features - virt features continue to use the existing boolean config check Any comments / suggestions / reviews will be highly appreciated :) I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. Review comments here are on the contrary: http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/_config.sql I don't think "From, To, etc" is a good design, it's not a standard way and is very restrictive. Can you please explain in what way is it restrictive?
Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review
- Original Message - > From: "Ofri Masad" > To: "Wei D Chen" > Cc: engine-devel@ovirt.org > Sent: Thursday, March 28, 2013 12:05:02 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > proposal has submitted patchset5 for your > review > > Hi Dave, > > I would like to raise again the question of the full cache flash for > each stale cache entry found. > This method can cause two unwanted situations: > 1. Choosing untrusted host: lets say, for example that you have 1000 > host in your pool. you look at the first host in the cache and find > that its attestation hat expired. you refresh the entire pool > (there are 1000 host, that must take some time). by the the time > the last host was refreshed in the pool, the first host may already > be expired again. but since you already checked it - you keep on > with your flow and select that host, even so it has expired and may > as well be untrusted. > > 2. infinite loop: lets say we'll try to fix what I've described in > 1. then, we need to check again if the host has expired before we > select it. if it is, the entire refresh process starts again. this > could potentially go on forever (unless I'm missing something, and > the expiration is much longer then the full re-cache process). > > Instead of re-caching the full cache we can do as follows: > - hold the cache entries sorted by expiration (if the expiration > time is the same for all hosts, so a queue is enough). > - each time we need a new trusted host - select from the unexpired > hosts, refresh all expired hosts (in one query). > - if all hosts are expired - we can wait for the first host to be > defined trusted by the attestation server and select that host. > > Ofri > > Dave, adding another suggestion on top of Ofri's; Generally speaking, a cluster of hosts defines many joint features (such as CPU level), which means that in the same cluster we would expect to be able to freely migrate a VM from one host to another. Current trust-pools design is breaking this concept, as you introduce a state where a VM cannot migrate from a 'safe' host into an 'unsafe' host. This leads me to the suggestion of having attestation as a cluster policy rather than a VM-level property. It means that all hosts in this cluster are constantly being monitored to be safe. If a host is declared as unsafe in the Attestation server, it will become non-operational in the engine. This will simplify the implementation since you have everything ready for you once you have a 'safe' cluster and no need to do any VM-level changes. So in this way you keep current concepts while simplifying the implementation with very little worries of performance issues. Can you please share your thoughts on this suggestion? > - Original Message - > > From: "Wei D Chen" > > To: engine-devel@ovirt.org > > Sent: Friday, March 22, 2013 11:34:55 AM > > Subject: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your > > review > > > > Hi all, > > > > Before submitting this patch set, we has updated our design page, > > and > > new feature about VM template has added to this patchset. In > > patchset a lot of frontend changes has been imported. > > Welcome to review our patchset and thanks advance for your > > suggestion. > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > In this patch set, follow changes has been introduced: > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > physical host. > > 2. View/Edit VM changes to enable end user switch between three run > > on options. > > 3. Template relevant changes to support end user create a trusted > > VM > > template and create trusted VM based on this template afterwards. > > 4. Bug fixing and code cleanup. > > 5. wiki design page update. > > > > > > > > Best Regards, > > Dave Chen > > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Move SQL out of stored procedures
Hi, apart from SQL vs. stored procedures discussion, I am trying to understand what we can get if we support more databases... Some points: 1. Is there a real need by end-users/customers to run it on e.g. Oracle only? (performance, stability, easier administration). What is the future of PostgreSQL? 2. Is it decided by architectural board, what kind of databases we would like to support? (cannot support any db) 3. Are we talking about the Engine only, or there will be a need to rewrite ETL mappings and upgrade DWH database, or maybe modify JasperReports templates (simply, some DB types behave differently)? Maybe we can look at JasperSoft solution, they support more databases. 4. Current full/incremental upgrade process of PostgreSQL is IMHO very good tuned (it is similar to dbmaintain.org tool - Java implementation - I used successfully on one project - after some changes of course). I do not believe we can use or easily develop general upgrade/migration tool, and XML based (I am sorry Alissa, not sure about Liquibase, I haven't studied it deeply, but there is a need to incrementally change db objects, but sometimes also to migrate data to new structures, the most flexible and quickest is to do it using native SQL, but yes, it depends on the project needs...). 5. As a developer, with every new column I need to write upgrade scripts, prepare test environments and test all scenarios several times on different databases, so time-consuming. On 27.3.2013 13:53, Itamar Heim wrote: On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: - Original Message - From: "Juan Hernandez" To: engine-devel@ovirt.org Sent: Tuesday, March 26, 2013 7:34:04 PM Subject: [Engine-devel] Move SQL out of stored procedures Hello, I would like to start a discussion about the subject. I think this is something we need to do if one day we want to be able to use any database other than PostgreSQL. Hello, I think that database layer is a software interface like any other software interface, if done properly, a dba can convert the stored procedure to any other database without any code change. This way the database specific implementation lives within the database and maintained by the designated dba. Fixups and optimizations can be done in database without touching the code. Backward compatibility layer is much simpler to implement based on stored procedures than complex set of views and tables. Also, accessing the database via different technologies is simpler if there is maintained database interface (stored procedures). I've seen hibernate based java applications that promised to be database independent but at the edges when performance counts, the DAO became HQL, then a special dialect and finally database specific SQLS. there may be db specific optimization/logic, but I don't see why we need STPs for 80% (if not more) of the CRUD and basic queries. I also agree with Tal later in the thread that its a good question if we can't find a better solution than re-writing the sql's in the code ___ 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] UI Plugin API improvements
Hi guys,
I've just merged some UI Plugin patches that improve existing API functions, as
well as add some new API functions. Please read on to learn what's new.
Modal dialog API
Function improved: showDialog
New signature:
showDialog(title, dialogToken, contentUrl, width, height [, options])
Example usage:
showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px',
'600px', {
// Default value = empty array (no buttons)
buttons: [
{
label: 'Do stuff',
onClick: function() {
alert('Bump!');
}
}
],
// Default value = false
resizeEnabled: true,
// Default value = true
closeIconVisible: true,
// Default value = true
closeOnEscKey: true
});
Notable changes:
* modal dialogs now look & feel the same as standard WebAdmin dialogs
* width & height are strings containing CSS units
* the reason why buttons default to empty array is to give plugin authors the
choice to provide custom buttons (or similar input elements) via dialog content
(iframe), and use HTML5 window.postMessage to call the plugin (coming soon!)
--
New function: setDialogContentUrl
New signature:
setDialogContentUrl(dialogToken, contentUrl)
Example usage:
setDialogContentUrl('my-dialog', 'http://www.example.com/')
--
New function: closeDialog
New signature:
closeDialog(dialogToken)
Example usage:
closeDialog('my-dialog')
Tab API
===
Functions improved: addMainTab & addSubTab
New signatures:
addMainTab(label, historyToken, contentUrl [, options])
addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
Example usage:
// Tab is left-aligned by default
addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
// Tab is right-aligned via options object
addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', {
alignRight: true
});
--
Regards,
Vojtech
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Move SQL out of stored procedures
- Original Message - > From: "Libor Spevak" > To: "Itamar Heim" > Cc: "Juan Hernandez" , engine-devel@ovirt.org > Sent: Thursday, March 28, 2013 4:04:20 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > Hi, > > apart from SQL vs. stored procedures discussion, I am trying to > understand what we can get if we support more databases... > > Some points: > 1. Is there a real need by end-users/customers to run it on e.g. > Oracle > only? (performance, stability, easier administration). Usually companies have one database and they are trying to stick to that one. Having two doubles the resource needs, you need one more DBA team, care for mirrors, backups. So it almost doubles the costs. This is why I frequently hear people asking if we plan to support XyDB in the future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they just do not want one more. > What is the future of PostgreSQL? > > 2. Is it decided by architectural board, what kind of databases we > would > like to support? (cannot support any db) With a JPA we could support most mainstream relational databases, but in my opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So maybe we do not have to think in big number of database engines. This is theoretical since JPA is still on wishlist :( > > 3. Are we talking about the Engine only, or there will be a need to > rewrite ETL mappings and upgrade DWH database, or maybe modify > JasperReports templates (simply, some DB types behave differently)? > Maybe we can look at JasperSoft solution, they support more > databases. > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > very > good tuned (it is similar to dbmaintain.org tool - Java > implementation - > I used successfully on one project - after some changes of course). I > do > not believe we can use or easily develop general upgrade/migration > tool, > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > studied it deeply, but there is a need to incrementally change db > objects, but sometimes also to migrate data to new structures, the > most > flexible and quickest is to do it using native SQL, but yes, it > depends > on the project needs...). > > 5. As a developer, with every new column I need to write upgrade > scripts, prepare test environments and test all scenarios several > times > on different databases, so time-consuming. > > > On 27.3.2013 13:53, Itamar Heim wrote: > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > >> > >> > >> - Original Message - > >>> From: "Juan Hernandez" > >>> To: engine-devel@ovirt.org > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > >>> Subject: [Engine-devel] Move SQL out of stored procedures > >>> > >>> Hello, > >>> > >>> I would like to start a discussion about the subject. I think > >>> this is > >>> something we need to do if one day we want to be able to use any > >>> database other than PostgreSQL. > >> > >> Hello, > >> > >> I think that database layer is a software interface like any other > >> software interface, if done properly, a dba can convert the stored > >> procedure to any other database without any code change. > >> > >> This way the database specific implementation lives within the > >> database and maintained by the designated dba. > >> > >> Fixups and optimizations can be done in database without touching > >> the > >> code. > >> > >> Backward compatibility layer is much simpler to implement based on > >> stored procedures than complex set of views and tables. > >> > >> Also, accessing the database via different technologies is simpler > >> if > >> there is maintained database interface (stored procedures). > >> > >> I've seen hibernate based java applications that promised to be > >> database independent but at the edges when performance counts, the > >> DAO became HQL, then a special dialect and finally database > >> specific > >> SQLS. > > > > there may be db specific optimization/logic, but I don't see why we > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > I also agree with Tal later in the thread that its a good question > > if > > we can't find a better solution than re-writing the sql's in the > > code > > > > ___ > > 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] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment?
On 03/28/2013 03:14 AM, Chen, Wei D wrote: Just want to setup 3.2.0 or 3.2.1 ovirt engine running environment. Thanks. if you already have 3.2.0 installed, I suggest running engine-upgrade. if its a clean system, just install 3.2.1. Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, March 27, 2013 8:39 PM To: Chen, Wei D Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? On 03/26/2013 05:50 AM, Chen, Wei D wrote: Hi, We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? re-setup as in destroy and re-install, or just upgrade (engine-upgrade should take care of that for you) Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. Best Regards, Dave Chen ___ 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] Cloud-Init integration
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! Thanks, Greg ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] [ANN] Development environment and Gentoo packaging (preview)
Hello All, We[1] are working to rewrite the current installer to something more portable and flexible. Currently two milestones had been reached: 1. Ability to install almost fully functioning ovirt-engine at $HOME for development environment. 2. Porting ovirt-engine to run on different distribution, Gentoo. We will be glad to receive feedback on either. Code is located at github[2] for now, at otopi branch. Instructions for setting up development environment are available[3]. Gentoo overlay for live ebuilds is available[4], the following packages are valid: - app-emulation/otopi - app-emulation/ovirt-host-deploy - app-emulation/ovirt-jboss-bin - app-emulation/ovirt-engine Why Gentoo first? because source based distributions demands the highest level of customization, solving the complex issue ease to continue porting to binary based distributions. Please remember that this is work in progress, and not guarantee to be stable or even work... The installer was re-written from scratch so expect issues at this point. Any feedback is welcomed, we are focusing first in providing the functionality of the existing installer to be able to replace it entirely before going into new adventures. Regards, Alon Bar-Lev. [1] Alex Lourie, Sandro Bonazzola, Alon Bar-Lev [2] https://github.com/alonbl/ovirt-engine [3] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer [4] https://github.com/alonbl/ovirt-overlay ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review
Thanks Doron & Ofri, As to the question of cache flash, we already have our consideration and wrote them on our design page. I have no doubt that your suggestion is more reasonable, we just keep in mind that expiration is much longer that the time needed to poll all of hosts, so this is really a potential issue we ignored. Let's make estimation at first, we will have a try if our schedule is okay. Doron, we have reserved some effort to research about cluster-level policy. As ovirt is complete new to our engineers, would we finished our current features (such as ovf and rest api.) in pipeline at first? After these basic features are ready and we still have some buffer, we will make some improvement. Is this acceptable? Thanks again to Doron and Ofri. Best Regards, Dave Chen -Original Message- From: Doron Fediuck [mailto:dfedi...@redhat.com] Sent: Thursday, March 28, 2013 10:43 PM To: Ofri Masad Cc: engine-devel@ovirt.org; Chen, Wei D Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review - Original Message - > From: "Ofri Masad" > To: "Wei D Chen" > Cc: engine-devel@ovirt.org > Sent: Thursday, March 28, 2013 12:05:02 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > engine proposal has submitted patchset5 for your review > > Hi Dave, > > I would like to raise again the question of the full cache flash for > each stale cache entry found. > This method can cause two unwanted situations: > 1. Choosing untrusted host: lets say, for example that you have 1000 > host in your pool. you look at the first host in the cache and find > that its attestation hat expired. you refresh the entire pool (there > are 1000 host, that must take some time). by the the time the last > host was refreshed in the pool, the first host may already be expired > again. but since you already checked it - you keep on with your flow > and select that host, even so it has expired and may as well be > untrusted. > > 2. infinite loop: lets say we'll try to fix what I've described in > 1. then, we need to check again if the host has expired before we > select it. if it is, the entire refresh process starts again. this > could potentially go on forever (unless I'm missing something, and > the expiration is much longer then the full re-cache process). > > Instead of re-caching the full cache we can do as follows: > - hold the cache entries sorted by expiration (if the expiration > time is the same for all hosts, so a queue is enough). > - each time we need a new trusted host - select from the unexpired > hosts, refresh all expired hosts (in one query). > - if all hosts are expired - we can wait for the first host to be > defined trusted by the attestation server and select that host. > > Ofri > > Dave, adding another suggestion on top of Ofri's; Generally speaking, a cluster of hosts defines many joint features (such as CPU level), which means that in the same cluster we would expect to be able to freely migrate a VM from one host to another. Current trust-pools design is breaking this concept, as you introduce a state where a VM cannot migrate from a 'safe' host into an 'unsafe' host. This leads me to the suggestion of having attestation as a cluster policy rather than a VM-level property. It means that all hosts in this cluster are constantly being monitored to be safe. If a host is declared as unsafe in the Attestation server, it will become non-operational in the engine. This will simplify the implementation since you have everything ready for you once you have a 'safe' cluster and no need to do any VM-level changes. So in this way you keep current concepts while simplifying the implementation with very little worries of performance issues. Can you please share your thoughts on this suggestion? > - Original Message - > > From: "Wei D Chen" > > To: engine-devel@ovirt.org > > Sent: Friday, March 22, 2013 11:34:55 AM > > Subject: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your review > > > > Hi all, > > > > Before submitting this patch set, we has updated our design page, > > and new feature about VM template has added to this patchset. In > > patchset a lot of frontend changes has been imported. > > Welcome to review our patchset and thanks advance for your > > suggestion. > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > In this patch set, follow changes has been introduced: > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > physical host. > > 2. View/Edit VM changes to enable end user switch between three run > > on options. > > 3. Template relevant changes to support end user create a trusted VM > > template and create trusted VM based on this template afterwards. > > 4. Bug fixing and code cleanup. > > 5. wik
