Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available
On 10/22/2012 05:25 PM, Morrissey, Christopher wrote: Hi Vojtech, Thanks again for the delivery of the patch. For revision 7, do you have a list of content? I had previously indicated I could work on adding the plugin API to launch a dialog, but hadn’t been able to get started on it until now. I wanted to see if you by chance were already working on it or if you were planning to deliver that yourself in the next revision? A couple of other items we are looking for are the ability to add tasks for execution and get access to the session ID or some kind of authentication token so that we can make calls from our server into the REST API. I’m not very familiar yet with the REST API so I’m not sure what authentication methods are available and which would be best. Oved - I remember we discussed UI plugins should be able to use same logic as jasper reports for getting a session identifier for using the REST API. do you remember the details on this one? Thanks, Itamar -Chris *From:*engine-devel-boun...@ovirt.org [mailto:engine-devel-boun...@ovirt.org] *On Behalf Of *Vojtech Szocs *Sent:* Thursday, October 18, 2012 10:49 AM *To:* engine-devel *Subject:* [Engine-devel] UI Plugins: PoC patch revision 6 now available Hi guys, the latest revision of UI Plugins proof-of-concept patch is now available for you to experiment with. You can download the patch from oVirt Gerrit at http://gerrit.ovirt.org/#/c/8120/2 (patch set 2). Please read on to learn what's new in this revision. If you have any comments, questions or ideas, please let me know! *0. UI plugin path information resolved using local Engine configuration** * Server-side UI plugin infrastructure now uses local (machine-specific) Engine configuration instead of global (/vdc_options/ database table) Engine configuration: * Previously, path information was resolved through org.ovirt.engine.core.common.config.Config class - Engine configuration values were retrieved from /vdc_options/ database table. * Currently, path information is resolved through org.ovirt.engine.core.utils.LocalConfig class - Engine configuration values are retrieved from local file system. In case you're not working with oVirt Engine through RPM package system, e.g. you have a local development environment set up and you build and deploy oVirt Engine through Maven, please follow these steps: a. Copy default Engine configuration into /usr/share/*ovirt-engine*/conf # mkdir -p /usr/share/ovirt-engine/conf # cp /backend/manager/conf/engine.conf.defaults /usr/share/ovirt-engine/conf/engine.conf.defaults b. If necessary, copy UI plugin data files from /usr/share/engine/ui-plugins to /usr/share/*ovirt-engine*/ui-plugins c. If necessary, copy UI plugin config files from /etc/engine/ui-plugins to /etc/*ovirt-engine*/ui-plugins d, In case you want to override the default Engine configuration, put your custom property file into /etc/sysconfig/ovirt-engine The reason behind this change is that path information for UI plugin data and configuration is typically machine-specific, and should be customizable per machine through Engine local configuration. *1. New plugin API function: addMainTabActionButton * The "addMainTabActionButton" API adds custom context-sensitive button to the given main tab's data grid, along with corresponding data grid context menu item. addMainTabActionButton(entityTypeName, label, actionButtonInterface) /entityTypeName/ indicates which main tab's data grid the button should be added to, according to the entity type associated with the main tab./entityTypeName/ values are strings reflecting org.ovirt.engine.ui.webadmin.plugin.entityEntityType enum members. Following /entityTypeName/ values are currently supported (values are case-sensitive): "DataCenter", "Cluster", "Host", "Storage", "Disk", "VirtualMachine", "Template". Note: "Pool" value is currently not supported, because of org.ovirt.engine.core.common.businessentities.vm_pools entity not implementing the BusinessEntity interface, not sure why though. Maybe we should switch from BusinessEntity to IVdcQueryable interface and always cast getQueryableId method result value to Guid? /label/ is the title displayed on the button/. / /actionButtonInterface/ represents an object that "implements the button interface" by declaring its functions: /onClick/, /isEnabled/, /isAccessible/. All functions of /actionButtonInterface/ receive currently selected item(s) as function arguments. Let's take a closer look at the concept behind /actionButtonInterface/. In traditional class-based object-oriented languages, such as Java, interface is an abstract type that contains method declarations without an implementation. A class that implements the given interface must implement all methods declared by that interface (unless it's an abstract class,
[Engine-devel] git-review
I've recently encountered more and more people not using the git-review tool and manually pushing their changes to Gerrit using raw git commands. Even though there is nothing wrong with doing things the hard way. I prefer not using an overly complicated error prone way to interact with Gerrit. Last I checked the version of git-review in Fedora is broken but I suggest using pip anyway as it is always synced with the master branch. Also, please use topics. Either use a BZ# or a topic codename (eg. live_migration, vdsm_api, nfs4_support) so people can skim the review list for topics they might want to review. Be careful, it automatically uses current the branch name (unless you use -t) so if you giving your branches funny names (I know I do) don't forget to manually specify a topic. More information. http://wiki.openstack.org/GerritWorkflow https://github.com/openstack-ci/git-review ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] Strange input from oVirt-engine for create (VM) API
On Mon, Oct 22, 2012 at 02:22:18PM -0500, Adam Litke wrote:
> Hi all,
>
> Today I was watching the vdsm log as ovirt-engine started a VM and I saw
> something peculiar with how VM device addresses were specified. Here is a
> sample of the python dictionary for the VM from vdsm.log (I reformatted it
> with
> pprint for readability):
>
> {'address': {' bus': '1',
> ' controller': '0',
> ' target': '0',
> ' type': 'drive',
> 'unit': '0'},
>
> Notice the whitespace in the 'controller', 'target', and 'type' keys. Could
> someone explain why this is happening? Is it deliberate or a bug?
I'm ashamed to see that I've taken a patch stripping these whitespaces
without discussion
http://gerrit.ovirt.org/#/c/3107/1/vdsm/libvirtvm.py
Igor, do you remember why this was not fixed properly, at the Engine
side?
Vdsm's schema should not be as lenient as the current code.
Dan.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Strange input from oVirt-engine for create (VM) API
Hi all,
Today I was watching the vdsm log as ovirt-engine started a VM and I saw
something peculiar with how VM device addresses were specified. Here is a
sample of the python dictionary for the VM from vdsm.log (I reformatted it with
pprint for readability):
{'address': {' bus': '1',
' controller': '0',
' target': '0',
' type': 'drive',
'unit': '0'},
Notice the whitespace in the 'controller', 'target', and 'type' keys. Could
someone explain why this is happening? Is it deliberate or a bug?
Thanks!
--
Adam Litke
IBM Linux Technology Center
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Feature page for GLUSTERFS_DOMAIN support is now available.
Hi list, I created a wiki page for GLUSTERFS_DOMAIN support. Comments/Suggestions are welcome. http://wiki.ovirt.org/wiki/Features/GlusterFS_Storage_Domain thanx, deepak ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] alias in disk instead of name
- Original Message - > From: "Michael Pasternak" > To: "Simon Grinberg" > Cc: "engine-devel" > Sent: Monday, October 22, 2012 8:58:25 AM > Subject: Re: [Engine-devel] alias in disk instead of name > > On 10/21/2012 06:13 PM, Simon Grinberg wrote: > > > > > > - Original Message - > >> From: "Michael Pasternak" > >> To: "Simon Grinberg" > >> Cc: "engine-devel" > >> Sent: Sunday, October 21, 2012 4:56:33 PM > >> Subject: Re: [Engine-devel] alias in disk instead of name > >> > >> On 10/21/2012 04:15 PM, Simon Grinberg wrote: > >>> > >>> > >>> - Original Message - > From: "Michael Pasternak" > To: "Simon Grinberg" > Cc: "engine-devel" > Sent: Sunday, October 21, 2012 3:48:46 PM > Subject: Re: [Engine-devel] alias in disk instead of name > > On 10/21/2012 03:36 PM, Simon Grinberg wrote: > > > > - Original Message - > >>> From: "Michael Pasternak" > >>> To: "engine-devel" > >>> Sent: Sunday, October 21, 2012 12:26:46 PM > >>> Subject: [Engine-devel] alias in disk instead of name > >>> > >>> > >>> The problem we caused by using alias in disk instead of name > >>> is > >>> break > >>> of search-by-name paradigm > >>> in engine.search dialect, not sure why we do not want forcing > >>> disk > >>> name to be unique [1], > >>> but lack of "name" in disk search is does not look good in my > >>> view. > >>> > >>> thoughts? > >>> > >>> [1] can be easily achieved via appropriate can-do-action > >>> verification. > > Names by definition are not unique IDs, > > they do, otherwise /search wasn't effective, remember users not > exposed to entity id, all entities fetched by-name, so names has > to > be unique. > >>> > >>> Yap that is what we do with many entities, and it causes > >>> problems. > >>> But with disks it is multiplied > >>> > > > thus it should not be enforced. > > What would be the auto naming conversion to ensure uniqueness > > with > > plain text? > > not sure i follow, i'll assume you refer here to empty name, - > you > cannot have an > entity with no name. > >>> > >>> Well you create a new disk - do we want to enforce the user to > >>> provide a unique disk name/alias for every disk he creates? > >>> This will drive the user crazy. This is important even for user > >>> only for floating/shared disks. For any other disks user does not > >>> care if it's disk1, hd1, whatever. For these kind of disk, it's > >>> just a VM disk and the user does not care if in all VMs this is > >>> called disk 1 - so why bother him? > >> > >> from the same reason we have unique > >> clusters/datacenters/networks/templates/etc... > > > > Networks, DataCenter, Clusters, templates - are in order of > > magnitude less then the number of disks. > > And you name once and use many. > > > > As for VMs - well it's may take that we should not force uniqueness > > either ( you can warn though ) > > you cannot have two vms with same name in same domain ... I didn't say that in a domain you are allowed to have two guests with the same hostname, I've said engine should allow for having duplicate VM names. You are assuming that the VM name is identical to the guest host name. For many this is the case, for other it's just an alias/name given in oVirt. Actually for the cloud, this is mostly going to be the case and worse, you are blocking different tenants from having the same VM name just because you are assuming that VM name = guest hostname. > > > > > For disks, well number is >= VMs to >>>= VMs > > Name by definition is mostly interesting in many cases only within > > the VM, and we don't even have a way to correlate disk alias to > > the internal name in the VM. In many cases as said before, a user > > won't care about the name/alias if it is always attached to the > > same VM. A user will rather look the VM and then list it's disk. > > So actually I'll be better off with vm1.disk1 vm2.disk2 then > > unique name per disk (PS AFAIK) this should be the default > > suggested name by the UI, but then changing the VM name will break > > this (yes, I know it's not possible ATM, but many people I know > > requested for that). > > > > So I as user will prefer that all the disks that created from a > > template will have the same name as the original template, and > > then to be able to search by (vm=name, disk=name) thus I can > > access easily the same disk for the VMs. > > > > On the other hand for others, as you've mentioned (especially for > > floating and shared disk) the name/alias may be of importance, > > uniqueness may be very important. > > any disk can become shared. Then when you make it shared then bother to give it a meaningful alias > > > > > All that I'm saying that we can't force it's not that uniqueness in > > never desired. > > simon, you missing the point, i was talk
