Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt
- Original Message - From: Gilad Chaplik gchap...@redhat.com To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com Cc: Eli Mesika emes...@redhat.com, Roy Golan rgo...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Monday, March 31, 2014 4:31:17 PM Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt adding Roy Omer. why CPU topology is in dynamic? the guideline we (try to) follow today is (i know you can find exceptions to this, but this is how it suppose to be): vm/vds static - user configurable information (whatever you have in add/edit) vm dynamic - information related to a running instance, the is changed in a somewhat small frequency vds dynamic - host capabilities, information from the host that doesn't change while the host is up. statistics - all the rest, mostly statistics, and other fast changing information. Thanks, Gilad. - Original Message - From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com To: Eli Mesika emes...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com, Roy Golan rgo...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Monday, March 31, 2014 3:20:33 PM Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt Thanks Eli. I will move the vm level NUMA fields to vm_dynamic, and the related database schema will be updated accordingly. Thanks Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei@hp.com -Original Message- From: Eli Mesika [mailto:emes...@redhat.com] Sent: Monday, March 31, 2014 5:49 PM To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel@ovirt.org Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt - Original Message - From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com To: Gilad Chaplik gchap...@redhat.com, Eli Mesika emes...@redhat.com, Roy Golan rgo...@redhat.com Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Monday, March 31, 2014 12:38:04 PM Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change. NUMA information are similar to the host's cpu topology information like cpu_cores and cpu_sockets which are in vds_dynamic, we refer to this. VM level NUMA fields are configured by user, and actually we originally think they should be in vm_dynamic. But we found that the field of another feature cpuPin which is similar as NUMA feature is in vm_static, so we put vm NUMA fields in vm_static. Do you think we need to put VM level NUMA fields in vm_dynamic? I think that in this case we should fix cpuPin to be in vm_dynamic and put after that the other NUMA fields in vm_dynamic as well Thanks Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei@hp.com -Original Message- From: Gilad Chaplik [mailto:gchap...@redhat.com] Sent: Monday, March 31, 2014 5:22 PM To: Eli Mesika; Roy Golan Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel@ovirt.org Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt +1 IMO: vds data should reside in static VM need to think about it. Roy? Thanks, Gilad. - Original Message - From: Eli Mesika emes...@redhat.com
Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt
- Original Message - From: Gilad Chaplik gchap...@redhat.com To: Eli Mesika emes...@redhat.com Cc: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 3, 2014 4:04:55 AM Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt Hi all, Sorry for joining-in late. My comments (according to the db diagram section in https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY): 1) Join vm_numa_node and vds_numa_node to a single table (almost identical), one of the FKs can be null. 2) No templates reference in the design, need to check it out (it might be inherently designed already :-) ); vNode can be linked to a template. 3) The reason I want host's NUMA data to be in static is because it updates only once (on boot). engineerically speaking, dynamic table has a lot of traffic and that's not the case for NUMA info. Its feels to me like 'a hybrid' of static and dynamic, 3 suggestions comes to mind: - leave it in dynamic (maybe in a separate process). - have a separate flow that updates static. - come up with a third 'vds_on_boot' table (my favorite ;-P ). I will get back to you on that. i dont agree here, static is user options, there is no flow to automatically update it, and shouldn't be. this is the exact definition of dynamic for vds. there is not much updates to this table, getCaps when host moves to up and there are few fields that are updated from the statistics cycle, which is basically bad. 4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to split the tables (vds_numa_node vds_numa_node_statistics), going back to comment #1, don't we want vNode stats as well, it can be nice to show it :-) (have a vNUMA overview of the VM using guest-agent or sth, in a future phase). 5) IMO vds_cpu_statistics shouldn't include any reference to NUMA, I gave that comment in the BE patch as well (remove vds_numa_node_id FK in vds_cpu_statistics), for that you should extract cpu_list to a connection table (anyway I don't like lists as a text/strings/etc.) 6) vm_numatune_nodeset can be removed - the vNode should hold it's pinning info; I think that vNode (node according to comment #1) should be connected to a connection table that points to vdsNode (also Node table) itself (kinda complicated but does the trick - nested link). 7) Please add delete-cascade info all over, i.e. what happens when we remove a host/vm/node. 8) Is it possible to put a db constraint that mapping between vNode and Node will be deleted once the VM isn't UP? Thanks, Gilad. - Original Message - From: Eli Mesika emes...@redhat.com To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com Cc: Gilad Chaplik gchap...@redhat.com, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Tuesday, April 1, 2014 10:10:37 AM Subject: Re: Please help us to review our database schema design with NUMA feature on ovirt - Original Message - From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com To: Gilad Chaplik gchap...@redhat.com, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com, Eli Mesika emes...@redhat.com, Chegu Vinod chegu_vi...@hp.com Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org Sent: Tuesday, April 1, 2014 5:13:34 AM Subject: RE: Please help us to review our database schema design with NUMA feature on ovirt Assemble the related discussions in this mail session. Hi Vinod, On 3/31/2014 2:38 AM, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote: We put host level NUMA fields in vds_dynamic because these information are from host itself, and NUMA topology may be changed if the host's hardware make a change. Can you please elaborate ? Are you thinking about resource (cpu and/or memory) hot plug on the host ? [Bruce] It's not about resource hot plug. In ovirt engine, there is a scheduled task which will refresh hosts' and vms' information periodically. Only the dynamic and statistics data will be updated during the refresh. So I
Re: [Engine-devel] Share Your Thoughts
- Original Message -
From: Eli Mesika emes...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Sunday, March 23, 2014 2:41:15 PM
Subject: Re: [Engine-devel] Share Your Thoughts
- Original Message -
From: Eli Mesika emes...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Sunday, March 23, 2014 2:36:17 PM
Subject: Re: [Engine-devel] Share Your Thoughts
- Original Message -
From: Gilad Chaplik gchap...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Sunday, March 23, 2014 2:06:01 PM
Subject: [Engine-devel] Share Your Thoughts
Dear Devel Community Members,
We are having a small discussion on patch:
http://gerrit.ovirt.org/#/c/25633/,
bug 1065753 - Maintenance operations on a VM would ask for an optional
reason (adding a note to stop/shutdown VM, that will be cleared when the
VM
go up).
The proposed solution is to add a free text field in the VM entity, and
to
update it in command's parameters (StopVmParmas.. etc.).
I think slightly different, my alternative is to enhance the current free
text (comment field) into XML, and allow to add multiple comments that
include types.
You are welcome to read more about it in the patch's comments.
Thoughts?
I suggest a third approach
We are logging here a reason for a user/admin operation
The natural place for such information is the audit log and not the VM
tables.
I think that the audit log messages related for the stop/shutdown commands
should be enhanced to include a {REASON} field then the command itself will
replace this value in the message with the one given by the user and we are
done.
Again, the required information is a pure logging issue, therefor I suggest
to put this information in the correct place for it, there is no point in
saving any logging messages in any entity table.
Technically:
1) The option for giving a reason should be configurable (per Cluster if I
look at Arthur comment in the BZ)
2) If the option is on than any stop/shutdown will ask for reason and sent
it
in the command parameters
than=then
3) If the command succeed and got a non-empty reason , it will set the
reason
in the command audit log message
4) We gain here additional advantage since we can :
a) search for the reason using the search engine
b) get the reason in the message text sent to us if we are subscribed for
the VM stop/shotdown event ans using engine-notifier
Eli
+1
sounds like a good and simple idea
Thanks,
Gilad.
___
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] oVirt Engine 3.2 ReST API
- Original Message - From: Vikas Kokare vikaskok...@gmail.com To: Omer Frenkel ofren...@redhat.com Sent: Wednesday, March 12, 2014 5:24:11 AM Subject: Re: [Engine-devel] oVirt Engine 3.2 ReST API The problem is this situation is not obvious from the documentation. The data center field on the cluster is defined as required during creation and non-updatable. How can that be explained? So its a question not just for this example but for other entity associations too. i guess this is a bug in the documentation, this field is editable in this specific case only. can you open a bug? On Tue, Mar 11, 2014 at 5:56 PM, Omer Frenkel ofren...@redhat.com wrote: From: Vikas Kokare vikaskok...@gmail.com To: engine-devel@ovirt.org Sent: Tuesday, March 11, 2014 12:11:41 PM Subject: [Engine-devel] oVirt Engine 3.2 ReST API As per the API documentation, the host cluster element data_center id= is both required at creation(exclamation in a triangle) as well as non-updatable(lock sign). Is it right to consider that, not only is this a required element, but it can't be changed and deleting(disassociation) is out of question? We have a RHEVM environment, where one such host cluster was created initially being associated to a data center. Later someone changed something, that resulted in the specific host cluster having no data_center element on it. Could it be that the association was deleted, or that the data_center itself was deleted, but the system didn't honor referential integrity, that it was being referred by other objects? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel it is possible to remove a data-center, even if it has clusters, as long there is no usage in the storage (vms, templates..) this makes the clusters to have no data-center, and then the cluster can be joined to a different data center (new/existing) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] oVirt Engine 3.2 ReST API
- Original Message - From: Vikas Kokare vikaskok...@gmail.com To: engine-devel@ovirt.org Sent: Tuesday, March 11, 2014 12:11:41 PM Subject: [Engine-devel] oVirt Engine 3.2 ReST API As per the API documentation, the host cluster element data_center id= is both required at creation(exclamation in a triangle) as well as non-updatable(lock sign). Is it right to consider that, not only is this a required element, but it can't be changed and deleting(disassociation) is out of question? We have a RHEVM environment, where one such host cluster was created initially being associated to a data center. Later someone changed something, that resulted in the specific host cluster having no data_center element on it. Could it be that the association was deleted, or that the data_center itself was deleted, but the system didn't honor referential integrity, that it was being referred by other objects? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel it is possible to remove a data-center, even if it has clusters, as long there is no usage in the storage (vms, templates..) this makes the clusters to have no data-center, and then the cluster can be joined to a different data center (new/existing) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-3.4.0 is broken
Hi, looks like both commits: http://gerrit.ovirt.org/#/c/25436/ http://gerrit.ovirt.org/#/c/25313/ introduced an upgrade script with the same number to the 3.4.0 branch, and now build fails. can you please fix this? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] proposing Arik Hadas as a maintainer of engine core
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Itamar Heim ih...@redhat.com, Livnat Peer lp...@redhat.com, Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Maor Lipchuk mlipc...@redhat.com, Roy Golan rgo...@redhat.com, Eli Mesika emes...@redhat.com, Mike Kolesnik mkole...@redhat.com, Moti Asayag masa...@redhat.com, Shahar Havivi shav...@redhat.com, ov...@redhat.com, Allon Mureinik amure...@redhat.com Cc: engine-devel@ovirt.org, in...@ovirt.org Sent: Thursday, January 30, 2014 10:47:46 AM Subject: proposing Arik Hadas as a maintainer of engine core Dear engine-core maintainers, I'd like to propose Arik Hadas as a maintainer of oVirt engine backend Since he started with oVirt project in October 2012 he was working in various areas in engine core, demonstrated his abilities with more than 200 patches merged to engine master alone. Tons of migration related fixes, refactoring of legacy code, but also new complex features including complementary patches in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements for VMTemplate operations) Thanks in advance for your response. Thanks, michal +1 I've been working closely with Arik since he joined the project, discussing and reviewing most of his work, and i trust his opinion and think he will be a good addition to the team of maintainers. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposing Liron Aravot as an engine-core maintainer
- Original Message - From: Tal Nisan tni...@redhat.com To: Itamar Heim ih...@redhat.com, Livnat Peer lp...@redhat.com, Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Maor Lipchuk mlipc...@redhat.com, Roy Golan rgo...@redhat.com, Eli Mesika emes...@redhat.com, Mike Kolesnik mkole...@redhat.com, Moti Asayag masa...@redhat.com, Shahar Havivi shav...@redhat.com, ov...@redhat.com, Allon Mureinik amure...@redhat.com Cc: engine-devel engine-devel@ovirt.org, in...@ovirt.org Sent: Sunday, January 26, 2014 2:47:30 PM Subject: Proposing Liron Aravot as an engine-core maintainer Hi core maintainers, I would like to propose Liron Aravot as an engine-core maintainer. Liron joined the oVirt project on June 2012, and has since contributed over 170 patches to master (not counting backports to various stable branches). He has been instrumental in implementing oVirt's Backup API for external providers, and has a been a driving force in improving flows regarding SPM election and master domain reconstruction, handling OVF backups and various concurrency issues both as a coder and a reviewer. Your response would be appreciated. +1 Thanks, Tal. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] missing javadoc for restapi?
- Original Message - From: Sven Kieske s.kie...@mittwald.de To: engine-devel@ovirt.org Sent: Friday, December 20, 2013 12:56:32 PM Subject: Re: [Engine-devel] missing javadoc for restapi? I'm asking because the rsdl is not correct about cloud-init, specific: http://www.ovirt.org/Features/Cloud-Init_Integration e.g. it is not mentioned that there is an collection ips, not in the wiki and not in the rsdl. ATM our developers are cursing at me/ovirt. I'd like to stop this asap. what version are you working on? please note that network under cloud_init was changed to network_configuration recently. i've updated the wiki as well. if this doesn't help, please attach the xml you are using and i could try and look for the error. Am 20.12.2013 11:47, schrieb Sven Kieske: Hi, we are not able to find the javadoc for the restapi. I can find the javadoc for the java sdk but not for REST. Are we looking in the wrong place? Any links or help would be appreciated! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ 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] UX: Display VM Downtime in the UI
- Original Message - From: Adam Litke ali...@redhat.com To: Malini Rao m...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 11:19:17 PM Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI On 18/12/13 16:04 -0500, Malini Rao wrote: - Original Message - From: Adam Litke ali...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 9:42:59 AM Subject: [Engine-devel] UX: Display VM Downtime in the UI Hi UX developers, My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for tracking the time a VM was last stopped and presenting it in the REST API. I would also like to expose this information in the admin portal. This feature has been requested by end users and is useful for managing lots of VMs which may not be used frequently. My idea is to change the 'Uptime' column in the VMs tab to 'Uptime / Downtime' or some equivalent and more compact phrasing. If the VM is Up, then last_start_time would be used to calculate uptime. If the VM is Down, then last_stop_time would be used to calculate downtime. This helps to make efficient use of the column space. Thanks for your comments! MR: I like the idea in general but can we extend to other states as well? Then we could have the col be called something like 'Time in I would argue that 'Up' and 'Down' are the only persistent states where a VM can linger for a user-controlled amount of time. The others (WaitForLaunch, PoweringDown, etc) are just transitions with their own system defined timeouts. Because of this, it really only makes sense to denote uptime and downtime. When the VM is in another state, this column would be empty. when do you think this would be empty? the way i see it, if there is a qemu process running, we count 'up time' (as it is today) otherwise, its down time (when vm is suspended/image locked its down as well) maybe only in 'unknown' state, when we dont have connection to the host, and we dont know the state of the vm it can be empty. current state'. Also, I think since this col is so far from the first column that has the status icon, we should have a tooltip on the value that says ' Uptime' , 'down time' or 'Status time'. Agree on the tooltip. I am not sure how column sorting is being implemented, but if we combine uptime and downtime into a single column we have an opportunity to provide a really intuitive sort where the longest uptime machines are at the top and the longest downtime machines are at the bottom. This could be accomplished by treating uptime as a positive interval and downtime as a negative interval. MR: That's an interesting idea. Not sure how that would translate if we did all states and times. Then I would think you would do descending order within each state but then we would have to fix a sequence for the display of the various statuses based on the statuses that matter most. This is much simpler if you just work with Up and Down. Questions for you all: - Do you support the idea of changing the Uptime column to include Downtime as well or would you prefer a new column instead? MR: I do not like the idea of introducing new columns for this purpose since at any given time, only one of the columns will be populated. Another idea is to remove this column all together and include the time for the current status as a tooltip on the status icon preceding the name. What about adding the uptime/downtime to the status column itself? I don't necessarily think this will muddy the status much since there is still an icon on the left. i like better the first option of one column with up/down time, i think its more clear to the user ___ 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] Proposal to add Juan Hernandez as maintainer to api/sdk/cli
- Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Monday, December 16, 2013 5:34:36 PM Subject: Proposal to add Juan Hernandez as maintainer to api/sdk/cli Juan has worked on oVirt for a long period of time, developing several features in the different areas (including api and cli), and obviously gained a lot of experience and knowledge, I'd like to propose Juan as a maintainer of the api/sdk/cli projects. +1 -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [QE] oVirt 3.3.2 RC status
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: engine-devel engine-devel@ovirt.org, us...@ovirt.org, VDSM Project Development vdsm-de...@lists.fedorahosted.org, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com Cc: Itamar Heim ih...@redhat.com Sent: Wednesday, December 11, 2013 10:29:41 AM Subject: Re: [QE] oVirt 3.3.2 RC status Hi, we should decide today at oVirt sync meeting about oVirt 3.3.2 RC build scheduled for today [1] A bug tracker is available at [2] and it shows only 2 bugs still blocking the release: WhiteboardBug ID Summary virt 1029885 cloud-init testcase does not work in engine 3.3.1 virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once Omer: 3.3.2 backported and wait for review from REST - Is 1029885 solved by fix introduced for bug 1039009 ? I can't see any pending patches about this pushed to 3.3.2 branch. you are right, i mixed up those 2 bugs, 'Bug 1039009 - can't use cloud-init /run once via api' - fixed, '1029885 - cloud-init testcase does not work in engine 3.3.1' - no fix except upgrading guest right now Roy: - ETA for 1025829? oVirt 3.3.2 beta testing is in progress, thanks to all who already started testing it! For those willing to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [3]. Maintainers should fill release notes before RC build if not already done, the page has been created here [4] [1] http://www.ovirt.org/OVirt_3.3.z_release-management [2] https://bugzilla.redhat.com/1027349 [3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing [4] http://www.ovirt.org/OVirt_3.3.2_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [QE] oVirt 3.3.2 RC status
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: engine-devel engine-devel@ovirt.org, us...@ovirt.org, VDSM Project Development vdsm-de...@lists.fedorahosted.org, Eduardo Warszawski ewars...@redhat.com, Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com, vdsm-devel vdsm-de...@fedorahosted.org Cc: Itamar Heim ih...@redhat.com Sent: Monday, December 9, 2013 11:30:58 AM Subject: Re: [Engine-devel] [QE] oVirt 3.3.2 RC status Hi, we've scheduled oVirt 3.3.2 RC build on 2013-12-11 [1] A bug tracker is available at [2] and it shows only 3 bugs still blocking the release: WhiteboardBug ID Summary storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI virt 1029885 cloud-init testcase does not work in engine 3.3.1 3.3.2 backported and wait for review from REST virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once Please provide an ETA for the above bugs. oVirt 3.3.2 beta testing is in progress, thanks to all who already started testing it! For those willing to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [3]. Maintainers should fill release notes before RC build, the page has been created here [4] [1] http://www.ovirt.org/OVirt_3.3.z_release-management [2] https://bugzilla.redhat.com/1027349 [3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing [4] http://www.ovirt.org/OVirt_3.3.2_release_notes Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration REST-API
- Original Message - From: Itamar Heim ih...@redhat.com To: Sven Kieske s.kie...@mittwald.de, engine-devel@ovirt.org, Omer Frenkel ofren...@redhat.com, Michal Skrivanek mskri...@redhat.com Sent: Saturday, December 7, 2013 10:09:05 AM Subject: Re: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration REST-API On 12/06/2013 03:43 PM, Sven Kieske wrote: Hi, cool that there are patches, but is there any chance to get this into 3.3.1 or at least 3.3.2? we need this feature asap. This is really urgent. 3.3.1 was released, i don't see it being re-spin for anything but a critical regression. 3.3.2 is in beta, so still planned to re-spin. omer/michal - thoughts about backporting this to 3.3.2? sent http://gerrit.ovirt.org/#/c/22139/ Am 06.12.2013 13:31, schrieb Itamar Heim: On 12/06/2013 12:42 PM, Sven Kieske wrote: Hi, I think this may be the more appropriate list to discuss this issue? I fear this isn't integrated yet and can't be integrated in 3.3.1 or 3.3.2? its already fixed for stable 3.3, but just after 3.3.2 was created... http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=45cfd1951d87293d3aad661372cdd4391b7116f8 http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4eb464cec2b4f529a6b6a76bbcb5bd76a5302188 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Using config values
- Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Kanagaraj kmayi...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Sunday, December 1, 2013 8:08:42 AM
Subject: Re: [Engine-devel] Using config values
- Original Message -
Hi All,
Hi Kanagaraj,
The are some issues arising in configurations whenever we move up on the
versions(3.3 = 3.4), because of the way we store and interpret them.
Whenever there is a new cluster level, you will need to add a new entry for
all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
3.3, except some CPU/PM type related configurations.
Better option would be to have the defaul config value in ConfigValues.java
and the overrides will go to config.sql. In this approach you don't need a
new entries to config.sql when there is a new cluster level.
Lets take an exmaple, SupportForceCreateVG - This is supported from 3.1
onwards,
If you look at config.sql, you will see following entries
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
And in ConfigValues.java
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(false)
SupportForceCreateVG,
Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
feel is redundant.
Instead we can make
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(true)
SupportForceCreateVG,
and have only the following in config.sql
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in
ConfigValues.java.
This has already been implemented, there are many feature supported
configurations working like this (for example GlusterSupport).
I think a more interesting approach would be to move these out of the DB
since these values don't really hav e a reson to be there.
Since the entire thing is abstracted by Gluster/FeatureSupported classes
then we can easily change mechanism (of course whatever code is not using it
can be easily converted to use the mechanism)
For example a simple enum could do the trick:
- EXAMPLE
-
/**
* Convenience class to check if a gluster feature is supported or not in any
given version.br
* Methods should be named by feature and accept version to check against.
*/
public class GlusterFeatureSupported {
/**
* @param version
* Compatibility version to check for.
* @return codetrue/code if gluster support is enabled, codefalse/code
if it's not.
*/
public static boolean gluster(Version version) {
return SupportedFeatures.GLUSTER.isSupportedOn(version);
}
/**
* @param version
* Compatibility version to check for.
* @return codetrue/code if gluster heavyweight refresh is enabled,
codefalse/code if it's not.
*/
public static boolean refreshHeavyWeight(Version version) {
return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
}
/* More methods... */
enum SupportedFeatures {
GLUSTER(Version.v3_0),
REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
/* More members */;
private SetVersion unsupportedVersions = new HashSetVersion();
private SupportedFeatures(Version... versions) {
unsupportedVersions.addAll(Arrays.asList(versions));
}
public boolean isSupportedOn(Version version) {
return !unsupportedVersions.contains(version);
}
}
- END EXAMPLE
-
Thoughts?
unless i didn't understand something, this is not good,
this should stay configurable by the users,
for example if some user experience some issues with a feature and want to turn
it off/change the values..
(not all version configuration are boolean, some are different values to
different versions, like cpu-list)
Regards,
Mike
Please share your thoughts on this.
Thanks,
Kanagaraj
___
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] Using config values
- Original Message -
From: Eli Mesika emes...@redhat.com
To: Dusmant Kumar Pati dp...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Saturday, November 30, 2013 10:58:35 PM
Subject: Re: [Engine-devel] Using config values
- Original Message -
From: Dusmant Kumar Pati dp...@redhat.com
To: Kanagaraj kmayi...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Friday, November 29, 2013 1:40:09 PM
Subject: Re: [Engine-devel] Using config values
On 11/29/2013 01:46 PM, Kanagaraj wrote:
Hi All,
The are some issues arising in configurations whenever we move up on the
versions(3.3 = 3.4), because of the way we store and interpret them.
Whenever there is a new cluster level, you will need to add a new entry for
all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
3.3, except some CPU/PM type related configurations.
Better option would be to have the defaul config value in ConfigValues.java
and the overrides will go to config.sql. In this approach you don't need a
new entries to config.sql when there is a new cluster level.
Lets take an exmaple, SupportForceCreateVG - This is supported from 3.1
onwards,
If you look at config.sql, you will see following entries
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
And in ConfigValues.java
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(false)
SupportForceCreateVG,
Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
feel is redundant.
Instead we can make
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(true)
SupportForceCreateVG,
and have only the following in config.sql
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in
ConfigValues.java.
Please share your thoughts on this.
Hi
First of all I think its a good idea
I have 2 questions
1) Which value will be stored as default in the java class for configuration
values that are not a boolean, that represents if a feature is active or
not.
Is that the latest version value ? sounds not obvious to me
i guess this will have to have a configuration values for each version in the
db.
2) There are some configuration values that are exposed to the user via the
engine-config tool, how this will work, we can not remove the entries their
since the user may change and override those values.
in your suggestion below, there is the same issue,
if user want to change the 3.3 value, engine config will fail with No such
entry
because 3.3 will not be in the db..
so if we are not fixing this, i think using the current implementation is good
enough,
no need to add logic, just to convert current options that are not in this
format, to use this logic.
I have a different suggestion:
Default value will stay as is , meaning , it will reflect the value that
should be used to keep the application running correctly if a value is not
found in DB (which should not occur)
Code of getting configuration value (getConfigValue(key,version) will be
changed to get the closest version value to the given one.
For example , if a 3.4 version is given for a given key and we have in DB
just values for 3.0 and 3.1 , the 3.1 value is returned.
I prefer this solution since it makes the config.sql file self documented ,
showing only value changes and in which version each change occurred.
To implement that, we should add this mechanism to the current code that
caches the DB content and as I see that it should be a simple change.
engine-config should be modified such that if the user change a value, this
value will be inserted to the database with the current release if not
exists and then the mechanism described above will get this value
Example:
VdsFenceType lists all the supported fencing agents for power management , it
currently has the following settings
option_value
|
version
-+-
alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
| 3.0
alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
| 3.1
apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
| 3.2
apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
| 3.3
In the proposed solution, we will have
Re: [Engine-devel] Using config values
- Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Omer Frenkel ofren...@redhat.com
Cc: Kanagaraj kmayi...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Sunday, December 1, 2013 11:01:50 AM
Subject: Re: [Engine-devel] Using config values
- Original Message -
- Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Kanagaraj kmayi...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Sunday, December 1, 2013 8:08:42 AM
Subject: Re: [Engine-devel] Using config values
- Original Message -
Hi All,
Hi Kanagaraj,
The are some issues arising in configurations whenever we move up on
the
versions(3.3 = 3.4), because of the way we store and interpret them.
Whenever there is a new cluster level, you will need to add a new entry
for
all(most) of the configuration. Mostly a copy paste if you see from 3.2
to
3.3, except some CPU/PM type related configurations.
Better option would be to have the defaul config value in
ConfigValues.java
and the overrides will go to config.sql. In this approach you don't
need
a
new entries to config.sql when there is a new cluster level.
Lets take an exmaple, SupportForceCreateVG - This is supported from
3.1
onwards,
If you look at config.sql, you will see following entries
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
And in ConfigValues.java
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(false)
SupportForceCreateVG,
Now if there is 3.4 and 3.5, the user needs to add 2 more entries,
which
i
feel is redundant.
Instead we can make
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute(true)
SupportForceCreateVG,
and have only the following in config.sql
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in
ConfigValues.java.
This has already been implemented, there are many feature supported
configurations working like this (for example GlusterSupport).
I think a more interesting approach would be to move these out of the DB
since these values don't really hav e a reson to be there.
Since the entire thing is abstracted by Gluster/FeatureSupported
classes
then we can easily change mechanism (of course whatever code is not using
it
can be easily converted to use the mechanism)
For example a simple enum could do the trick:
- EXAMPLE
-
/**
* Convenience class to check if a gluster feature is supported or not in
any
given version.br
* Methods should be named by feature and accept version to check against.
*/
public class GlusterFeatureSupported {
/**
* @param version
* Compatibility version to check for.
* @return codetrue/code if gluster support is enabled,
codefalse/code
if it's not.
*/
public static boolean gluster(Version version) {
return SupportedFeatures.GLUSTER.isSupportedOn(version);
}
/**
* @param version
* Compatibility version to check for.
* @return codetrue/code if gluster heavyweight refresh is enabled,
codefalse/code if it's not.
*/
public static boolean refreshHeavyWeight(Version version) {
return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
}
/* More methods... */
enum SupportedFeatures {
GLUSTER(Version.v3_0),
REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
/* More members */;
private SetVersion unsupportedVersions = new HashSetVersion();
private SupportedFeatures(Version... versions) {
unsupportedVersions.addAll(Arrays.asList(versions));
}
public boolean isSupportedOn(Version version) {
return !unsupportedVersions.contains(version);
}
}
- END EXAMPLE
-
Thoughts?
unless i didn't understand something, this is not good,
this should stay configurable by the users,
for example if some user experience some issues with a feature and want to
turn it off/change
Re: [Engine-devel] Error message while trying to delete default cluster
- Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: engine-devel engine-devel@ovirt.org, michal skrivanek michal.skriva...@redhat.com, Omer Frenkel ofren...@redhat.com, Allon Mureinik amure...@redhat.com Cc: Dusmant Pati dp...@redhat.com Sent: Monday, November 11, 2013 8:20:41 AM Subject: Error message while trying to delete default cluster Hi, While trying to delete the Default cluster in oVirt it shows the below error message - Cannot remove default Host Cluster. Cannot remove Cluster. One or more Template(s) are still associated with it But in the case of RHSC, Templates are not used and this message is not relevant. [1]. Can we opt for not installing the templates while engine setup? And would it be having any impact/consequences ? Kindly provide your thoughts and possibility of the same. Thanks and Regards, Shubhendu PS: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838 removing the blank template means the system couldn't be used to create vms at all. but blank template is not the only problem, there is an explicit check that prevent deleting the default cluster (RemoveVdsGroupCommand class, line #35), i couldn't find the commit that added this, but i /think/ its because by default host registration is done to the default cluster, so it had to exist. so this should be solved first. then, if we decide to have a 'non-virt' installation we probably could avoid default cluster and blank template. but what if user changes his mind after installation? another option is to remove the protection from DB level and make cluster-id nullable in the vm_static table, and have logic to allow removing last cluster and update template on new cluster addition. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time
- Original Message - From: Frantisek Kobzik fkob...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, November 6, 2013 11:33:28 AM Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time Dear devels, I started working on a feature that allows user to run a VM with both SPICE and VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These are two different things and should be treated separately. What I suggest is to split that configuration in vm_static into two fields: 1, (already existing) Display type with values QXL or CIRRUS 2, (new) Graphics types - enum or comma-separated string that indicates that the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that the type will be derived from the video device which is current behavior. when choosing both, does this mean vm will have 2 video devices (cards)? The feature would consist of three patches: - vdsm - add new field in vm.conf with information about graphics types of a vm. - engine backend - add graphics types to VM and corresponding entities, adjust xml rpc communication. - engine frontend - only adjust the ui. The patches would be backwards compatible with older engine/vdsm versions. There are some things that must be taken into account, mostly it's about differences in SPICE/VNC supported features (like multimonitors, single qxl, smartcard, migration...). e.g. if you run a vm with both graphic types together the engine should probably disallow some spice features. But this is more of an implementation detail. Feel free to reply if you have anything to say about this feature. Cheers, Franta. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044 ___ 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] simulating 100 hypervisors
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, October 28, 2013 4:16:13 PM Subject: [Engine-devel] simulating 100 hypervisors Hi, I need to do some testing on log-collector for solving Bug 1014379 - When calling the API the LC does not provide a max value, limiting the returned results to 100 by default. How may I have the engine listing more than 100 hypervisors? (I don't really need them to be up, just need them to be listed) check this out: http://www.ovirt.org/VDSM_Fake -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ 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] DataIntegrityViolationException when creating a new template
- Original Message -
From: Einav Cohen eco...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Friday, August 23, 2013 10:54:07 PM
Subject: [Engine-devel] DataIntegrityViolationException when creating a new
template
latest upstream, using development environment.
attempting to 'Make Template' results in an internal engine error (see
attached screen-shot).
in engine.log, I see the following error:
org.springframework.dao.DataIntegrityViolationException:
CallableStatementCallback; SQL [{call insertvmdevice(?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?)}]; ERROR: null value in column device_id violates not-null
constraint
[see attached engine.log, look for the 2013-08-23 15:40:04 time-stamp to see
the initial invocation of AddVmTemplateCommand, error above appears in
2013-08-23 15:40:27]
ideas?
did you remember to run setup in order to update your db?
i just tried creating few templates and all worked ok
Thanks in advance.
Regards,
Einav Cohen Baum
RHEV-M Engineering - UX Team Manager
Red Hat, Inc.
314 Littleton Road
Westford, MA 01886
T [internal]: (81) 31046
T [external]: (+1) 978 589 1046
IRC: ecohen @
- RHAT [internal]: #rhev-dev #boston #westford #tlv
- OFTC [external]: #ovirt
___
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] does now engine support join vm to AD
- Original Message - From: bigclouds bigclo...@163.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, August 8, 2013 1:12:29 PM Subject: Re:Re: [Engine-devel] does now engine support join vm to AD thanks, is it the best way? if is it possiable to add windows vm to domain automaticly without a reboot? look at my thought. if can make it true. 1.before start vm, inject domain infomations into guest-image(libguestfs), the another side ,it is DC(domain controller), we create matching info(i do not know exactly what is that info, ad exchange with a host), when start vm, it joins domain automaticly, user can login using domain account. why it is realizable, because even you use sysprep, a reboot is needed, so they can connect seamless if they are prepared corrently? i have try, but failed, i did not know how to prepare DC info. thanks i don't know much about using libguestfs to manipulate a running vm, and if it works. afair, when adding windows machine to a domain (from within windows), windows requires reboot so... i might be wrong here. so for your question, not sure its the best way, but this is what i know. At 2013-08-08 13:57:57,Omer Frenkel ofren...@redhat.com wrote: - Original Message - From: bigclouds bigclo...@163.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, August 8, 2013 3:36:35 AM Subject: [Engine-devel] does now engine support join vm to AD hi,all does now engine support join vm to AD? on UI there is a configuration option for windows domain, how to use it? when creating template with windows os, y! ou need to 'seal' it somehow for sysprep, then you need to set the domain when creating vm from the template (also you can set the windows domain on the template to be set by default to vms created for it) and when you run the vm for the first time, the windows sysprep takes place and the domain should be set there. make sure to select the right os on the template/vm since the sysprep is different between windows versions. for linux im not sure, it might be possible with cloud init, with user-scripts, once we have this option (currently not implemented) thanks. ___! 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] does now engine support join vm to AD
- Original Message - From: bigclouds bigclo...@163.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, August 8, 2013 3:36:35 AM Subject: [Engine-devel] does now engine support join vm to AD hi,all does now engine support join vm to AD? on UI there is a configuration option for windows domain, how to use it? when creating template with windows os, you need to 'seal' it somehow for sysprep, then you need to set the domain when creating vm from the template (also you can set the windows domain on the template to be set by default to vms created for it) and when you run the vm for the first time, the windows sysprep takes place and the domain should be set there. make sure to select the right os on the template/vm since the sysprep is different between windows versions. for linux im not sure, it might be possible with cloud init, with user-scripts, once we have this option (currently not implemented) thanks. ___ 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] oVirt 3.3 feature freeze and delivery to testing repo
- Original Message - From: Itamar Heim ih...@redhat.com To: Moran Goldboim mgold...@redhat.com, Doron Fediuck dfedi...@redhat.com, Greg Padgett gpadg...@redhat.com, Omer Frenkel ofren...@redhat.com, Michal Skrivanek mskri...@redhat.com, Mike Kolesnik mkole...@redhat.com, Livnat Peer lp...@redhat.com, Ayal Baron aba...@redhat.com, Federico Simoncelli fsimo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, July 16, 2013 4:03:46 PM Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo On 07/15/2013 05:45 PM, Moran Goldboim wrote: Maintainers and all, due to some misunderstanding regarding feature freeze for ovirt 3.3 release (suppose to be today, but marked as Jul 17th on release page), we are extending feature freeze till wendesday. feature owners: -please update 3.3 release page [1] with the feature status -please update testing page for your feature package owners- once your component is ready (should be done till wendesday) -tag your repo for 3.3 beta release -provide srpm to mike -provide fc19/el6 rpms builds using mock to mike mike if you would like to set a place people can upload it too please let us know. [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table what's the status of these which seem a shame to release without (and all are supposed to be on their final step)? - glance integration (federico) - Neutron (quantum) integration (livnat/mike)? - cloud-init (greg/omer)? pending ack from REST - plugable scheduling (doron)? Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Guest Reboot
- Original Message - From: Martin Betak mbe...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, June 10, 2013 1:29:29 PM Subject: Re: [Engine-devel] Guest Reboot - Original Message - From: Omer Frenkel ofren...@redhat.com To: Martin Betak mbe...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, June 9, 2013 8:51:54 AM Subject: Re: [Engine-devel] Guest Reboot As i understand it, reboot will do shutdown and initiate a run-command in order to send any updated parameters, if this is correct, why vdsm and GA need to know its a reboot? guest is shutting down, no? Well in some cases where the VM configuration hasn't changed we can do graceful reboot using libvirt acpi reboot capabilities via guest agent (by just passing different option to the existing shutdown script). This preserves the qemu process and can be more efficient than the destroy(); start() sequence. Of course if it were the case that the guest would not respond to graceful method of reboot and the power-down policy for this VM hard, the engine would fall back to the destroy(); start() sequence. Otherwise (graceful-only reboot policy) we would leave the guest alone - status UP. ok maybe worth adding this info to the wiki, although currently there is no way to know if configuration has changed or not, but should be something like this soon (RFE for changing running vm configuration) it would be better to add some info on stateless issue: when stateless vm goes down, its state is cleared, so need to decide if reboot to stateless means also start with new state or no. I think this issue is similar to the Run-Once question. Do we want to give the user another option to choose from or do we pick one for him? similar is vm from pool: when vm from automatic pool goes down, it returns to the pool, and not belong to a specific user anymore, also here the state is cleared, so again need to understand the correct behaviour In the case of vm from pool the state treatment should be the same as in stateless but we also need to run the stop(); start() sequence in a transaction to make sure nobody else can steal this machine from this user. Or possibly since pool-VM configuration cannot change we could perhaps do the reboot only using the new vdsm capabilities. Do you think this would be possible or the engine would notice that the VM went Down for a brief moment? engine have to identify the vm as down before starting it again.. Maybe a new VM state Rebooting instead of Down would help in this case? not sure this is the best approach, need to do some thinking about this ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] cluster emulation mode feature
- Original Message - From: Roy Golan rgo...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, June 9, 2013 8:56:45 AM Subject: Re: [Engine-devel] cluster emulation mode feature On 06/08/2013 10:33 PM, Itamar Heim wrote: On 06/06/2013 08:17 AM, Roy Golan wrote: Hi, A new wiki has been published on Cluster Emulation mode http://www.ovirt.org/Cluster_emulation_modes Please review. Thanks, Roy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel strange, I thought the EmulatedMachine config value we currently have was also used to validate host support, but seems we were missing that part. I was also puzzled while doing git grep -i emulatedmachine what will happen with the current EmulatedMachine config value? The OVF builder will use the cluster config and EmulatedMachine will be deleted what happens when cluster emulation mode changes to hosts not matching it? Updating cluster's emulation mode is prohibited when active hosts has running VMs. if VMs are not running on them they will transit to non-op on the next refresh the emulated machines are reported on getCaps, not getStats, so not sure what refresh you refer to, anyway i think we should allow if no vms running but all active hosts support new value and block otherwise (if vms are running or one of the active hosts doesn't support new value) iirc this is the logic for changing cpu type ___ 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] Guest Reboot
- Original Message - From: Martin Betak mbe...@redhat.com To: engine-devel@ovirt.org Sent: Friday, June 7, 2013 7:32:31 PM Subject: [Engine-devel] Guest Reboot Hi, engine-devel Customers request the ability to reboot a VM with a single click so I started designing the overall architecture and planing out the required changes to the respective components. You can find the wiki page for the initial draft at [1] and I would like to ask you for your input on my general design and potential issues that could arise in some corner cases. Please feel free to respond to this thread or add to the Issues section of [1]. Thanks in advance for your opinions :-) Martin [1] http://www.ovirt.org/Features/Guest_Reboot ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel As i understand it, reboot will do shutdown and initiate a run-command in order to send any updated parameters, if this is correct, why vdsm and GA need to know its a reboot? guest is shutting down, no? it would be better to add some info on stateless issue: when stateless vm goes down, its state is cleared, so need to decide if reboot to stateless means also start with new state or no. similar is vm from pool: when vm from automatic pool goes down, it returns to the pool, and not belong to a specific user anymore, also here the state is cleared, so again need to understand the correct behaviour ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk BE very small refactoring
- Original Message - From: Vered Volansky ve...@redhat.com To: Maor Lipchuk mlipc...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Omer Frenkel ofren...@redhat.com, Mike Kolesnik mkole...@redhat.com, Allon Mureinik amure...@redhat.com, Daniel Erez de...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 8:40:38 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I had a problem, didn't see all the replies till now. I'll add some more info as to why we want to do this like we do. It all started from adding the readOnly property to disks. It should have been handled like plugged is handled, yet plugged is a hack, and if we don't change that now, we'll only keep on adding unreasonable hacks. please explain why you think plugged is a hack? what is wrong with it? So from the start - Disk currently: - Sometimes represents a disk in a vm context and sometimes not. - Holds plugged property, which is only relevant when a disk is in a vm context, which already suggests this is not the natural place for it. - Also holds bootable and interface, which cause limitations of use, but are not so obviously related to the relationship between Disk and Vm as plugged. - Can be shared between several vm's, to some plugged and to some not plugged. - Will soon be optionally RO in one VM and RW in another, which is exactly the same as plugged, and therefore plugged issue should be fixed first. Every column in that shows a disk in the UI receives a Disk entity, and show its contents, while plugged/unplugged is ignored when not in a VM context. The way things are now, using a VmDevice in the where we need it to show plug status, we'll also have to use it in all other columns, which is irrelevant and just totally not related. So using VmDevice in UI is a no go. The UI is the main limitation forcing us to use something that extends Disk, and what I described below is the easiest thing to implement in the time restrictions we have without changing the entire system. I think this answers all the questions not already answered by others. Regarding Maor suggestion - might be a good idea, but not in this scope or time-frame. If there is any other/unanswered issue or objection to the design change please share. I appreciate your inputs, Vered sorry i didnt understand why the current disk object isnt good enough, you get a disk, some of its properties are valid only in some situations. i think its easier to use instead of couple of different objects representing the same entity in different situations. - Original Message - From: Maor Lipchuk mlipc...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 1:49:46 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I think the main problem is that we abuse the business entity to act as an O/R mapping class to the DB and also to be used as a business entity for presentation purposes. I understand how Yair thought isPlugged could be fetched from vmDevice, this is a confusing design, and it is just one example and more to come. I suggest that if we already thinking of changing the class hierarchy, we can start by implementing a package for presentation classes for transient classes such as this instead enforcing complex hierarchy. The query class will fetch all the data from the DB and initialized the transient class and send it to the client. I think it could be a good start and will solve many issues we might encounter in the future. Regards, Maor On 05/28/2013 11:24 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, May 27, 2013 6:22:58 PM Subject: Re: [Engine-devel] Disk BE very small refactoring Vered, VmDevice has isPlugged field, Why not have somehow in your inheritence (either Disk or a subclass) a field : VmDevice device disk id is the device id, no need for field to represent the relation. the combination of disk-id and a specific entity (vm/template) will get you the other info and have isPlugged method called device.isPlugged() ? Then you can also add the readOnly property which is not represented at VmDevice. Does this sound logical to you? - Original Message - From: Vered Volansky ve...@redhat.com To: engine-devel@ovirt.org Sent: Monday, May 27, 2013 6:18:58 PM Subject: [Engine-devel] Disk BE very small refactoring Hi All, Please express your opinion if you have any - Currently Disk BE has a plugged property, which should be a property of the relationship between vm(or template) and a disk. I plan to remove this property from the Disk entity, and add new entity, called DeviceDisk. This should
Re: [Engine-devel] about ticket
- Original Message - From: wlbleaboy@126 wlblea...@126.com To: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 2:54:24 PM Subject: [Engine-devel] about ticket Hi all: When I connect to a vm via spicec or spicy, I need a ticket, so I get a ticket from ovirt-engine via ovirt-engine-sdk, and it works well. But I don’t know how long can a ticket to use? For example, when I got a ticket, it’s validated In many minutes, or several hours, or always. Or in some other condition, a ticket will invalidate. If a ticket have a time limits, where and how could I change it, let it always can validated. I guess the ticket come from ovirt-node, when I via ovirt-engine-sdk get a ticket, sdk will get ovirt-engine a POST action, and then engine-core give VDSM a command, VDSM get it from ovirt-node and return it to ovirt-engine. ovirt-engine-sdk use GET action to get it. you can use expiry with the sdk, default is 120sec ___ 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] How to get the number of all running VMs
- Original Message - From: Edgar shw...@163.com To: engine-devel@ovirt.org Sent: Monday, May 27, 2013 4:35:42 PM Subject: [Engine-devel] How to get the number of all running VMs Hi All, I need to get the number of All running VMs of the oVirt-engine. My thought is first get all hosts with up status and then traverse each host and count the VM with state Running . Does this method feasible,and is there any easier way to count the running VMs of oVirt-engine? Best Regards you can use the webadmin, but not sure there is an easy way to see total count if there are more than one pages of results, just enter in the search: Vms: status != down and status != imagelocked and status != suspended you can use get the same with rest api: http://localhost:8700/api/vms?search=%22status%20!=%20down%20and%20status%20!=%20imagelocked%20and%20status%20!=%20suspended%22 and parse the result or by using the db: select count(*) from vm_dynamic where status not in (0,15,13); ___ 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
- Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Cc: Omer Frenkel ofren...@redhat.com Sent: Thursday, May 2, 2013 1:03:23 PM Subject: Re: [Engine-devel] FeatureSupported and compatibility versions On 03/18/2013 01:30 PM, Omer Frenkel wrote: - Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Sent: Monday, March 18, 2013 8:28:14 AM Subject: [Engine-devel] FeatureSupported and compatibility versions 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: 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 like this approach better, if one add new feature for 3.3 he should add it as 'true' in the config to be used as default, and explicitly add it as false for other unsupported versions. For the record, this was the approach that was finally approved on the patch and merged (http://gerrit.ovirt.org/12970) So I think now onwards, everyone can start using this approach for new features being added. if we do go this way, we need to make sure it works because i vaguely remember we had a bug in configuration, making us explicitly specify value for all versions. I wrote a test case on DBConfigUtils that verifies that it does indeed work fine (http://gerrit.ovirt.org/13787), which has also been approved and merged. Thanks! Thoughts? Regards, Shireesh ___ 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] ovirt user portal and attach a cd
- Original Message - From: Andrej Bagon andrej.ba...@arnes.si To: engine-devel@ovirt.org Sent: Monday, April 29, 2013 11:28:39 AM Subject: [Engine-devel] ovirt user portal and attach a cd Hi all, we would like to limit a user as much as possible and give him only actions that he needs with his VM. If we disallow a user the right in system|configure system|manipulate permissions), we give the user, in user portal, only basic mode. But then three is no option to attach a cd in the basic user portal. In basic mode user interface there is no chance in attaching a cd (as this is a basic operation a solution to this would be a button attaching a cd when starting a vm). If we allow the user to manipulate permissions, we get the extended menu back and the user is limited, but we found unacceptable when he is adding permission to the VM, he sees all the users (name, surname, email!) in the ovirt authentication mechanism? A solution to this would be authenticating to the directory service as a user an not as ovirt admin user - meaning that the user will see only users that we allowed he sees in the ldap directory. Thank you. Best Regards, Andrej ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel well if you only need to change cd for vm, permission wise, the userRole and basic user portal are enough, iirc, if using spice (on windows?) that used to be possible, this may be related: https://bugzilla.redhat.com/show_bug.cgi?id=957611 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
- Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: Hi Dave, The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host. Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state. You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation. You can add a UI to allow manual refresh attestation. so the new thread will poll all for all hosts and update the db, then during the normal monitoring detect the issue? Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Monday, April 15, 2013 5:53:34 PM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Good approach, thanks all. How long it needs to invoke periodic
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
- Original Message - From: Doron Fediuck dfedi...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Monday, April 15, 2013 10:05:57 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Itamar Heim ih...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, April 15, 2013 9:49:12 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/15/2013 09:20 AM, Oved Ourfalli wrote: - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Doron Fediuck dfedi...@redhat.com, Ofri Masad oma...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, April 15, 2013 8:54:18 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Doron and Ofri, Thanks for your reply, here is some other question. ii. When adding a host into the trusted cluster, the host will be attested via OAT service, only trusted hosted can be added. Would you also kindly tell me if there is any mandatory logic check when adding a host into a cluster, so we can also put attestation logic with these mandatory check together? Some example or code location is better. Thanks a lot. I think there are two approaches, depending on the use case. #1: If the host trusted property is static, then you can narrow the tests to two locations: * AddVdsCommand - (Vds = Host) - This command is triggered when a new host is added to the system. You can use the canDoAction method (which we have on all commands, and it determines whether an action can be run or not), and there, if cluster requires trusted hosts only, you can test whether this host is trusted or not. * ChangeVdsClusterCommand - this command is used when you change the cluster of a host. So, if the target cluster requires tursted hosts, you can do a similar test in its canDoAction method. #2: If the host trusted property can change, then I'd suggest using the NonOperational property of a host. We have a class called VdsUpdateRunTimeInfo that does periodic tests of hosts, deciding what's their status, according to specific flags. The code there is quite complex, and would require refactoring at some point, but in the meantime you can use the MonitoringStrategy interface that is being used there, and implement a new monitoring strategy for Open Attestation. There, in the processHardwareCapabilities, you can test that the host is trusted. When creating the strategy, using the MonitoringStrategyFactory, you'll need to create the appropriate strategy. Currently we support either virt strategy or gluster strategy or both. In your case you would need virt+attestation / gluster+attestation / virt+gluster+attestation, according to the services deployed on the cluster. I'd go with the 2nd approach. i.e., not block the host from being added, only from being used, based on monitoring / non-op status +1. It means that the admin can add the host, but the host will not be operational until we get a positive indication from the attestation service. +1 if we want to test attestation only once, every time before host moves to up. the right place for it, imo, is InitVdsOnUpCommand if its periodic also after host is up, then it should be somewhere in the monitoring code Does that make sense? Doron and Ofri, what did you have in mind for this feature? Regards, Oved Best Regards, Dave Chen -Original Message- From: Doron Fediuck [mailto:dfedi...@redhat.com] Sent: Wednesday, April 10, 2013 8:03 PM To: Ofri Masad Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Gang Wei gang@intel.com Cc: Wei D Chen wei.d.c...@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Doron Fediuck dfedi...@redhat.com Sent: Wednesday, April 10, 2013 2:23:57 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi, answers inside the mail body. - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Gang Wei gang@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Ofri Masad oma...@redhat.com Sent: Wednesday, April 10, 2013 12:12:26 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Adding Ofri to answer your questions. - Original Message
Re: [Engine-devel] FeatureSupported and compatibility versions
- Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Sent: Monday, March 18, 2013 8:28:14 AM Subject: [Engine-devel] FeatureSupported and compatibility versions 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: 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 like this approach better, if one add new feature for 3.3 he should add it as 'true' in the config to be used as default, and explicitly add it as false for other unsupported versions. if we do go this way, we need to make sure it works because i vaguely remember we had a bug in configuration, making us explicitly specify value for all versions. Thoughts? Regards, Shireesh ___ 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] CreateComputerAccount - do we really need it?
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Sunday, March 17, 2013 12:01:37 PM Subject: [Engine-devel] CreateComputerAccount - do we really need it? Hi all, Do we need CreateComputerAccountCommand and its correspoding ldap broker LdapCreateComputerAccountCommand? is it exposed by any of the front-ends? (rest/user portal/webadmin)? Thanks, Yair ___ 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] new engine watchdog version
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 6:46:06 PM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Omer Frenkel ofren...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 1:25:39 PM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 12:15:39 PM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Omer Frenkel ofren...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 11:12:48 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 9:59:53 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Omer Frenkel ofren...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, March 10, 2013 8:36:46 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Friday, March 8, 2013 7:18:59 PM Subject: [Engine-devel] new engine watchdog version Hi, I uploaded a new version of the watchdog patch. This patch is still a work in progress, it adds audit log alerts to the functionality. http://gerrit.ovirt.org/12419/ Feature page: http://www.ovirt.org/Features/Watchdog_engine_support Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Hi, i looked at the patch and there is something i don't understand, i see you are treating the watchdog as a vm device, which is great, so why do we need to save the device details in vm_static table in addition to the vm_devices? i think its even not used at all (only setting the device in command which could be parameters, no need to persist) Hi Omer, Thanks, I hoped someone will come up with that question :) The answer is that I followed the established design patterns in the backend. See smartcard and memory balloon, probably others. The motivation for this pattern could be that in case of these devices, you must have the settings in the VM data, not separately in the devices. Also when vdsbroker builds the devices list, it just asks the device list. The redundancy is already there, we can make it differently in this case but that will present the readers with a puzzle: why this pattern in feature X, why that pattern in feature Y... So I would recommend to leave it like this for now and schedule a cleanup on device handling. Devices deserve a cleanup. Thx, Laszlo i agree there is a mess that requires clean-up, but i don't think its a good thing to keep piling up the mess, i don't like it that smartcard is there, but some other devices are ok (balloon and payload) so we already have 2 'patterns', lets go with the right one.. and answering also @Doron's question - yes the device data should be kept with the device Ok, I may have missed the other pattern, could you explain which one do you mean? Balloon does not very different from smartcard, it is there in VM. the difference is that balloon is not in vm_static table at all (the only place in the db for it is in vm_devices) and smartcard has 'is_smartcard_enabled' field in vm_static in addition to vm_devices (which is not needed..) Ok, so what you want is that - the engine should query the devices each time the VM record is set (from DAO's or Action) XOR - the client code (rest-api and frontend) should query the devices to figure out if the watchdog is there i prefer this approach, as we do with other sub-collections of vms (disks,networks..) but if we don't expose devices from the engine, so we need some
Re: [Engine-devel] new engine watchdog version
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 12:15:39 PM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Omer Frenkel ofren...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 11:12:48 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, March 11, 2013 9:59:53 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Omer Frenkel ofren...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, March 10, 2013 8:36:46 AM Subject: Re: [Engine-devel] new engine watchdog version - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Friday, March 8, 2013 7:18:59 PM Subject: [Engine-devel] new engine watchdog version Hi, I uploaded a new version of the watchdog patch. This patch is still a work in progress, it adds audit log alerts to the functionality. http://gerrit.ovirt.org/12419/ Feature page: http://www.ovirt.org/Features/Watchdog_engine_support Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Hi, i looked at the patch and there is something i don't understand, i see you are treating the watchdog as a vm device, which is great, so why do we need to save the device details in vm_static table in addition to the vm_devices? i think its even not used at all (only setting the device in command which could be parameters, no need to persist) Hi Omer, Thanks, I hoped someone will come up with that question :) The answer is that I followed the established design patterns in the backend. See smartcard and memory balloon, probably others. The motivation for this pattern could be that in case of these devices, you must have the settings in the VM data, not separately in the devices. Also when vdsbroker builds the devices list, it just asks the device list. The redundancy is already there, we can make it differently in this case but that will present the readers with a puzzle: why this pattern in feature X, why that pattern in feature Y... So I would recommend to leave it like this for now and schedule a cleanup on device handling. Devices deserve a cleanup. Thx, Laszlo i agree there is a mess that requires clean-up, but i don't think its a good thing to keep piling up the mess, i don't like it that smartcard is there, but some other devices are ok (balloon and payload) so we already have 2 'patterns', lets go with the right one.. and answering also @Doron's question - yes the device data should be kept with the device Ok, I may have missed the other pattern, could you explain which one do you mean? Balloon does not very different from smartcard, it is there in VM. the difference is that balloon is not in vm_static table at all (the only place in the db for it is in vm_devices) and smartcard has 'is_smartcard_enabled' field in vm_static in addition to vm_devices (which is not needed..) the way i think we (currently) need to work with devices is: add a parameter for it in the parameters, and use it in add/update (/run-once?) (as done for balloon) i don't know what is the use of the field balloonEnabled in VM, i don't see any use of it.. going forward we need to think if we want to expose devices to frontend, so then we can drop the encapsulation and just use list of devices in VmBase or something like that ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] new engine watchdog version
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Friday, March 8, 2013 7:18:59 PM Subject: [Engine-devel] new engine watchdog version Hi, I uploaded a new version of the watchdog patch. This patch is still a work in progress, it adds audit log alerts to the functionality. http://gerrit.ovirt.org/12419/ Feature page: http://www.ovirt.org/Features/Watchdog_engine_support Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Hi, i looked at the patch and there is something i don't understand, i see you are treating the watchdog as a vm device, which is great, so why do we need to save the device details in vm_static table in addition to the vm_devices? i think its even not used at all (only setting the device in command which could be parameters, no need to persist) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine table comments
- Original Message - From: Libor Spevak lspe...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, February 27, 2013 9:36:16 AM Subject: Re: [Engine-devel] Engine table comments Thanks for the confirmation. Appending a template for the columns :-) psql engine -U postgres -c SELECT 'COMMENT ON COLUMN ' || table_name || '.' || column_name || ' IS TODO;' sql FROM information_schema.columns where table_schema='public' order by table_name, column_name comments_columns_to_do.sql It looks like we have cca 73 tables and 2353 columns now. So probably better to start with the tables. i documented some (not complete) information about columns of vm_static here: http://wiki.ovirt.org/Features/Templates-3.2#Design as part of preparation for instance types feature so maybe we can use it as well On 26.2.2013 15:03, Yair Zaslavsky wrote: I think your idea is very good. I also think we should have it for columns as well. But since we already have many columns, maybe we should have an on going effort from various developers on this (i.e - each developer will do that for several tables). Thoughts? - Original Message - From: Libor Spevak lspe...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, February 26, 2013 2:37:17 PM Subject: [Engine-devel] Engine table comments Hi, I would like to propose to create a patch assigning sql comment to each Engine table. The comments will be a part of the exported DB schema report, too. The terminology is not always consistent across all application layers, so for the newcomers it would be easier to understand the model. But, what would be general guidelines? I recommend to use singular form of entity name as used from end-user point of view (if somehow visible, of course), or just used frequently inside code. Examples: storage_pool ... Data center vds_groups ... Cluster but: vm_static ... Virtual machine configuration vm_dynamic ... Virtual machine runtime data vm_statistics ... Virtual machine statistics data ... etc. This command prepares a template for the patch: psql engine -U postgres -c select 'COMMENT ON TABLE ' || relname || ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE schemaname='public' order by t.relname comments_to_do.sql or just I can prepare a page on the wiki with table containing table names and volunteers :-) can propose simple understandable comments for known tables. Is it useful? Thanks. 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Global transaction in ovirt-engine
- Original Message - From: Michael Kublin mkub...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Tuesday, February 12, 2013 11:38:33 AM Subject: [Engine-devel] Global transaction in ovirt-engine The issue is a following (I think I had raised it once), by default when any command is invoked in ovirt-engine a transaction is opened. Now, lets take a look on complicated command which is performing a lot of XML-RPC/HTTP calls and just simple update , such command is a main cause for the following problems: 1. Long transactions, each call increase a time of transaction 2. When transaction is opened a connection which is associated with it also in used, so a number of available DB connections reduced from connection pool. 3. A errors : transaction was cancelled and operation is failed on engine side, but successes at host side. 4. Performance - try to keep transactions as short as possible. 5. Performance - to many unneeded transactions 6. Bug debugging - it is very difficult to understand why something was committed and something not why transaction was reverted or not, when we have a lot of nested transactions. Now, what should be done by my opinion: 1. Change default behaviour - by default not to open a transaction (Today, transaction is opened and if we don't want a command should be marked by NonTransactiveCommandAttribute) - it is simple 2. The change described at 1 will require to rewrite and redesign some flows - more difficult, but also can be done pretty fast. By the way this can be or even should be done at any case. 3. All new commands should not be based on global transaction or keep in mind that global transaction can be disabled Benefits, 1. Better performance 2. Cleaner code 3. Less bugs 4. Increased scale Regards Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel need to remember that transaction also gave us 10-min limit for command execution, not saying its good or bad, but disabling the transactions will allow commands to run forever, this 10 min limit actually, saved us few times when commands got stuck in all kind of locks etc.. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] How to show our VM template from web protal?
- Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, February 4, 2013 11:49:33 AM Subject: Re: [Engine-devel] How to show our VM template from web protal? Thanks Itamar. Of course, we can create a VM template by clicking 'make template' button. What we want to do is create a VM template contains some customized parameters which are not currently supported by web portal, so, we expect to create the template by executing some DB procedure, like InsertVmTemplate . The result is this template could be created in DB but cannot be showed from web portal. Thanks. you can't see it also in the web admin portal or just user portal? my guess is that you are missing a permission for it (check permissions table - object id is the template id, object type for template is 4) Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Monday, February 04, 2013 4:51 PM To: Chen, Wei D Cc: engine-devel; Liu, DanqingX Subject: Re: [Engine-devel] How to show our VM template from web protal? On 01/02/2013 11:31, Chen, Wei D wrote: Hi, We are trying to create a VM template which is similar with blank template and hope to display this template on web portal, our consideration is simple, that is, just execute InsertVmTemplate procedure manually and expect our template would be showed from web portal. Unfortunately, there is no changes seen from portal even after restarting engine service. Definitely, we must miss something, would you anyone input any suggestion, any feedback is great appreciated. thanks in advance! the supported way of creating a template is to stand on a VM and click 'make template'. (as normally, templates have disks in them, though not mandatory). ___ 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] Guid NGuid
- Original Message - From: Michael Kublin mkub...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Sunday, February 3, 2013 3:10:14 PM Subject: [Engine-devel] Guid NGuid Hi, In ovirt-engine code we have Guid and NGuid objects. Guid is extends NGuid and also NGuid class has method getValue() which should return Guid. As for me these two classes are look like the same and I don't see to much differences between them. My proposal is to remove NGuid and move it functionality to Guid (Because of Guid is much more common) i agree, but we need to take another step forward and allow Guid to be null (as it should) and not assume its EMPTY or have a value (i'm pretty sure we have this assumption in many places) 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] default Vm memory size
- Original Message - From: Itamar Heim ih...@redhat.com To: Roy Golan rgo...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, January 23, 2013 8:12:09 PM Subject: Re: [Engine-devel] default Vm memory size On 23/01/2013 07:00, Roy Golan wrote: On 01/23/2013 04:34 PM, Laszlo Hornyak wrote: Hi, The default Vm size is 512 MB now. I think A bit more could be useful, e.g. a fedora installer won't start with 512 MB. What about 1024 MB? Upcoming Instance Types would be the means to handle that rather than the Blank template. Also there's work around integrating libosinfo for validating for minimum RAM per guest OS. but until then, why not change the default to 1GB which i hope is a one liner? +1 (its a db update liner - change blank template mem) ___ 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] Time to move to 3.3.0-SNAPSHOT?
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Monday, January 21, 2013 8:27:36 AM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? - Original Message - From: Michael Pasternak mpast...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, January 20, 2013 3:24:58 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 I agree, and this is not the only place where should start marking and cluster compatibility version.. 3.3.0 - what about upgrade scripts? http://gerrit.ovirt.org/11143 -- Michael Pasternak RedHat, ENG-Virtualization RD ___ 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] Proposal to add Shireesh Anjal as maintainer to engine-gluster
- Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel@ovirt.org Sent: Friday, November 30, 2012 1:28:51 PM Subject: [Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster Shireesh has been working on the engine gluster support for the past year, covering patches and leading reviews of the various engine gluster patches. I'd like to propose a new sub-component of the engine for the gluster module, adding shireesh as its maintainer. +1 Thanks, Itamar ___ 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 does engine with cpuIdle?
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, September 10, 2012 3:51:59 PM Subject: [Engine-devel] what does engine with cpuIdle? hi, I am trying to change a behavior in vdsm. When you pass 100% load on a VM, it will stop reporting further load and will keep telling 100% until the load drops under 100% again in it's cpuIdle information. This is totally correct if you have only single-cpu VM's, but it is false when you have multiple vcpu's, I think the cpuIdle information should not be on a 0-100 scale, but on a 0-100*vcpus scale. So I submitted this patch to vdsm: http://gerrit.ovirt.org/#/c/7892/2 and Dan pointed out that some functionality may depend on the value in the 0-100 interval. For me it seems it is ignored and the load is calculated only from sysCpu + userCpu. Does anyone build on the cpuIdle value? Thanks, Laszlo you are right, engine doesn't save cpuIdle for vm, so it's not in use in the engine. ___ 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] Domain rescan action question
- Original Message - From: Andrew Cathrow acath...@redhat.com To: Itamar Heim ih...@redhat.com, Dan Yasny dya...@redhat.com, Ricky Hopper ricky.hop...@netapp.com Cc: engine-devel@ovirt.org Sent: Wednesday, August 1, 2012 12:24:42 AM Subject: Re: [Engine-devel] Domain rescan action question - Original Message - From: Itamar Heim ih...@redhat.com To: Ricky Hopper ricky.hop...@netapp.com Cc: engine-devel@ovirt.org Sent: Tuesday, July 31, 2012 4:44:34 PM Subject: Re: [Engine-devel] Domain rescan action question On 07/31/2012 11:30 PM, Hopper, Ricky wrote: Hey all, As I'm making progress with the domain rescan functionality, I've realized that I'm unsure what to do with any disks that are detected on the domain. Should I add them back into the database to be listed as floating disks, or should I just return a list of disk images to be attached to whatever the caller of the query needs? - Ricky i'm not sure they should be added automatically. I think a dialog[1] showing orphan disks/images on the storage domain for user to choose which to import as 'floating' disks would be better than auto importing them. there is also the reverse of flagging existing disks as 'missing' in storage? Perhaps we should start a feature page to discuss and better scope it. There is a feature page that we could expand, it doesn't discuss the notion of importing those disks which is certainly something we need to address. http://wiki.ovirt.org/wiki/Features/Orphaned_Images +1 also, how will be handled images with snapshots? or broken chain of images (not sure its a valid scenario) [1] or a subtab on the storage domain. ___ 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] RESTAPI: what is the purpose for /api/disks collection
- Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm. At the moment this collection contains all disks in system while engine does not provide any search capabilities for it, I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so. in my view it not really useful, till we add search capabilities for being able: 1. locate shareabletrue/shareable disks this is available. 2. distinguish between shareabletrue|false/shareable and activetrue|false/active disks 3. maybe even worth taking activefalse/activeshareablefalse/shareable out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared. your thoughts? active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there) -- Michael Pasternak RedHat, ENG-Virtualization RD ___ 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] Adding atomic restore snapshot command at backend
- Original Message - From: Michael Pasternak mpast...@redhat.com To: Livnat Peer lp...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, May 28, 2012 2:37:10 PM Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend Hi Livnat, On 05/28/2012 02:07 PM, Livnat Peer wrote: On 28/05/12 12:59, Michael Pasternak wrote: Currently 'restore snapshot' done in two steps on a client side: 1. TryBackToAllSnapshotsOfVm 2. RestoreAllSnapshots This implementation creates race condition on 1 and therefore unstable bug prone, IIRC, there is an easy way to fix this, by polling on engine jobs and not vdsm tasks, no? i suggested refactoring 2 to include 1 as single atomic operation at backend. Hi Michael, The two commands above are used for functionality that is needed regardless of the functionality you are looking for. We want to present the user the option to preview a snapshot without committing to it and without loosing the current snapshot. I think we need to model the the two options above in the REST, it is functionality that is used in the UI. +1 for that. this is out of scope of this RFE. What you are looking for is a functionality 'restore to snapshot', this functionality does not exist in the engine in a single step, and I think that because we assumed that the user can get it in two steps It wasn't prioritize so far. the cons. of this approach is an async nature of the former command. Implementing the missing functionality with the two functions above is a compromise that was done in the API. To summarize I think the requirement you present is a missing functionality in the engine and solving it is not about refactoring the two existing verbs into one. what i meant is not deprecating/refactoring old commands, but introducing new one that reusing them and expose as single (atomic) command called 'RestoreAllSnapshots', sorry if i wasn't clear. another suggestion is to have a way to send to the engine list of commands that will be performed. Thanks, Livnat -- Michael Pasternak RedHat, ENG-Virtualization RD ___ 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] Enabling guest memory balloon device
- Original Message - From: Doron Fediuck dfedi...@redhat.com To: engine-devel@ovirt.org, Adam Litke a...@us.ibm.com Sent: Sunday, May 27, 2012 10:31:22 PM Subject: [Engine-devel] Enabling guest memory balloon device Hi All, In the following wiki, there's a design for enabling the balloon device, which is currently disabled in engine setups. Other than enabling the device, this is also a step forward in the path to vdsm and MoM sub-project integration. More details can be found here: http://www.ovirt.org/wiki/Features/Design/memory-balloon P.S. UI mockups should be updated soon. -- /d “Funny,” he intoned funereally, “how just when you think life can't possibly get any worse it suddenly does.” --Douglas Adams, The Hitchhiker's Guide to the Galaxy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel what does it mean template is not supported? (and why is it under ovf section?) this value will not pass to a template created from a vm? (although its mentioned in Backend-vdsm parts section) if this is a vm-device, why do we need it in vm_static? can you explain means the change in VmOldInfoBuilder? shouldn't we just ignore it to keep old behavior? or we want to support ballooning in all clusters? (in Validations section it says only 3.1 is supported) maybe validation is needed on changing vm cluster command, in case changing to 3.0 cluster and balloon enabled. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Query regarding ValidationUtils#validateInputs
- Original Message -
From: Shireesh Anjal san...@redhat.com
To: engine-devel@ovirt.org
Sent: Thursday, April 12, 2012 9:35:25 AM
Subject: [Engine-devel] Query regarding
ValidationUtils#validateInputs
Hi,
This is regarding the following validation method we have in
ValidationUtils:
public static T extends VdcActionParametersBase ArrayListString
validateInputs(ListClass? validationGroupList, T parameters);
I there any particular reason for supporting the validations only on
objects of classes derived from VdcActionParametersBase? I guess
this was done because this method is primarily intended to validate
the action parameters passed to a BLL action, using the validation
annotations on the parameter class. However I think this method can
be useful for general use as well. e.g. I cannot add a @Valid
annotation on a list or a map in a parameter class. So I need to
iterate over the list/map, and validate each element inside the
loop. The validation inside the loop can also utilize the above
method if the restriction extends VdcActionParametersBase is
removed. This will allow me to do the following in the canDoAction
method:
protected boolean canDoAction() {
...
for(GlusterBrickEntity brick :
getParameters().getGlusterVolume().getBricks()) {
ListString errors =
ValidationUtils.validateInputs(getValidationGroups(), brick);
if(errors != null) {
for(String error : errors) {
addCanDoActionMessage(error);
}
}
}
...
}
Regards,
Shireesh
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
i don't think there is a reason to restrict only for VdcActionParametersBase,
roy what do you think?
also you can use here
getReturnValue().getCanDoActionMessages().addAll(errors);
instead of going over on all errors.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - From: Oved Ourfalli ov...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org, Omer Frenkel ofren...@redhat.com Sent: Sunday, March 18, 2012 11:09:54 AM Subject: Re: [Engine-devel] Disk Permissions Feature - Original Message - From: Itamar Heim ih...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, March 15, 2012 5:46:07 PM Subject: Re: [Engine-devel] Disk Permissions Feature On 03/15/2012 05:34 PM, Omer Frenkel wrote: 1. Create disk - requires permissions on the Storage Domain, (can't assume Quota is sufficient to permit user creating the disk on the Storage Domain, as Quota might be disabled) I'd also specify create disk for regular disks is at storage domain level?, while direct lun disks require system level permission of add disk. so, if quota is disabled, how important is it to prevent creation of disks (other than direct lun ones, which would require a permission similar to storage domain creation)? if this is added, it has to be implicitly added / not needed if user has quota (i.e., having a quota should be similar to having a permission as far as the check goes). We should look into it, how complicate is it to validate if user has either quota or permission, and allow creating a disk on a SD if either exists. this might be confusing to the user as he can disable the quota, then stuff would stop working. we can't require both quota and permissions from user on storage domains - that's cumbersome. question is if we can limit the need for permissions to disks only to places where they are needed (shared, direct, floating)? +1 on that. I also think it is only relevant on attaching a disk to a VM, as the other use-cases are simpler: 1. Attach disk to VM - would require having permissions on the disk (whether it is shared, direct lun or floating) 2. Add disk to VM - would only require quota (if enforced). 3. Create disk (i.e., floating/shared disk) - would only require quota (if enforced). and if not enforced? anyone can create as much disks as he like? we thought of requiring permissions if quota is disabled, but i think its confusing to the user as he plays with ___ 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] Disk Permissions Feature
- Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, March 15, 2012 9:52:59 AM Subject: Re: [Engine-devel] Disk Permissions Feature On 15/03/12 07:25, Itamar Heim wrote: On 03/14/2012 02:20 AM, Moti Asayag wrote: Hi all, Disk Permissions feature description Wiki page: http://www.ovirt.org/wiki/Features/DiskPermissions Please share your comments. I think you are lacking a paragraph explaining some of the issues around this: - are disks part of storage domains or VMs wrt permissions inheritance? yes - Disk inherits permissions from the VM it is attached to and from the storage domain it resides on (if there is one) - what about direct luns (are not part of storage domains)? - what about shared disks (multiple inheritance if from VM)? i guess so, i think current vm roles shouldn't contain the disks actions, therefore vm admin cannot change any disk attached to his vm, only if got an explicit permission on it. (one can have disk-operator on vm, and then can manipulate any disk related to that vm) - what if tomorrow we allow disks to span multiple storage domains? i don't see a problem with this, as user will need to have permission on all the domains, makes sense to me. - quota's are already a concept of permissions to create disks at storage domain level, does user need both (cumbersome) - when do we must have this (to filter shared, floating or direct lun disks we would show to power users when not attached to VMs) - or these won't be available for now via the power user portal, only via admin. 1. Create disk - requires permissions on the Storage Domain, (can't assume Quota is sufficient to permit user creating the disk on the Storage Domain, as Quota might be disabled) I'd also specify create disk for regular disks is at storage domain level?, while direct lun disks require system level permission of add disk. so, if quota is disabled, how important is it to prevent creation of disks (other than direct lun ones, which would require a permission similar to storage domain creation)? if this is added, it has to be implicitly added / not needed if user has quota (i.e., having a quota should be similar to having a permission as far as the check goes). We should look into it, how complicate is it to validate if user has either quota or permission, and allow creating a disk on a SD if either exists. this might be confusing to the user as he can disable the quota, then stuff would stop working. 2. Attach disk to VM - requires permissions on the Disk and on the VM (applies for shared disk as well). which permission at disk is required? (disk access?) The user should have attach_disk permission on the disk and on the VM (same action on two objects). 3. Detach disk from VM - requires permissions on the VM only. (Unlike attach disk that requires permissions on the VM and on the Disk). will detaching a disk copy the permission it so far inherited from the VM? No, inheritance is never translated into explicit permission on the objects in the hierarchy . 4. UI changes an edit permissions button from VM disks subtab seems appropriate (will open a dialog i guess) I think we need permissions subtab in the floating disk main tab. I'll ask Einav to add the UI part as well to the wiki. ___ 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] 'Import VM/Template More Than Once' feature
- Original Message - From: Yaniv Kaul yk...@redhat.com To: Gilad Chaplik gchap...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, February 21, 2012 5:27:19 PM Subject: Re: [Engine-devel] 'Import VM/Template More Than Once' feature On 02/21/2012 05:11 PM, Gilad Chaplik wrote: Hello all, The 'Import VM/Template More Than Once' feature description can be found under the following link: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce Please review, and feel free to share your comments and thoughts. Thanks, Gilad. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel 1. Missing high level (user level) summary. For example, what does it mean that a VM already exist in the setup? If I had a VM with 10GB disk, without an OS installed, then exported it, then installed an OS into it (so now the disk is a bit full, as opposed to the emptied exported one). Does it means that an identical entity already exist in the setup or not? (think of overwriting files). The design should (ALWAYS?) start with the user flow. 2. 'clone' doesn't strike me as a great parameter name in the API. Not in the UI either (but I don't have a better suggestion - yet). i would say: importAsNewEntity - because what it really does is create a new entity, in terms of ids, disks, nics... also, the copyCollapse flag should be on as well. 3. What is the equivalent to 'suffix' in the API? Or do we expect to provide a name when we import? I'm not sure how the API works in the case of an existing VM, really. Only after we fetch via the API the fact it has an existing VM, we give it a new suffix? 4. Small typos (I'll fix them later directly in the wiki, except for the mockups, which I can't fix). Y. ___ 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] Shared disk / Floating disk import/export (was: Re: move disk command)
- Original Message - From: Ayal Baron aba...@redhat.com To: Maor mlipc...@redhat.com Cc: engine-devel@ovirt.org, Jon Choate jcho...@redhat.com, Omer Frenkel ofren...@redhat.com Sent: Tuesday, January 17, 2012 10:21:29 PM Subject: Re: Shared disk / Floating disk import/export (was: Re: [Engine-devel] move disk command) - Original Message - On 01/17/2012 11:57 AM, Omer Frenkel wrote: - Original Message - From: Ayal Baron aba...@redhat.com To: Omer Frenkel ofren...@redhat.com Cc: engine-devel@ovirt.org, Jon Choate jcho...@redhat.com Sent: Tuesday, January 17, 2012 10:45:53 AM Subject: Shared disk / Floating disk import/export (was: Re: [Engine-devel] move disk command) [SNIP] This may be unrelated, but user would be allowed to export and import a floating disk, right? I would like the ability to import *any* disk in the export domain as a floating disk, but in the least, export and import disks not associated with a VM. you are right, it is unrelated, this thread is about move disk of a vm between SDs, export and import is copy, and floating disks is part of the shared disk feature, this indeed need to be discussed in that scope. Ok, so I've changed the subject, now let's discuss it. Adding Maor, not sure if we have any plan regard export/import of floating disk, or in general, exporting disk without it's vm (if I understood Ayal correctly) Maor, any comments? I remember, we mentioned export/import issue in our last meeting with Andrew in the context of shared raw disk. It was decided then, that export/import will not be supported by shared raw disk, I'm not sure if we also decided that for floating disk, but I think its a PM decision. Support import/export domain might evolve to a big change, since if we want to export disk, we might also want to reflect all its configuration and functionality there, also reflect disks which are attached to VMs and templates as well. What properties does a disk have? Interface is what type of connection is used when plugging the disk in the computer (VM) so it's not really a disk property. Address is also VM specific Description is already stored in storage side. What else do you have for disk? type (system/data..) post-zero name(?) creation-date last modify date application-list volume type and format Note that being able to import floating disks means that we'd be able to take any data storage domain and import any disk(s) from it (assuming user changes domain type to export domain, which users already know how to do) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
